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/
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this transmission 
is virus-free and will not be

liable for any damages resulting from 
any virus transmitted.

 

On all offers and agreements under 
which Atos Origin supplies goods and/or

services of whatever nature, the Terms 
of Delivery from Atos Origin

exclusively apply. 

The Terms of Delivery shall be promptly 
submitted to you on your request.

 

Atos Origin Nederland B.V. / Utrecht

KvK Utrecht 30132762

Reply via email to