|
Home >
Reducing Resources
Reducing Resources
The following document can help you manage the various resources for your account.
| Apache |
 |
CPU
Enabling Monitoring:
Apache's CPU usage is best monitored using the server-status feature provided by the module mod_status, with ExtendedStatus set to 'on'. This will let you view detailed information about Apache in your browser by going to http://yourdomain.com/server-status/. If it has not been enabled for your account already, here is how you turn it on:
- You will need to edit the file /etc/httpd/conf/httpd.conf inside your VPS account. We recommend using SSH (http://members.westhost.com/ssh-manual.html) to edit the file, but you may use your online file manager at http://yourdomain.com/fm/ or download the file via FTP and edit the file locally on your computer. If you edit the file locally on your computer be sure to use a text editor that does not replace Linux end-of-line characters with Windows end-of-line characters.
- First, look for the following section, typically located on or around line 377:
#
# ExtendedStatus controls whether Apache will generate "full" status
# information (ExtendedStatus On) or just basic information (ExtendedStatus
# Off) when the "server-status" handler is called. The default is Off.
#
#ExtendedStatus On
You will need to remove the '#' character so the line reads 'ExtendedStatus On' instead of '#ExtendedStatus Off'.
- Next, locate this block of text, which is usually on or around line 1135:
#
# Allow server status reports, with the URL of http://servername/server-status
# Change the ".your-domain.com" to match your domain to enable.
#
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#</Location>
Change the 'location' block to the following:
<Location /server-status>
SetHandler server-status
AuthName "Restricted Area"
AuthType Basic
AuthUserFile /usr/local/apache/.htpasswd
Require valid-user
satisfy any
ORDER allow,deny
allow from 69.36.160.253 69.36.160.254
</Location>
This will cause Apache to prompt you for your main account username and password when you visit your server-status page. If you know your computer's IP address you may also add it after '69.36.160.254' (separated by a space) to automatically be allowed access. It is usually important to keep this secure, as it can potentially reveal things about your website that should be kept secure.
Using 'server-status'
There is quite a bit of information available on the server-status page, but the part which you will be most interested in is the section that looks like the following:
Server uptime: 28 days 15 hours 10 minutes 55 seconds
Total accesses: 2493682 - Total Traffic: 28.5 GB
CPU Usage: u1242.45 s2784.84 cu193635 cs30105.8 - 9.21% CPU load
1.01 requests/sec - 12.1 kB/second - 12.0 kB/request
Perhaps the most significant number here is that the CPU load is 9.21% in this example. This is simply a calculation of the 4 CPU usage values added together (u, s, cu, cs) divided by the server's uptime in seconds. To better evaluate the significance of the number 9.21% it is helpful to divide it into 100 write it as a fraction. In other words, 100/9.21 = 10.9, meaning this account has used 1/10.9 of all available CPU time in the last 28 and a half days. If this server were to have only 10 accounts on it and they were all just like this one then we would have an extremely overworked server on our hands.
The reality of shared hosting is that there are many more then 10 accounts on a server, although the exact number varies quite a bit from server to server.
Limiting CPU usage
The idea is the faster you can make your website, the less CPU time is required to for Apache to serve out your content. Here are some suggestions on common techniques used to do this:
- If your site uses a lot of PHP then try installing the Site Application 'eAccelerator' (note that this requires that you use the most recent version of either the 4.3 development line or 5 development line of PHP). This program will cache PHP scripts in a compiled state, greatly reducing the overhead associated with each hit to that script. Typically this results in a 200%-250% improvement in CPU usage (and therefore helps your website speed). The trade off is 16-32 megabytes of disk space and slightly more RAM to load the eAccelerator library-which is quite a bargain.
- The front page of your website is always going to be a high traffic spot, as it is the doorway into your website. If you have dynamic content on your front page then you probably stand to benefit by automatically dumping this to static HTML content. For example, consider a fictitious news website whose front page is http://example.com/index.php. Their front page shows the top 10 stories for the week, the 10 most recent stories, etc. Typically the content on this page only changes every hour or so. This would be an ideal situation to make a page called 'index.html' that gets automatically updated every hour. This can be done with a cron job (http://members.westhost.com/software-miscellaneous.html#cron) that looks like the following:
0 * * * * wget -O /var/www/html/index.html http://example.com/index.php
This will use the 'wget' program to visit the dynamic index page, take the output and write a static HTML page. Something you'll need to pay attention to is whether 'index.html' or 'index.php' comes first in your 'DirectoryIndex'. For this to work it should be 'index.html', which is the default in all VPS accounts.
- When you view a website your browser needs to download every item necessary to view the page. This means every image, flash document, sound, style sheet and so forth requires your browser to connect to the server, request the item, and download it. If your page has a lot of items then this adds to the overhead of each visit to that page. Reducing the number of items on each page is another easy way to reduce your CPU usage. If you use a lot of small images as part of a menu consider replacing them with an image map and a single image. If you have a blog you can usually change the number of posts to display on each page.
- If you have a dynamic website and you created by yourself then you should take the time to go through your code and evaluate it from a performance perspective. With web languages it is especially easy to write what comes to mind first-but this may not be the most efficient way to do the task.
RAM
Monitoring RAM usage
The best way to check on Apache's RAM usage is to log in via SSH and type the following command:
ps auxw | grep -E '(httpd|%CPU)' | grep -v grep
You will get something similar to the following:
$ ps auxw | grep -E '(httpd|%CPU)' | grep -v grep
| USER |
PID |
%CPU |
%MEM |
VSZ |
RSS |
TTY |
STAT |
START |
TIME |
Command |
| 2007 |
30814 |
0.0 |
0.1 |
49964 |
3920 |
? |
S |
Jul24 |
0:01 |
/usr/sbin/httpd - |
| 2007 |
30864 |
0.1 |
0.9 |
58584 |
29260 |
? |
S |
Jul24 |
21:35 |
/usr/sbin/httpd - |
| 2007 |
30865 |
0.0 |
0.9 |
58128 |
29808 |
? |
S |
Jul24 |
19:52 |
/usr/sbin/httpd - |
| 2007 |
30870 |
0.1 |
0.9 |
58172 |
28804 |
? |
S |
Jul24 |
21:22 |
/usr/sbin/httpd - |
| 2007 |
30871 |
0.0 |
0.9 |
58016 |
27996 |
? |
S |
Jul24 |
19:51 |
/usr/sbin/httpd - |
| 2007 |
30872 |
0.1 |
0.9 |
59384 |
28848 |
? |
S |
Jul24 |
22:37 |
/usr/sbin/httpd - |
| 2007 |
30873 |
0.1 |
0.9 |
57700 |
28456 |
? |
S |
Jul24 |
22:31 |
/usr/sbin/httpd - |
| 2007 |
30875 |
0.0 |
0.6 |
58828 |
19556 |
? |
S |
Jul24 |
17:51 |
/usr/sbin/httpd - |
| 2007 |
30876 |
0.1 |
0.9 |
58384 |
29168 |
? |
S |
Jul24 |
21:38 |
/usr/sbin/httpd - |
| 2007 |
30877 |
0.1 |
0.9 |
57872 |
30176 |
? |
S |
Jul24 |
21:43 |
/usr/sbin/httpd - |
| 2007 |
30878 |
0.1 |
0.9 |
59000 |
29488 |
? |
S |
Jul24 |
21:52 |
/usr/sbin/httpd - |
| 2007 |
30879 |
0.0 |
0.9 |
58464 |
29060 |
? |
S |
Jul24 |
19:55 |
/usr/sbin/httpd - |
| 2007 |
30880 |
0.1 |
0.9 |
58772 |
28724 |
? |
S |
Jul24 |
20:14 |
/usr/sbin/httpd - |
| 2007 |
30881 |
0.1 |
0.9 |
58980 |
29504 |
? |
S |
Jul24 |
20:13 |
/usr/sbin/httpd - |
| 2007 |
30882 |
0.1 |
0.9 |
59056 |
29192 |
? |
S |
Jul24 |
21:05 |
/usr/sbin/httpd - |
| 2007 |
3333 |
0.1 |
0.8 |
55048 |
24796 |
? |
S |
Aug05 |
3:41 |
/usr/sbin/httpd - |
The RAM usage can be calculated simply by adding up the RSS column (residential set size, given in kilobytes). Or, you can run the following one line shell script by cutting and pasting it into your SSH session:
usage=0; for mem in `ps aux | grep httpd | grep -v grep | awk '{print $6}'`; do usage=`expr $mem + $usage`; done; echo $usage
In this case you'll see that the account is using ~416 MB of RAM. The two obvious ways to decrease this is to either decrease the number of Apache processes or for each process to use less RAM.
Limiting the number of Apache processes
In order to limit the number of Apache processes you need to understand Apache's process management. First, let's look at the directives in Apache that govern process creation and what they mean. Note that each process can be thought of as a server and the words are often used interchangeably.
- MaxClients - Limit on total number of servers running, i.e., limit on the number of clients who can simultaneously connect
- StartServers - Number of servers to start initially
- MaxSpareServers, MinSpareServers - Server-pool size regulation. Rather than making you guess how many server processes you need, Apache dynamically adapts to the load it sees --- that is, it tries to maintain enough server processes to handle the current load, plus a few spare servers to handle transient load spikes. It does this by periodically checking how many servers are waiting for a request. If there are fewer than MinSpareServers, it creates a new spare. If there are more than MaxSpareServers, some of the spares die off.
- MaxRequestsPerChild - The number of requests each child process is allowed to process before the child dies. A setting of 0 means unlimited. This value does not include keepalive requests after the initial request per connection.
To better understand what the above directives do let's put them into context. Suppose we have the following values:
· MaxClients 35
· StartServers 8
· MinSpareServers 1
· MaxSpareServers 3
· MaxRequestsPerChild 1000
Any time Apache starts the first thing it does is look at 'StartServers' to know how many servers (processes) to start up. Our configuration file says we need to start 8 servers, and have a minimum of one spare server waiting around. This means 9 processes/servers will initially start up. However, if Apache isn't receiving any traffic then there is no reason to keep all of these idle servers around. Apache will then start killing off servers until 1-3 spare servers are sitting around doing nothing. As traffic picks up then Apache will start up new servers as needed, up to a total of 35 servers. It will spawn them at a rate of 2^n per second (so 1, 2, 4, 8, etc.).
The last thing to look at is MaxRequestsPerChild. Every time your browser needs to download an element off from your server to display a webpage (i.e. a flash document, an image, and an external cascading style sheet are all examples) it needs to make a unique request to Apache to download that element. If you have a page that has 3 images and a cascading style sheet then 5 requests (don't forget the initial request for the page itself) are required to view the page. However, if all 5 requests are made with the same connection (your default configuration in your VPS allows up to 100 requests per connection) then it only counts as 1 request towards the MaxRequestsPerChild limit. It is worth noting that some browsers will tend to use the same connection, while some will open multiple connections at once to download the different elements of a page. Once a child process serves out 1000 requests it will automatically die, freeing up the RAM it had allocated. Usually this is not needed, but you are using a module which has memory management problems then it doesn't hurt to set this option to a finite amount.
By looking at the above you can see that the easiest way to limit the number of processes is to set your MaxSpareServers to something very low (i.e. 2) and to also keep your MaxClients low. What you may give up in exchange is if the MaxClients is ever reached then any new requests will be forced to wait until a server becomes available to handle the request. Any time this occurs you will see a warning in /var/log/httpd/error_log to notify you of this problem unless you have changed the LogLevel for Apache.
Reducing RAM for Apache processes
The easiest way to limit RAM usage for your Apache processes is to only install exactly what you need in your Site Manager. For example, if you don't need mod_perl then don't install it. A good rule of thumb is that Apache will allocate and hold enough RAM to serve your biggest script. If you have one very large script then as soon as it is executed Apache will allocate enough RAM to serve it and won't free it until the processes that handled the request has been killed.
| MySQL |
|
CPU
Directly monitoring MySQL's CPU usage is much more difficult then monitoring Apache's CPU usage. You can see MySQL's CPU usage you by connecting to your account via SSH and typing:
ps auxw | grep -E '(mysql|%CPU)' | grep -v grep
The problem is that it can be very difficult to identify high CPU usage for MySQL just by looking at the process list through 'ps'. Sometimes you can identify problematic queries via SSH using mysqladmin:
$ mysqladmin pro
+---+----+---------+--+-------+----+-----+----------------+
|Id |User|Host |db|Command|Time|State|Info |
+---+----+---------+--+-------+----+-----+----------------+
|554|root|localhost| |Query |0 | |SHOW DATABASES |
|555|root|localhost| |Query |0 | |show processlist|
+---+----+---------+--+-------+----+-----+----------------+
One of the most important things to do with your MySQL databases is to ensure that your tables have indexes and that your queries are making use of those indexes. If you go to http://dev.mysql.com/books/hpmysql-excerpts/ch06.html you will find an excerpt from a book on MySQL performance (see http://dev.mysql.com/doc/mysql/en/slow-query-log.html in reference to the slow query log). The 'Solving I/O Bottlenecks' section provides a great tutorial on finding problems with queries where an index was not used. Just like with Apache, the faster MySQL can do its job the less CPU time is used to do it.
RAM
Because MySQL is multithreaded each process shares the same memory space. When you look at the list of processes running you'll see something similar to:
$ ps aux | grep -E '(mysql|%CPU)' | grep -v grep
| USER |
PID |
%CPU |
%MEM |
VSZ |
RSS |
TTY |
STAT |
START |
TIME |
COMMAND |
| 2007 |
30860 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:07 |
/usr/local/mysql/ |
| 2007 |
30866 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:09 |
/usr/local/mysql/ |
| 2007 |
30867 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:00 |
/usr/local/mysql/ |
| 2007 |
30868 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:00 |
/usr/local/mysql/ |
| 2007 |
30869 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:00 |
/usr/local/mysql/ |
| 2007 |
30874 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:00 |
/usr/local/mysql/ |
| 2007 |
30883 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
1:54 |
/usr/local/mysql/ |
| 2007 |
30884 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
2:02 |
/usr/local/mysql/ |
| 2007 |
30885 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:02 |
/usr/local/mysql/ |
| 2007 |
30886 |
0.0 |
0.9 |
53592 |
28360 |
? |
SN |
Jul24 |
0:02 |
/usr/local/mysql/ |
Notice that the VSZ and RSS sizes are exactly the same for all processes. In this case, MySQL is using 28 megabytes of RAM. One of the first things that you can do is to edit the file /etc/my.cnf and change the line
set-variable = key_buffer=16M
to
set-variable = key_buffer=8M
The difficult thing is that there may be a direct loss in performance by making this change-- possibly even increased CPU usage. The best thing to do is to just try it out and see how it works out.
| Java |
|
RAM
Checking Java's RAM usage is much the same as MySQL, as the SDK and JRE are multithreaded. After you log in via SSH type the following:
$ ps aux | grep -E '(jdk|%CPU)' | grep -v grep
| USER |
PID |
%CPU |
%MEM |
VSZ |
RSS |
TTY |
STAT |
START |
TIME |
COMMAND |
| 2089 |
7061 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:01 |
/var/jdk1.5.0_01/ |
| 2089 |
7067 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:00 |
/var/jdk1.5.0_01/ |
| 2089 |
7073 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
21:26 |
/var/jdk1.5.0_01/ |
| 2089 |
7099 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:02 |
/var/jdk1.5.0_01/ |
| 2089 |
7100 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:03 |
/var/jdk1.5.0_01/ |
| 2089 |
7101 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:00 |
/var/jdk1.5.0_01/ |
| 2089 |
7102 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:04 |
/var/jdk1.5.0_01/ |
| 2089 |
7107 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:00 |
/var/jdk1.5.0_01/ |
| 2089 |
7108 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:09 |
/var/jdk1.5.0_01/ |
| 2089 |
7166 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:52 |
/var/jdk1.5.0_01/ |
| 2089 |
7167 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:00 |
/var/jdk1.5.0_01/ |
| 2089 |
7168 |
0.0 |
2.3 |
269252 |
90200 |
? |
S |
Jul20 |
0:00 |
/var/jdk1.5.0_01/ |
Java's memory allocation size can be set using the parameters '-Xmx' and '-Xms' as described here:
-Xmsn
Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. Examples: "-Xms6291456, -Xms6144k, -Xms6m"
-Xmxn
Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. Examples: "-Xmx83886080, -Xmx81920k, -Xmx80m"
If you are using Tomcat4 inside your VPS the easiest way to set this is to modify the file /usr/bin/dtomcat4. On or around line 44 you'll see the following:
TOMCAT_CFG="/etc/tomcat4/tomcat4.conf"
JAVADIR="/usr/share/java"
Directly below these two lines add in the following line (replacing the numbers 32m as needed):
JAVA_OPTS="-Xmx32m -Xms32m"
You can then restart tomcat4 with the command
/etc/rc.d/init.d/tomcat4 restart
|
