'van Sleeuwen, Berry' wrote:
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.
Why not fix the actual source off the resource consumption ?
Webservers like ngix or lighthttpd offer more performance in terms of
requests per second at (sometimes substancially) lower resource consumption.
If you are looking for max performance with little resources I can only
recommend ngix ...
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/
??D>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
Med venlig hilsen / Best Regards
Henrik Johansen
hen...@myunix.dk
----------------------------------------------------------------------
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/
