[LUG.ro Mix] Linux tuning

[Horacio]

2010/3/3 Stefano Lendaro <stefano.lendaro en gmail.com>:
>  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
> Lugro-mix en lugro.org.ar
> http://lugro.org.ar/mailman/listinfo/lugro-mix
>