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.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Nativ Disc
- The Many Paths to a Solution
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Recovery of RAID and LVM2 Volumes
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- Synopsys' Coverity
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
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