Red Hat Linux Networking , System Administration (P16) ppsx

Optimizing Network Services IN THIS CHAPTER ■■ Getting the X Window System ■■ Optimizing NFS ■■ Optimizing NIS ■■ Optimizing Samba Networking ■■ Getting More from a Database Server This

For LANs that need to keep accurate time or if having 50 LAN clients eachwith a slightly different idea of what time it is offends your sense of order, theNetwork Time Protocol, NTP, is for you NTP is easy to configure, brain-deadsimple to use, and remarkably accurate and reliable Perhaps the hardest part

is deciding which remote time servers to use as reference clocks Another ful, albeit infrequently requested, service is a caching proxy server If you havelimited bandwidth, Squid’s caching capabilities can reduce bandwidth con-sumption, especially for sites that are more static than dynamic Squid can also

use-be used (or misused, perhaps) to limit who can access the Web

Optimizing Network Services

IN THIS CHAPTER

■■ Getting the X Window System

■■ Optimizing NFS

■■ Optimizing NIS

■■ Optimizing Samba Networking

■■ Getting More from a Database Server

This chapter offers some tips for optimizing the performance of network vices running on Fedora Core and RHEL systems For example, X Windowsystem desktops run faster when you reduce the amount of eye candy becausegiving up eye-popping graphics results in less bandwidth consumption whenyou run X applications across a network Print queues can be configured tosend large print jobs to high-speed printers NFS disk farms can be designed tospread the load across multiple disks The information in this chapter is only astarting point, however, and does not address larger issues of performancetuning, such as establishing a baseline, identifying performance goals, andongoing performance monitoring Rather, this chapter concerns itself withspecific steps you can take to address known causes of slow performance.Chapter 32 goes into more of the theory behind performance tuning As youread the tips and ideas in this chapter, bear in mind that you always have tobalance your efforts along three axes: performance, usability, and security.Indeed, when it comes to server or application tuning, the pithy epigrammight be, “Convenient, secure, fast Pick any two.”

ser-C H A P T E R

18

Optimizing the X Window System

