2010/3/3 Stefano Lendaro <[email protected]>: > Hola a todos,
Heee! que haces estefanito... disfrutando de la buena vida en Suiza... xD > > From www.linux.com ( > http://www.linux.com/learn/tutorials/290179-five-tools-for-measuring-and-improving-linux-system-performance- > ) Espero puede ser util y interesante ;-) > > Stefano > > > Five > T<http://www.linux.com/learn/tutorials/290179-five-tools-for-measuring-and-improving-linux-system-performance->ools > for Measuring and Improving Linux System > Performance<http://www.linux.com/learn/tutorials/290179-five-tools-for-measuring-and-improving-linux-system-performance-> > Monday, 01 March 2010 10:29 Joe 'Zonker' > Brockmeier<http://www.linux.com/community/profile?userid=107> > > Out of the box, Linux runs just fine for many uses. But if you find yourself > needing to ferret out performance problems or tune the kernel for better > performance, Linux has more than enough tools to measure and tweak system > performance. In this guide, we'll take a look at five of the best utilities > to measure system performance and tweak the Linux kernel. > > You'll find many, many, *many* utilities for measuring and improving Linux > system performance. The utilities discussed here are chosen because they're > widely available, and provide a good scope functionality. Also, I chose to > avoid tools that have too steep a learning curve. As an example, > SystemTap<http://sourceware.org/systemtap/>is > a bit more complex than should be covered in an overview article. I left out > some of the more basic tools such as *ps* and *top* because most Linux users > are exposed to them fairly early on. And I didn't try to tackle any > application-specific tools. > > This won't be the last word on system performance and administration on > Linux.com, so don't worry. In future tutorials, I'll dive in a bit deeper > with specific tools and tuning: but this should be a good starter kit for > newer Linux admins. > KDE System Monitor > > The KDE System Monitor and GNOME System Monitor are both good for getting a > quick visual representation of the state of your system. For me, the KDE > System Monitor has a bit of an edge over its GNOME counterpart because it > allows you to monitor remote systems in addition to the local host, so we'll > look at that one in a bit more depth. Of course, you can run the KDE System > Monitor on a GNOME desktop, and the accompanying daemon that provides data > can be run on a system without a desktop environment at all. > > If you don't have the KDE System Monitor installed, look for a package > called ksysguard. You'll also want to install ksysguardd, which is the > daemon that provides data to KDE System Monitor frontend. > > Once installed, just run the KDE System Monitor from the menu or > *ksysguard* from > the command line. When it starts up, you'll see three tabs by default that > include a process table, system load, and read/write totals for the system > disks. Nice, but hardly all of what this tool can do. KDE System Monitor has > a set of "sensors" that can be used to display memory usage, CPU load, disk > throughput, network activity, and more. > > To fire up your very own custom monitors, go to File -> New Tab. You'll be > asked to specify the number of rows and columns for the tab. I usually opt > for one to four monitors per tab. Once you've added a tab, you can drag one > or more of the sensors to one of the cells on the tab. It's not entirely > obvious, but you can have more than one sensor per cell. So, for instance, > if you would like to have the free and used memory in swap displayed in a > single cell, you can do that. > > If you want to monitor a remote system, go to File -> Monitor Remote > Machine. Assuming you have ksysguardd running on the remote host, you should > be able to just accept the defaults. You'll probably want to have an SSH key > set up so you don't need to provide a password to log into the remote > system, as the default connection is made over SSH. > > When you've set up a tab to your liking, you can save it for later use. KDE > System Monitor will save the file as a *.sgrd* file. KDE System Monitor is > extremely easy to use, and shouldn't take much time to get set up to be > useful. The only real problem with this tool is that it's mostly targeted at > real-time monitoring, and doesn't have a logging option. > Monitor Your System With Dstat > > Like the KDE System Monitor, *dstat* is a sort of general-purpose system > profiling tool, but it's CLI-based. I like *dstat* for a number of reasons. > First, because it covers all the bases: it's usable to log data or view it > in real time; it can show CPU load, disk I/O, network receive/send, etc. It > also produces colorized output at the console, which makes it somewhat > easier to scan results quickly. > > Dstat is written by Dag Wieers <http://dag.wieers.com/home-made/dstat/>. > Unlike some of the performance tools, it includes a decent amount of > documentation. And it's extensible; plugins can be added to Dstat with > Python. If you want to analyze your data later, you can use the > *--output* option > to write the information to a CSV file suitable for import into > OpenOffice.org, Gnumeric, or whatever your favorite spreadsheet might be. > > If you want to see a "full" output that includes CPU usage by CPU (for SMP > systems), disk read and write, network traffic, and paging, use *dstat -f*. > > The most recent version of dstat ships with quite a few plugins that are > suitable for servers and personal systems. This includes plugins to examine > MySQL performance, Postfix, Sendmail, Qmail, and much more. You can combine > the plugins with built-in functions of dstat as well. So, for instance, if > you want to watch MySQL I/O along with the *-a* (all) option, you can > use *dstat > --mysql-io -a*. Some experimentation may be required and not all options can > be combined with other options. > > One word of caution: *dstat* can have some impact on system performance > itself. You might want to profile the plugins you're using and get a > baseline of system performance running with dstat to make sure that you're > accounting for its impact. See the performance.txt file under the docs > directory in the dstat > <http://dag.wieers.com/home-made/dstat/#download> tarball. > Packages are available for quite a few distros as well, though the pointers > on the dstat site itself may lead to some older releases. (For example, > Ubuntu Breezy, which is a bit long in the tooth at this point.) > The Sysstat Auite > > Sysstat is actually a collection of > several<http://pagesperso-orange.fr/sebastien.godard/features.html> > utilities, > including *sar*, *iostat*, *mpstat*, and *pidstat*. You'll actually find a > few versions of *sar* floating around. There's the *atsar* package, and sar > included with the *sysstat*package. Here we're going to look at the sysstat > tools, but you might run into slight variations if you're using the atsar > version. > > Why am I mentioning this one if I've already covered *dstat*? The individual > tools in the sysstat suite are good to know, and you might want to > familiarize yourself with the "standard" tool that is pre-packaged and more > widely available. > > The *sar* utility is good for collecting data over the long term. When you > install the sysstat package on most distros, it will automatically add cron > jobs that will collect data to be displayed with sar. Note that you can get > a good graphical display of sar data using the > isag<http://www.volny.cz/linux_monitor/isag/index.html> package > or kSar <http://ksar.atomique.net/>. > > Just running *sar* will show CPU usage. *sar -b* will give you information > about I/O being written and read from discs, and *sar -B* will give you > paging information. The *sar -A* command will display pretty much all of the > day's data, including reads and writes by partition, memory usage, paging > information, and much more. > > The *pidstat* utility can be used to display a great deal of information > about processes running on a system. You can examine one process or all > active processes. For example, running *pidstat -r 5* will display running > processes that have page > faults<http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/admin-primer/s1-memory-virt-details.html> > and > show how many are minor and major faults. A lot of major page faults and you > will start seeing serious performance problems. This can help nail down > which processes are the problem. > > The *iostat* command will let you get a quick read (get it?) on I/O stats > for the CPU, local disks, and NFS mounts. You can opt to view all devices or > narrow down by device. The *mpstat* command will let you see the CPU usage > and idle information for the system and by individual CPUs. It takes some > practice to become adept at using the sysstat suite, but it's worth > learning. > Network Monitoring with Ifstat > > The *ifstat* utility is to network interface activity what iostat is to > device I/O and CPU activity. You can use it to display activity on one or > more network interfaces. When you run *ifstat* without any arguments or > options, it will display the traffic for your standard network interfaces. > You can specify one or more interfaces, and add a few options to make the > results easier to read and work with. > > If you're running *ifstat* on a system that has unused or idle interfaces, > use *ifstat -z* to hide interfaces that are idle (for example, a system with > VMware that may not be using all the vmnet interfaces at the time). > > To see all the bandwidth being pushed by a system, the *-T* option tells * > ifstat* to display a total of all interfaces in addition to the individual > tallies. To add a timestamp at the beginning of each line, use *-t*. By > default the information is updated every second. If you want to crank this > down a bit, you can specify a delay by adding a number at the end of the > command. So, *ifstat -Tt 3* will give you a display with the count updated > every three seconds, and a total tally at the end of the display. > > Finally, if you only want *ifstat* to run a few times, you can specify a > second number to tell it to repeat that many times. To update 10 times, for > example, you might use *ifstat -tT 5 10* to get 10 updates five seconds > apart. Generally speaking, ifstat is easy to use and get started with. > Tune the Linux Kernel with Sysctl > > When it comes to actual performance tuning, you'll want to know *sysctl*. > The *sysctl* utility is actually used to configure kernel parameters stored > in /proc/sys/. The parameters will change with each kernel version, and how > it's configured. To see all the parameters that are available, run *sysctl > -a*, or *sysctl -a | sort* if you want them alphabetically. > > It should go without saying that if you're going to tweak these settings you > should either be working on a test system, or be quite sure what you're > doing. Or both. Preferably both. > > To change one of the parameters, run *sysctl -w key.value="newvalue"*. Note > that this will only hold the change until the next time the system is > rebooted. To make a setting permanent, you can add it to*/etc/sysctl.conf*. > > That's all for now. If you're interested in doing some further, more > in-depth, reading you'll want to start with IBM's Redbooks Guide Linux > Performance and Tuning > Guidelines<http://www.redbooks.ibm.com/redpapers/abstracts/redp4285.html>, > which is relatively current (updated April 2008) and specifically looks at > Red Hat and SUSE Linux. It's a good, detailed look at performance tuning. > _______________________________________________ > Lugro-mix mailing list > [email protected] > http://lugro.org.ar/mailman/listinfo/lugro-mix > _______________________________________________ Lugro-mix mailing list [email protected] http://lugro.org.ar/mailman/listinfo/lugro-mix
