httpd optimization.
Posted by NWSTech, 04-22-2009, 09:57 AM evening all, right ive got a server thats getting battered at the moment by lots of apache processes, ive moved sql off to a seperate box (with private lan so thats fine) but now i need to optimize/replace apache with something less intensive on resources, only problem is im using plesk on this server so i am not sure if i can change the webserver app? any ideas/suggestions using apache 2.2 with prefork mpm server specs Athlon 64 3200+ 4gb DDR2 120Gb HD
Posted by JohnCS, 04-22-2009, 10:02 AM Apache settings are located in httpd.conf, you can use ‘locate httpd.conf’ or ‘whereis httpd.conf’ to find it. Optimal settings for apache should look something like this, I like to keep the min & start servers slightly lower to stop too many child processes spawning & using memory: KeepAlive OnMaxKeepAliveRequests 100KeepAliveTimeout 1MinSpareServers 5MaxSpareServers 10StartServers 5MaxClients 150MaxRequestsPerChild 1000
Posted by NWSTech, 04-22-2009, 11:02 AM only problem is 150 max would cripple my sites (i can easy pull and have see server handle 250-300 clients recently
Posted by CiscoMike, 04-22-2009, 11:20 AM nevermind, I misspoke, mod please delete. (sorry, I posted something inaccurate, I had to retract it)
Posted by mwatkins, 04-22-2009, 11:47 AM NWSTech - you'll need to collect and post your current Apache parameters related to prefork MPM; don't forget ServerLimit, if it is set. I take it you aren't using worker threading for a reason - shared hosting probably, or non thread safe apps?
Posted by NWSTech, 04-22-2009, 12:38 PM current set apache vars are below, i have edited these to try and let server take larger numbers of connections (it should be able to handle more than 300 when it isnt runing sql) and im using prefork due to it being what plesk uses
Posted by lemeneid, 04-22-2009, 01:03 PM KeepAlive Off - that will reduce the amount of ram per process of Apache. So that you can increase other parameters instead.
Posted by expressadmin, 04-22-2009, 01:41 PM As a general rule unless a site is getting utterly hammered by requests, apache not processing requests fast enough is generally a symptom of a lower level issue (I/O bound, swapping, or SQL queries taking too long or ending up in a LOCKED status). I am inclinded to lean towards SQL taking too long to return data, and PHP is holding the apache child in wait status waiting for the SQL server to return the data so that it can continue. Check the output of your SQL server's SHOW PROCESSLIST during periods of high utilization and see if you can indentify specific items that might be causing the SQL server to block processes from completing. Many times a site will simply out grow MyISAM based database tables (full table locking) and need to switch to InnoDB based tables to allow for row level locking instead. You won't notice this, unless you have to watch the SHOW PROCESSLIST very carefully during these periods. Look for bottlenecks elsewhere down the line, as Apache should be able to handle many hundreds of users with little trouble normally. The recommendation for turning off keepalives will help keep child processes free to handle new requests, but will do nothing if the child process is blocked waiting for SQL to return data to it.
Posted by mwatkins, 04-22-2009, 01:56 PM I tend to agree with ExpressColo - further db tuning may be in your immediate future. Yet KeepAlive for many applications makes no sense at all, and can easily cause an escalation in the number of worker processes being created. While application dependant it is generally true for many "click and read" apps: you definitely want to shut KeepAlive off, regardless of any database tuning issues you may have. With your settings above, if my memory serves me correctly, should 200 clients hit your DB more or less at the same time, even if half of the clients make no further requests, 100 of the worker processes started are going to sit around doing nothing for 15s until the request handler times out. During that period, no new requests can be handled by those 100 worker processes. Even if the root cause of the issue is database related, KeepAlive is likely making a bad situation worse.
Posted by NWSTech, 04-22-2009, 02:39 PM the sql server is a dual opteron with 4gb ram and no other services running (no http,ftp etc only ssh and mysql configured to use all available ram)and it has a private 100mb lanto the web server so i am inclined to not think its the sql side, though innodb is something im looking at. have turned off keepaliove and dropped the timeout to 5s also
Posted by expressadmin, 04-22-2009, 03:01 PM My point was more to the SQL query optimization itself. If you have a lot of large tables that are creating temp tables on disk, it wouldn't matter how much RAM you have, you are still going to be bottlenecked on IO. Find out what the SQL server is spending the most time working on, and start optimizing there.
Posted by mwatkins, 04-22-2009, 05:47 PM So NWSTech... any improvement?
Posted by lemeneid, 04-22-2009, 11:42 PM Precisely because this is a sql server which is why apache is of no concern here. Anyway, with regards to databases, having lots of ram means squat if you don't configure it properly. I suggest posting your my.cnf here so we can take a look. Also take a careful look at your web server as it is possible that is the bottleneck instead of the database server.
Posted by mwatkins, 04-23-2009, 02:15 AM While you are posting more info NWSTech, perhaps you could post the average RAM usage of a single active worker process. I suspect if you multiply that by 750 (your ServerLimit) you'll find it far exceeds the available RAM you have. With that in mind, also report on whether swap is in active use when you perceive the machine to be busy; once you've collected that data and if RAM is being maxed out you might consider reducing the ServerLimit radically. In fact you might try reducing it to a couple hundred... which might not feel intuitive... and then have a look at the RAM situation and be prepared to adjust. Last edited by mwatkins; 04-23-2009 at 02:20 AM.