Linux in Government: Optimizing Desktop Performance, Part III
As we discussed in Part I and Part II of this article series, for most of its existence, people have distributed Linux as a workstation or a server rather than as a desktop. The default workstation that evolved has existed mostly for use by developers. So, when you install a Linux distribution with a graphical interface, it generally fits the preferences of a developer. In addition, it performs like many UNIX workstations do, which can seem sluggish.
Some default features of Linux that seem slow to a new desktop user appear perfectly acceptable to long-time workstation users. When we begin to disable services that slow down the boot process, some Linux users might object. For instance, killing the mail transfer agent could mean that service messages meant for root or admin are not sent. Someone wanting to boot up her laptop quickly, however, might not care about that. For system administrators and developers, though, the missing chance to analyze a program flaw becomes a lost opportunity.
Most developers and administrators do not reboot their workstations. They consider uptime an important measurement of Linux's stability and do not seem to mind if services run that they do not use. If you run the command top, you can see why. Take a look at Figure 1.
As you can see in Figure 1, 70 processes or tasks exist, but 68 are sleeping. Open a terminal and run top on your own system, and watch as processes come alive and go to sleep. To quit the program, simple type q. So even if you started a service, it may rarely wake up and take up many CPU cycles or need much memory.
For desktop and laptop users who want a fast-booting operating system, getting rid of services you do not need can appear to improve performance. Obviously, if you are new to Linux, though, you probably do not know which processes you can get rid of safely nor how to stop them and keep them from restarting at boot time.
Note: In the first part of this series we said we would concentrate on Fedora Core 3 and Ubuntu 5.04. That has not changed. Depending on your distribution, some of the tweaks discussed in this series may not apply.
Also, some readers have suggested we put a warning label on our tweaks. When you try any suggestion we discuss, realize that they could have risks associated with them. Although we want to maximize performance, you have to experiment with some of our suggestions. Some of our examples may exist simply for illustration sake, such as the exercise with hdparm. We illustrated and stressed that hard drives had the potential to increase or decrease performance. You may understand how a hard drive can improve performance and choose to live with your existing situation anyway.
Before you can scale down processes in your installation of Linux to achieve increased performance, it helps to understand a little about how the operating system initializes services at boot time. Although this represents a simplistic explanation, it can provide enough background for you to accomplish the task of disabling unwanted services.
During boot up, the init process runs and starts software after the kernel initializes all devices. Depending on the distribution, Linux defines system states or runlevels such as text mode or graphics mode. In Fedora when you issue the command #init 3, for example, you put Linux in a full multiuser support state with the full range of services available, but you only see a text or command-line interface. Running #init 5 causes you to change states and run in graphical mode.
Linux-dedicated servers often run in init 3 mode. To give you an idea of how people regarded Linux before the maturity of GNOME and KDE, here's a 1999 quote from Craig Hunt (Linux Network Servers, Sybex):
Runlevel 5 initializes the system as a dedicated X Windows terminal. I don't think that is the best use for a powerful Linux system, but if you want to, you can use the system as a terminal by starting in runlevel 5.
Linux developers have taken the operating system from a simple X manager during the 1998-1999 timeframe to a complete graphical desktop that competes with Microsoft's and Apple's offerings. So, if you simply want a Linux desktop, you probably want to start out in graphical mode instead of text mode. In Fedora that means you live in runlevel 5, and in Ubuntu you live in runlevel 2.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide