Howto tune performance

A collection of tips on howto tweak your Bubba.
Post Reply
tor
Posts: 703
Joined: 06 Dec 2006, 12:24
Contact:

Howto tune performance

Post by tor » 25 May 2007, 02:03

This is a short note on how to tune performance on Bubba. It was taken from this thread understanding the power of bubba

Hi,

I cant give you a optimized config file that works in all cases. What i can do is try to give some pointers that most likely will save you some memory depending on how you use the system.

First of. Disable any servers that you aren't using. Ie, streaming servers, ftp, mail and print servers. Only run what you actually use.

Then when running a LAMP system there are two applications that most likely will eat a lot of memory, Apache and MySQL.

When looking at Apache the main source in saving memory is by not running more servers than you actually need. The settings for this can be found in /etc/apache2/apache2.conf and the parameters that is interesting is the section that looks like this:

Code: Select all

<IfModule prefork.c>
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients          20
MaxRequestsPerChild  0
</IfModule>
If the system doesn't have many concurrent users decreasing StartServers, MinSpareServers to say 3 or possibly even 2 instead of five and lower MaxSpareServers to say 5 or 6.

If the system further more occasionally uses a lot of memory it can be good to increase the value of MaxRequestsPerChild say for example 500.

When values are changed restart Apache to apply the changes.

Code: Select all

/etc/init.d/apache2 restart
When one looks at MySQL there are quite a few to fiddle with. Most of this information is based on the provided example config for small systems from the package. More info on this is available in /usr/share/doc/mysql/my-small.cnf

MySQLs config can be found in the file /etc/mysql/my.cnf The interesting parameters can be found in the [mysqld] section.

Parameters to fiddle with and suggested new values.

key_buffer original 16M suggested change 16-32K
max_allowed_packet original 16M suggested change 1M
thread_stack original 128K suggested change 64K
query_cache_size original 16M suggested change 8M

Further more it could perhaps save even more memory by disable query_cache all together by settng query_cache_type to 0

And to do even more adding these parameters to the same section can also be beneficial:

Code: Select all

table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
When changes are made, restart MySQL by issueing:

Code: Select all

/etc/init.d/mysql restart
That said. All above information wont work in all situations, they are targeted to minimize memory consumption. Everything here depends on how Bubba is used. Concurrent users, database size etc. So to find an optimum one most likely will have to test and change and test again.

Other things beyond this that can be interesting to evaluate to squeeze performance out of your Bubba is to look at php-accelerators. They can save CPU cycles if that is the problem. Example on such is Turck MMCache, eaccelerator and APC these however will of course eat memory as well and are not tested in any way by Excito.

To be able to tell if there has been any changes its good to be able to somewhat measure performance of the system. And an easy way to do that is to use the command

Code: Select all

vmstat -1
This command will write some vital statistics on the system every second. The easiest way to use this is to log in via ssh on Bubba and in the terminal start vmstat and pipe output to a file

Code: Select all

vmstat -1 > trace.log
and then while this is running make sure you have a natural load on the system.

When enough tests have been performed kill the vmstat command and evaluate the logfile produced.

There are a lot of interesting information in this file regarding memory and CPU load.

Code: Select all

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0  18452   1840   1648  14532    1    6    15     7  147    42  5  1 93  0
The first two columns tells us how many processes that is runnable at any given moment and how many processes that are blocked in uninteruptable sleep.

Then comes 8 columns that are very interesting memory wise. swpd tells us how much swap that is used. free tells us how much physical memory that is free. buff and cache tells us how much memory Linux uses to buffer and cache data. Then comes si and so that tells us how much data has been swapped in or out from disk. Next is bi and bo that is a measurement of how many blocks have been read and written to and from blockdevices.(Most likely the disk in Bubbas case) The next section tells us about the system in how many interrupts per second we experience and cs the amount of process switches per second. Lastly we have information regarding CPU load. us is the time spent executing in user mode, sy is time spent in kernel mode, id is idle time not used for anything, wa is time spent waiting for IO.

This information can be used to tell if the system is IO-bound, Memory-bound or CPU bound. That will say spending its time waiting for data, waiting for available memory to or from swap or waiting for CPU time to execute.

Depending on what this shows one should take different measurements. Examples above can help when memory is in short demand or if to much time is spent parsing php-pages.

/Tor
Co-founder OpenProducts and Ex Excito Developer

daniel
Posts: 6
Joined: 19 Jan 2008, 11:08

Post by daniel » 25 Jan 2008, 11:02

Another way to check the stuff vmstat is checking, is to run htop, a nice graphical version of top - atleast i found it easy to use, being a linuz newbie :-)

Post Reply