Summary For LANs that need to keep accurate time or if having 50 LAN clients each with a slightly different idea of what time it is offends your sense of order, the Network Time Protocol, NTP, is for you. NTP is easy to configure, brain-dead simple to use, and remarkably accurate and reliable. Perhaps the hardest part is deciding which remote time servers to use as reference clocks. Another use- ful, albeit infrequently requested, service is a caching proxy server. If you have limited bandwidth, Squid’s caching capabilities can reduce bandwidth con- sumption, especially for sites that are more static than dynamic. Squid can also be used (or misused, perhaps) to limit who can access the Web. 414 Chapter 17 23_599496 ch17.qxd 8/30/05 6:42 PM Page 414 415 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 ser- vices running on Fedora Core and RHEL systems. For example, X Window system desktops run faster when you reduce the amount of eye candy because giving up eye-popping graphics results in less bandwidth consumption when you run X applications across a network. Print queues can be configured to send large print jobs to high-speed printers. NFS disk farms can be designed to spread the load across multiple disks. The information in this chapter is only a starting point, however, and does not address larger issues of performance tuning, such as establishing a baseline, identifying performance goals, and ongoing performance monitoring. Rather, this chapter concerns itself with specific steps you can take to address known causes of slow performance. Chapter 32 goes into more of the theory behind performance tuning. As you read the tips and ideas in this chapter, bear in mind that you always have to balance your efforts along three axes: performance, usability, and security. Indeed, when it comes to server or application tuning, the pithy epigram might be, “Convenient, secure, fast. Pick any two.” CHAPTER 18 24_599496 ch18.qxd 8/30/05 6:46 PM Page 415 Optimizing the X Window System Optimizing the X Window system is not easy. The core X protocol, despite what its detractors say, is actually pretty well tuned. Of course, as Keith Packard 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 way that 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 or more 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 to start 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 server For the most part, this section addresses the first three measurements of per- formance. The fourth metric, client-server communication speed, is difficult to address without either rewriting the X application in question or making sig- nificant changes in your network infrastructure. There are, naturally, some steps you can take to improve the performance of X or, more specifically, the Xorg system running on Fedora Core or RHEL. ■■ The biggest improvement comes from beefing up the hardware on which 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 any- thing else to speed up X. Naturally, hardware upgrades are not always an option, but they are the best option you have. ■■ Use a lightweight window manager. The eye candy and functionality provided by desktop environments such as GNOME and KDE carry a heavy price tag in terms of overall system performance. If, like us, you use X mostly as a platform for running xterms, a Web browser, and other graphical applications, you might not even miss the integration between applications that the desktop environments provide. 416 Chapter 18 24_599496 ch18.qxd 8/30/05 6:46 PM Page 416 ■■ Consider reducing the color depth at which you run X.org. Obviously, if you need millions of colors for heavy-duty image processing or video editing, 16-bit color will result in poor-quality images. An awful lot of the computing that takes place on a Fedora Core and RHEL systems is text processing, programming, and email. Twenty-four-bit and 32-bit color are computationally intensive; 16-bit color is much less demanding. ■■ Reduce the amount of eye candy on your desktop. A solid-color back- ground is much less memory-intensive than a full-color wallpaper image. Transparent backgrounds in terminal emulators are cool but usually 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 of resources. ■■ Run a local font server. Doing so makes the fonts you want available locally, so they do not have to be sent across the network. Similarly, you can free up memory and speed up the server’s font handling by getting rid of fonts (that is, not loading them in /etc/X11/xorg.conf) that you do not use. For example, on a laptop computer, you can probably disable the 100-dpi fonts because you cannot run the X server at a high enough 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 use Mozilla, for example, because we have found that Firefox, the browser- only replacement for Mozilla, provides everything we need in a Web browser. ■■ 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 to download and install an updated driver for your card without having to refresh the entire X.org installation. Drivers sometimes improve dra- matically from release to release, so stay informed about the driver for you card. ■■ Unload modules you do not use. The standard X.org installation, for example, loads the RECORD and XTRAP extensions. Edit /etc/X11 /xorg.conf and comment out the lines that read: Load “record” Load “xtrap” Granted, these are only two modules with negligible memory and CPU impact, but every little bit helps. ■■ If you are motivated enough, consider recompiling X or at least the X applications you use most often for your specific system. Optimizing Network Services 417 24_599496 ch18.qxd 8/30/05 6:46 PM Page 417 ■■ Run X at a lower nice value, thereby increasing its priority relative to other 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 the command nice -n -10 X :0. You need root access to use the nice command to increase a process’s priority. If you run X using one of the 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/X Change the line so that it looks like the following, and then exit and restart X: :0 local nice -n -10 /usr/X11R6/bin/X TIP 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 also frees up memory that might have been lost to leaks. Don’t try all of these suggestions at once because doing so will make it dif- ficult, if not impossible, to pinpoint the change or changes that had the most affect. Rather, make one change and then test and record the result. Add each change incrementally, making sure to test and record the result, if any. At the end of the process, compare the results of your efforts to the pretuning perfor- mance to obtain a measure of how things have changed. The principle involved is to have a known baseline against which to measure the impact a given tuning measure makes. Optimizing NFS The subject of performance tuning deserves its own book, and, indeed numerous books exist on the general topic of performance tuning. Nevertheless, we can pro- vide some general guidelines for improving NFS’s performance and offer a few tips for maintaining a responsive NFS environment. The suggestions are far from exhaustive, and you must also take into account the needs and requirements of your network. To make the point that we make throughout this chapter, test your assumptions and tuning methods against baseline performance metrics taken from an untuned system. Comparing pre- with posttuning performance is the only way to ensure that your efforts make a positive difference. 418 Chapter 18 24_599496 ch18.qxd 8/30/05 6:46 PM Page 418 NFS is sensitive to network performance, more specifically to network con- gestion and bandwidth problems. As a general rule, if NFS performance starts to degrade, you can be reasonably certain that heavy network traffic is the cul- prit. However, NFS traffic, especially at the server, tends to be “bursty,” char- acterized by periods of relative quiescence broken up with sharp upward spikes in activity. As a result, tuning efforts need to take into account such 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’s performance overall and the performance of an NFS server in particular. While most 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 more noticeable in large, heavily used NFS installations than in small installations where the total number of clients and servers is counted in single digits. ■■ Using a journaling file system offers two clear advantages for an NFS server. First, in the event of a crash, journaling file systems recover much more quickly than nonjournaling file systems. If you value your data, use a journaling file system on an NFS server. Second, journaling file systems need only update the journal to maintain data integrity, so an NFS server running a journaling file system “completes” I/O much faster because only the journal needs to be updated. After updating the journal, the server can safely issue an I/O completed reply to the clients. Meanwhile, the actual file system update occurs when the server 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 NFS exported file systems across multiple disk controllers. This measure reduces the amount of I/O traffic on any single controller, which improves 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 more expensive than IDE, serial ATA, and even SCSI, offers even faster per- formance. However, in small shops and for small servers, using FibreChannel is akin to killing gnats with a howitzer. ■■ If your NFS server is using RAID, use RAID 1/0 to maximize write speed and to provide redundancy in the event of a disk crash. RAID 5 seems compelling at first because it ensures good read speeds, which is impor- tant for NFS clients, but RAID 5’s write performance is lackluster, and good write speeds are important for NFS servers. Write performance is Optimizing Network Services 419 24_599496 ch18.qxd 8/30/05 6:46 PM Page 419 critical because Linux’s NFS implementation now defaults to synchro- nous mode (and has since about kernel version 2.4.7), meaning that NFS operations do not complete until the data is actually synced to disk. CROSS-REFERENCE 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 cards throughout the network. Although only slightly more expensive than their 10-Mbit cousins, 100-Mbit cards offer considerably more through- put per dollar. The faster cards result in better network performance across 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, Gigabit Ethernet (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 cluster interconnect solutions rather than as the underlying protocols for gen- eral purpose LANS or intranets. ■■ Replace hubs with switches. Network hubs, while less expensive than switches, route all network traffic across the same data channel. During periods of heavy activity, this single data channel can easily become sat- urated. Switches, on the other hand, transmit network packets across multiple data channels, reducing congestion and packet collisions and resulting 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 or memory pages. ■■ An increasingly inexpensive alternative is adding a NAS, or network- attached storage, device to the network. A NAS device is effectively a large box of disks attached to the network by assigning the NAS its own IP address. NAS devices speed up file access because file I/O is moved off the departmental or workgroup server and because NAS devices usually have special-purpose high-speed I/O chips. Parking NFS exports on a NAS can improve NFS performance significantly. ■■ A common NFS optimization is to minimize the number of write- intensive NFS exports. Automounted homes are useful, expected, 420 Chapter 18 24_599496 ch18.qxd 8/30/05 6:46 PM Page 420 and therefore hard to eliminate, but for other exports it might be opti- mal to stop sharing heavily used project directories and require people to access the remote system that houses them via SSH or Telnet to mini- mize network traffic. ■■ In extreme cases, resegmenting the network might be the answer to NFS performance problems. Resegmenting the network to isolate NFS traffic on its own network segment reduces network saturation and congestion and allocates dedicated bandwidth to NFS traffic. A good place to start evaluating NFS performance is to use the nfsstat command, which prints the NFS statistics maintained by the kernel. You can use nfsstat output to establish baseline performance metrics; to measure the effects, 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 underlying RPC service. Use the -n option to display on NFS statistics or the -r option to print only RPC statistics. Likewise, nfsstat displays client and server statis- tics unless you specify -c for client statistics (which makes little sense because the client does not maintain statistics in the current implementation) or -s to for server statistics. The following listing displays NFS statistics only for an NFS server: $ /usr/sbin/nfstat -n -s Server nfs v2: null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir fsstat 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Server nfs v3: null getattr setattr lookup access readlink 0 0% 10861 43% 297 1% 6305 25% 95 0% 0 0% read write create mkdir symlink mknod 4151 16% 912 3% 621 2% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 1236 4% 0 0% 0 0% 615 2% 0 0% 0 0% fsstat fsinfo pathconf commit 9 0% 9 0% 0 0% 91 0% Optimizing Network Services 421 24_599496 ch18.qxd 8/30/05 6:47 PM Page 421 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 because this particular server is running NFS version 3. The displayed information shows the type of operation performed (arranged by RPC call), such as getattr, read, or write, the number of such operations performed, and the distribution of each operation. For example, 10,861 getattr operations have been performed, which represents 43 percent of all NFS server operations. The facility argument for the -o option enables you to fine-tune the type of information nfsstat displays. facility can have one of the follow- ing values: ■■ fh — Displays utilization data on the server’s file handle cache, includ- ing the total number of lookups and the number of cache hits and misses ■■ net — Shows network layer statistics, such as the number of received packets 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, includ- ing the total number of lookups and the number of cache hits and misses ■■ rpc — Prints general RPC information For additional information about improving the performance of NFS, see the Linux NFS-HOWTO on the NFS Web page at http://nfs.source forge.net/nfs-howto/. The NFS-HOWTO dedicates an entire section to performance tuning the Linux NFS implementation. Another valuable source of general performance tuning information, not only for NFS but also for all varieties of Linux issues, is the Linux Performance Tuning Web site at http://linuxperf.nl.linux.org/. 422 Chapter 18 24_599496 ch18.qxd 8/30/05 6:47 PM Page 422 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 is slow 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 problems with NIS’s speed. ■■ Make sure that your problem is with NIS and not with NFS-mounted exports. This is especially true when you are using automounted home directories, because problems that seem to be caused by NIS (such as slow login times) might actually be the result of problems mounting an exported 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 conve- nient for administrators because they limit the maintenance burden, but resolving group names is time-consuming and thus slows down the server. In large NIS installations, set up slave servers to reduce the load on the master server. Slave servers work best in situations in which the NIS maps 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 single master server. This reduces the overall load on any one NIS server and minimizes 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 perfor- mance might be to replace it with something else, such as LDAP. Optimizing Samba Networking Probably the most important consideration for optimizing Samba perfor- mance is file transfer speed between the Samba server and clients. There are options that can be set in the /etc/samba/smb.conf file that will increase file transfer performance between the client and server. You can try them to determine if your performance increases after implementing them. Optimizing Network Services 423 24_599496 ch18.qxd 8/30/05 6:47 PM Page 423 [...]... system Generally finger displays a user’s login name, real name, terminal name, idle time, login time, office location, and phone number You should disable finger outside of your local network, because user information gathered from it could be used to compromise your system The finger daemon listens on port 79 talk and ntalk talk and ntalk are real-time chat protocols The talk server runs on port 517 and... of the Linux networking world, and xinetd is an improvement on an important program that has been around for several years It incorporates new features that have been desired by system administrators for a few years now xinetd starts at system boot time, and waits and listens for connections to come in on the ports to which they are assigned in their conf files After a connection request is made, if... like Telnet — you start SSH, it asks for your password, and then you see a regular terminal screen What Are Internet Services? In addition to providing terminal access, SSH tunnels almost any other protocol through it So, it is possible to tunnel POP, RCP, and other protocols through SSH to turn them into encrypted, more secure protocols With enough imagination and practice, you can make almost anything... repositories, such as ftp.redhat.com, FTP is still the standard application to use However, for personal file transfers, you should use scp scp encrypts the traffic, including passwords Once you have successfully logged on to an FTP server, you can type help for a list of available commands Two important commands to remember are put to move a file from your machine to the remote machine, and get to... Actually, TCP and IP are two of the protocols that are included in a group of protocols sometimes known as the Internet protocols Since the two most frequently used or discussed protocols of the suite are TCP and IP, the entire suite is often referred to as just TCP/IP Internet services can be provided through either secure or nonsecure TCP/IP connections Common services are Telnet, FTP, SMTP, HTTP, ICMP,... nonsecure TCP/IP connections Common services are Telnet, FTP, SMTP, HTTP, ICMP, ARP, DNS, SSH, scp, sftp, and others The significance of TCP/IP as the basis for these services cannot be overlooked TCP/IP provides a platform- and operating -system- independent protocol for these services Any computer, running any operating system, can communicate with any other computer on the network if they both use TCP/IP... always run secure services instead of nonsecure services SSH Secure Shell, also known as SSH, is a secure Telnet replacement that encrypts all traffic, including passwords, using a public/private encryption key exchange protocol It provides the same functionality of Telnet, plus other useful functions, such as traffic tunneling This is what it looks like to SSH into a machine for the first time: [vnavrat@buffy... login program that connects your terminal to a remote machine’s terminal rlogin is an nonsecure protocol, because it sends all information, including passwords, in plain text It also enables an implicit trust relationship to exist between machines, so that you can use rlogin without a password finger finger enables users on remote systems to look up information about users on another system Generally... different criteria, such as remote host address, access time, remote hostname, and remote host domain In the past this kind of access control could be accomplished only with tools like tcpwrappers, or firewall software Even then, tcpwrappers could only reliably control TCP traffic xinetd also takes the extra security step of killing servers that aren’t in the configuration file and those that violate the... certain service, or keep it from running in the first place To control a service, you need to know what spawns it Here is a general listing of what services are spawned from superservers, such as xinetd, and which are started on their own from rc scripts or root The key differences between things that run standalone and those started by the xinetd server is the amount of config information required and availability . RPC call ), such as getattr, read, or write, the number of such operations performed, and the distribution of each operation. For example, 1 0,8 61 getattr operations have been performed, which represents. SMTP, HTTP, ICMP, ARP, DNS, SSH, scp, sftp, and others. The significance of TCP/IP as the basis for these services cannot be over- looked. TCP/IP provides a platform- and operating -system- independent. 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 any- thing else to speed up X. Naturally, hardware