During the 45000 hit/hr how many threads was created by APACHE. You should also look at I/O activities for dasda2, chances are is at 100. There are some apache perforamce you can do, one of them is proxy for static page.
----- Original Message ----- From: van Sleeuwen, Berry [mailto:berry.vansleeu...@atosorigin.com] Sent: Thursday, March 03, 2011 09:45 AM To: LINUX-390@VM.MARIST.EDU <LINUX-390@VM.MARIST.EDU> Subject: Re: Spiking server Perhaps you can look at the threads for the application. We have a very small apache that is configured to have only a few childs and threads within the web server. Granted, it can't service as much threads simultaneously but the server doesn't abend due to memory problems. So the users connecting to the server could experience some more delays during those peaks but usually the server doesn't crash. It does have a high vdisk IO rate during those peaks. Did it indeed crash with all swap space exhausted? In that case, maybe you can consider adding a swapdisk or enlarge an existing one. Regards, Berry. > -----Original Message----- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Bauer, Bobby (NIH/CIT) [E] > Sent: donderdag 3 maart 2011 13:45 > To: LINUX-390@VM.MARIST.EDU > Subject: Spiking server > > We have a Wordpress server that really spikes during certain, know > times of the month, about 45000 hits/hour. Its running on a single z9 > IFL with only 4G of memory on the lpar, z/VM 5.4, REHL 6 (yeah, I know, > more memory, good luck since we are a govt. agency). The user did not > expect this kind of response so we have all been surprised. > > We have Supercache in use. > > At 1G of memory it crashed yesterday due to lack of memory so we upped > it to 2G and are waiting for the next cycle. It has swap space of: > swapon -s > Filename Type Size Used > Priority > /dev/dasda2 partition 1023976 0 > -1 > /dev/dasdb1 partition 194964 0 > 2 > /dev/dasdc1 partition 64976 0 > 1 > > dasda2 is real dasd > dasdb1 and c1 are VDISK defined using the swapgen macro from Sine > Nomine > > this morning the server looks like this: > free > total used free shared buffers > cached > Mem: 2050360 1323728 726632 0 114588 > 345964 > -/+ buffers/cache: 863176 1187184 > Swap: 1283916 0 1283916 > > > So the general question is, are there other steps we can take to help > response time when usage peaks? There are 2 other production servers on > this lpar. One is very low usage, the other has the potential for the > same kind of activity. There is a test lpar sharing the IFL with 4G of > memory also. I've thought of stealing a G from test and moving it to > production. There are plans to host Wiki's on the production lpar also. > Any suggestions would be appreciated. > > Bobby Bauer > Center for Information Technology > National Institutes of Health > Bethesda, MD 20892-5628 > 301-594-7474 > > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 > or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ Please consider the environment before printing this email. Visit our website at http://www.nyse.com **************************************************** Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