Optimizing the X Window system is not easy The core X protocol, despitewhat its detractors say, is actually pretty well tuned Of course, as KeithPackard and Jim Gettys point out in their Usenix paper, “X Window Sys-tem Network Performance,” (see http://keithp.com/~keithp/talks/usenix2003/html/net.html), protocol improvements are under waythat should make X more efficient at the wire level Nonetheless, the garden-variety system administrator usually lacks the time, not to mention the desire,

to hack X at the level described in Packard’s and Gettys’ paper

What exactly does “performance” mean vis-à-vis the X Window system?Depending on whom you ask, the phrase “X performance” might mean one ormore of:

■■ Drawing and refresh speed, which refers to the time taken to render

com-plex graphics (including 3-D graphics) on-screen

■■ Startup and initialization time, which refers to how long it takes the X

Window System as a whole and, more pertinently, X applications tostart and become ready to accept user input

■■ Application responsiveness, which refers to the user’s perception of how

quickly or slowly an application responds to mouse and keyboard input

■■ Client-server communication speed, which refers to the round-trip time

between an X client and an X serverFor the most part, this section addresses the first three measurements of per-formance The fourth metric, client-server communication speed, is difficult toaddress without either rewriting the X application in question or making sig-nificant changes in your network infrastructure There are, naturally, somesteps you can take to improve the performance of X or, more specifically, theXorg system running on Fedora Core or RHEL

■■ The biggest improvement comes from beefing up the hardware onwhich you are running X There is simply no way around the fact that

a faster CPU, a faster GPU (graphics processing unit) that supports

hard-ware acceleration, more RAM, and more video RAM do more than thing else to speed up X Naturally, hardware upgrades are not always

any-an option, but they are the best option you have

■■ Use a lightweight window manager The eye candy and functionalityprovided by desktop environments such as GNOME and KDE carry aheavy price tag in terms of overall system performance If, like us, youuse X mostly as a platform for running xterms, a Web browser, andother graphical applications, you might not even miss the integrationbetween applications that the desktop environments provide

■■ Consider reducing the color depth at which you run X.org Obviously, ifyou need millions of colors for heavy-duty image processing or videoediting, 16-bit color will result in poor-quality images An awful lot of thecomputing that takes place on a Fedora Core and RHEL systems is textprocessing, programming, and email Twenty-four-bit and 32-bit colorare computationally intensive; 16-bit color is much less demanding.

■■ Reduce the amount of eye candy on your desktop A solid-color ground is much less memory-intensive than a full-color wallpaperimage Transparent backgrounds in terminal emulators are cool butusually impose overhead on the windowing system to keep the back-ground properly rendered and up to date Shaped windows and bor-ders are aesthetically pleasing but somewhat expensive in terms ofresources

back-■■ Run a local font server Doing so makes the fonts you want availablelocally, so they do not have to be sent across the network Similarly, youcan free up memory and speed up the server’s font handling by gettingrid of fonts (that is, not loading them in /etc/X11/xorg.conf) thatyou do not use For example, on a laptop computer, you can probablydisable the 100-dpi fonts because you cannot run the X server at a highenough resolution to get any benefit from the better-quality fonts Simi-larly, if you don’t use the CID fonts and Cyrillic fonts, don’t load them

■■ Actively seek out lightweight X-based applications We no longer useMozilla, for example, because we have found that Firefox, the browser-only replacement for Mozilla, provides everything we need in a Webbrowser

■■ Make sure that the X server is up-to-date The X.org project is working

to separate drivers from the rest of the system, which will enable you todownload and install an updated driver for your card without having

to refresh the entire X.org installation Drivers sometimes improve matically from release to release, so stay informed about the driver foryou card

dra-■■ Unload modules you do not use The standard X.org installation, forexample, loads the RECORD and XTRAP extensions Edit /etc/X11/xorg.confand comment out the lines that read:

■■ Run X at a lower nice value, thereby increasing its priority relative toother processes By increasing X’s priority over other processes, you get

a more responsive system One way to do this is to start X using thecommand nice -n -10 X :0 You need root access to use the nicecommand to increase a process’s priority If you run X using one ofthe display managers (xdm, gdm, or kdm), modify the Xservers file(/etc/X11/xdm/Xservers) Find the line that resembles the following:

:0 local /usr/X11R6/bin/XChange the line so that it looks like the following, and then exit andrestart X:

:0 local nice -n -10 /usr/X11R6/bin/X

T I P Counterintuitively, lowering a process’s nice value increases its priority

relative to other processes Think of it this way: the lower a process’s nice value, the less nice it is to other processes.

■■ If you run X for long periods of time, memory gets tied up as cache.Occasionally restarting X refreshes potentially stale caches and alsofrees up memory that might have been lost to leaks

Don’t try all of these suggestions at once because doing so will make it ficult, if not impossible, to pinpoint the change or changes that had the mostaffect Rather, make one change and then test and record the result Add eachchange incrementally, making sure to test and record the result, if any At theend of the process, compare the results of your efforts to the pretuning perfor-mance to obtain a measure of how things have changed The principleinvolved is to have a known baseline against which to measure the impact agiven tuning measure makes

dif-Optimizing NFS

The subject of performance tuning deserves its own book, and, indeed numerousbooks exist on the general topic of performance tuning Nevertheless, we can pro-vide some general guidelines for improving NFS’s performance and offer a fewtips for maintaining a responsive NFS environment The suggestions are far fromexhaustive, and you must also take into account the needs and requirements ofyour network To make the point that we make throughout this chapter, test yourassumptions and tuning methods against baseline performance metrics takenfrom an untuned system Comparing pre- with posttuning performance is theonly way to ensure that your efforts make a positive difference

NFS is sensitive to network performance, more specifically to network gestion and bandwidth problems As a general rule, if NFS performance starts

con-to degrade, you can be reasonably certain that heavy network traffic is the prit However, NFS traffic, especially at the server, tends to be “bursty,” char-acterized by periods of relative quiescence broken up with sharp upwardspikes in activity As a result, tuning efforts need to take into account such

cul-uneven access patterns to ensure optimal performance under load and during

less strenuous periods

Here are a few general suggestions you can apply to improve a system’sperformance overall and the performance of an NFS server in particular Whilemost of these tips address a server system, they also have beneficial effects on

a client system Bear in mind that the impact of any changes will be morenoticeable in large, heavily used NFS installations than in small installationswhere the total number of clients and servers is counted in single digits

■■ Using a journaling file system offers two clear advantages for an NFSserver First, in the event of a crash, journaling file systems recovermuch more quickly than nonjournaling file systems If you value yourdata, use a journaling file system on an NFS server Second, journalingfile systems need only update the journal to maintain data integrity, so

an NFS server running a journaling file system “completes” I/O muchfaster because only the journal needs to be updated After updating thejournal, the server can safely issue an I/O completed reply to theclients Meanwhile, the actual file system update occurs when theserver is less busy

■■ Spread NFS exported file systems across multiple disks and, if possible,multiple disk controllers The purpose of this strategy is to avoid disk

hot spots, which occur when I/O operations concentrate on a single disk

or a single area of a disk Similarly, distribute disks containing NFSexported file systems across multiple disk controllers This measurereduces the amount of I/O traffic on any single controller, whichimproves the overall performance of the I/O subsystem

■■ Replace IDE disks with serial ATA disks If you have the budget for it,use FibreChannel disk arrays FibreChannel, although markedly moreexpensive than IDE, serial ATA, and even SCSI, offers even faster per-formance However, in small shops and for small servers, usingFibreChannel is akin to killing gnats with a howitzer

■■ If your NFS server is using RAID, use RAID 1/0 to maximize write speedand to provide redundancy in the event of a disk crash RAID 5 seemscompelling at first because it ensures good read speeds, which is impor-tant for NFS clients, but RAID 5’s write performance is lackluster, andgood write speeds are important for NFS servers Write performance is

critical because Linux’s NFS implementation now defaults to nous mode (and has since about kernel version 2.4.7), meaning that NFSoperations do not complete until the data is actually synced to disk.

synchro-C R O S S - R E F E R E N synchro-C E For more information about configuring NFS, particularly how to disable synchronous I/O, see Chapter 12.

■■ Consider replacing 10-Mbit Ethernet cards with 100-Mbit Ethernet cardsthroughout the network Although only slightly more expensive thantheir 10-Mbit cousins, 100-Mbit cards offer considerably more through-put per dollar The faster cards result in better network performanceacross the board, not just for NFS Of course, to reap the benefits of 100-Mbit cards, they need to be used on clients and servers, and the gate-ways, routers, and switches must be capable of handling 100-MB speeds

■■ In situations in which performance is the paramount concern, GigabitEthernet (1000 Mbit) is available, although expensive Other high-performance network options, such as Myrinet and SONET (Synchro-nous Optical Networking), exist as well but are typically used as clusterinterconnect solutions rather than as the underlying protocols for gen-eral purpose LANS or intranets

■■ Replace hubs with switches Network hubs, while less expensive thanswitches, route all network traffic across the same data channel Duringperiods of heavy activity, this single data channel can easily become sat-urated Switches, on the other hand, transmit network packets acrossmultiple data channels, reducing congestion and packet collisions andresulting in faster overall throughput

■■ If necessary, dedicate one or more servers specifically to NFS work.CPU or memory-intensive processes, such as Web, database, and compute servers, can starve an NFS server for needed CPU cycles ormemory pages

■■ An increasingly inexpensive alternative is adding a NAS, or

network-attached storage, device to the network A NAS device is effectively alarge box of disks attached to the network by assigning the NAS itsown IP address NAS devices speed up file access because file I/O ismoved off the departmental or workgroup server and because NASdevices usually have special-purpose high-speed I/O chips ParkingNFS exports on a NAS can improve NFS performance significantly

■■ A common NFS optimization is to minimize the number of intensive NFS exports Automounted homes are useful, expected,

write-and therefore hard to eliminate, but for other exports it might be mal to stop sharing heavily used project directories and require people

opti-to access the remote system that houses them via SSH or Telnet opti-to mize network traffic

mini-■■ In extreme cases, resegmenting the network might be the answer toNFS performance problems Resegmenting the network to isolate NFStraffic on its own network segment reduces network saturation andcongestion and allocates dedicated bandwidth to NFS traffic

A good place to start evaluating NFS performance is to use the nfsstatcommand, which prints the NFS statistics maintained by the kernel You canuse nfsstat output to establish baseline performance metrics; to measure theeffects, if any, of configuration changes; and to diagnose specific NFS perfor-mance problems nfsstat’s general syntax is:

nfsstat [-acnrsz] [-o facility]

Table 18-1 explains nfsstat’s options

By default, nfsstat displays statistics for both NFS and the underlyingRPC service Use the -n option to display on NFS statistics or the -r option toprint only RPC statistics Likewise, nfsstat displays client and server statis-tics unless you specify -c for client statistics (which makes little sense becausethe client does not maintain statistics in the current implementation) or -s tofor server statistics The following listing displays NFS statistics only for anNFS server:

Table 18-1 nfsstat Command Options

OPTION DESCRIPTION

-a Prints all (NFS, RPC, and network) statistics for NFS clients and

servers -c Prints NFS client statistics -n Prints only NFS statistics -r Prints only RPC statistics -s Prints only NFS server statistics -z Resets the kernel’s NFS statistics counters to zero (not currently

supported)

-o facility Displays statistics for the specified facility

Notice that the statistics for NFS version 2 are all zeroes This is so becausethis particular server is running NFS version 3 The displayed informationshows the type of operation performed (arranged by RPC call), such asgetattr, read, or write, the number of such operations performed, and thedistribution of each operation For example, 10,861 getattr operations havebeen performed, which represents 43 percent of all NFS server operations.The facility argument for the -o option enables you to fine-tune thetype of information nfsstat displays facility can have one of the follow-ing values:

■■ fh— Displays utilization data on the server’s file handle cache, ing the total number of lookups and the number of cache hits and misses

includ-■■ net— Shows network layer statistics, such as the number of receivedpackets or number of TCP connections

■■ nfs— Displays NFS protocol statistics categorized by RPC call

■■ rc— Prints utilization data on the server’s request reply cache, ing the total number of lookups and the number of cache hits and misses

includ-■■ rpc— Prints general RPC informationFor additional information about improving the performance of NFS, seethe Linux NFS-HOWTO on the NFS Web page at http://nfs.sourceforge.net/nfs-howto/ The NFS-HOWTO dedicates an entire section toperformance tuning the Linux NFS implementation Another valuable source

of general performance tuning information, not only for NFS but also for allvarieties of Linux issues, is the Linux Performance Tuning Web site athttp://linuxperf.nl.linux.org/

Optimizing NIS

How do you know when you have an NIS performance problem? If you issue

a command that touches NIS-maintained information (such as yppasswd)that takes longer than you expect to complete, NIS might have problems.Other symptoms of NIS stumbling include error messages with phrases like

“Busy try again later” or “Not responding.” Another sign of NIS problems isslow login times or apparent system hangs when you are logged in

Frankly, with NIS+ for Linux no longer in development and traditional NIS

in maintenance mode, not much can be done to improve NIS’s performance.Nevertheless, the following tips should help you avoid common problemswith NIS’s speed

■■ Make sure that your problem is with NIS and not with NFS-mountedexports This is especially true when you are using automounted homedirectories, because problems that seem to be caused by NIS (such asslow login times) might actually be the result of problems mounting anexported home directory from a busy NFS server

■■ Do not use recursive netgroups A recursive netgroup is an NIS group

defined in terms of other NIS groups Recursive groups are quite nient for administrators because they limit the maintenance burden,but resolving group names is time-consuming and thus slows down theserver

conve-In large NIS installations, set up slave servers to reduce the load on themaster server Slave servers work best in situations in which the NISmaps are relatively static

■■ Partition big NIS domains into smaller so-called subdomains The idea

here is to reduce the number of authoritative maps served by any singlemaster server This reduces the overall load on any one NIS server andminimizes the size of NIS maps that have to be pushed around

As awful as doing so may sound, the best way to optimize NIS’s mance might be to replace it with something else, such as LDAP

perfor-Optimizing Samba Networking

Probably the most important consideration for optimizing Samba mance is file transfer speed between the Samba server and clients There areoptions that can be set in the /etc/samba/smb.conf file that will increasefile transfer performance between the client and server You can try them todetermine if your performance increases after implementing them

perfor-■■ socket options— These are controls on the networking layer of theoperating system that enable tuning of the connection For a completelist of options, refer to the smb.conf man page A good choice for tun-ing your local network is to use socket options = IPTOS_LOWDELAYTCP_NODELAY.

■■ dns proxy— This option should be set to no unless your Samba server is acting as a WINS server Setting this option to no prevents

the server from doing unnecessary name lookups and increases systemperformance

■■ debug level— This option should be set to 2 or less Setting thedebug level higher than 2 causes the server to flush the log file aftereach operation, a time-consuming process indeed

■■ level2 oplocks— This option provides for caching of downloadedfiles on the client machine Setting this option to true can increase sys-tem performance

Getting More from a Database Server

Like the topic of performance tuning in general, database performance tuningwould also require book-length treatment for fuller coverage The followingtips and references will get you started:

■■ Use a different scheduler— The Linux kernel supports four differentprocess schedulers, each of which excel at handling certain types ofworkloads Although you will want to test the results, the preferred andrecommended scheduler to use for database systems is the so-called cfqscheduler To use it, pass the following boot parameter to the kernel atboot time:

elevator=cfq

■■ Use raw disk partitions— Oracle supports storing data on raw or

unformatted disk partitions The advantage of using raw partitions isthat Oracle’s I/O processes bypass the kernel’s data caches and buffers,significantly speeding up disk I/O

■■ Add memory— Up to the limit supported by the underlying RDBMSand the kernel, database servers almost always benefit from addingRAM and/or swap

■■ Follow RDBMS vendor recommendations— For the most up-to-datedatabase server tuning techniques and suggestions, the RDBMS ven-dors are likely the best source of information The following links willtake you to the server optimization tips for the database server softwarediscussed in this book:

■■ MySQL — ”Optimizing the MySQL Server”: http://dev.mysql

.com/doc/mysql/en/optimizing-the-server.html

■■ PostgreSQL — ”PostgreSQL Hardware Performance Tuning”:

www.postgresql.org/files/documentation/books/aw_pgsql/hw_performance

■■ Oracle — ”Tuning the Oracle 9i Database on Linux”: www.oracle

.com/technology/oramag/webcolumns/2003/techarticles/scalzo_linux03.html

Summary

This chapter gave you some hints for improving the performance of FedoraCore and RHEL networking services Although not strictly necessary on aserver system, you learned some steps to take to speed up the X Window sys-tem All of these suggestions boiled down to eliminating or at least reducinggraphical eye candy We also highlighted the performance issues that can arisewith NFS and the measures you can implement to solve some of these prob-lems NIS can also be fixed, although the best “fix” is often to replace NIS withLDAP because LDAP is actively developed, whereas NIS is largely in mainte-nance mode The Samba optimization tips largely centered around reducingthe number and frequency of round trips to the server Finally, we offeredsome suggestions to get better out of a database server, which mostly involvedaddressing I/O bottlenecks and using a different kernel process scheduler.Candidly, performance tuning requires a book all its own; we hope we havegiven you a good start

PA R T

Three Internet Services

Chapter 19: What Are Internet Services?

Chapter 20: Configuring BIND: The Domain Name System

Chapter 21: Configuring Mail Services

Chapter 22: Configuring FTP Services

Chapter 23: Configuring a Web Server

Chapter 24: Providing Web Services

Chapter 25: Optimizing Internet Services