PDA

Bekijk Volledige Versie : Vraagje over storing door Apache memory usage



Tussendoor
15/08/11, 11:48
Hallo,

Wij beschikken momenteel over een managed VPS. We hebben dit nu een jaar geleden afgelosten bij een partij die goed is in het aanbieden van managed oplossingen. Toch zijn wij niet echt tevreden en wel omdat de server om de haverklap vastloopt. In het begin viel dit mee en beperkte het zich tot een aantal x per maand. In de afgelopen drie weken gebeurt het echter dagelijks. Dagelijks (vooral 's nachts) krijgen wij een mailtje van Hyperspin dat de server offline is. Na herstart van de Apache service in Plesk is de server ook direct weer bereikbaar.

Wat opvalt is dat Apache memory usage enorm omhoog schiet (zie screenshot). Het is echter verder niet echt te verklaren en ook de hoster heeft geen idee waardoor dit veroorzaakt wordt. Het zou een website kunnen zijn maar ook een proces dat (vooral 's nachts problemen geeft).

De error: "Error message::server reached MaxClients setting, consider raising the MaxClients setting" komt regelmatig langs maar deze setting is al flink verhoogd. Heeft iemand een verklaring hiervoor? Of beter nog.. wat te doen?

Info:
OS: CentOS 5 + Plesk 10 (Parallels Power Panel Desktop)
Dual QuadCore Xeon CPUs
RAM: 1024MB

9738

dennis0162
15/08/11, 11:58
Als je een Managed VPS af neemt, kan je dit probleem dan niet beter bij je Webhoster voorleggen?

Tussendoor
15/08/11, 12:01
Als je een Managed VPS af neemt, kan je dit probleem dan niet beter bij je Webhoster voorleggen?
Beste dennis0162,

Dit hebben we reeds veelvuldig gedaan. Je wilt niet weten hoeveel support tickets daar openstaan. Maar zoals je ook kon lezen speelt het probleem al langer, oftewel ze komen er niet uit. Vandaar dat ik een ticket hier aanmaak om jullie expertise inzake dit probleem.

websiteondemand
15/08/11, 12:25
Wat draait erop? Het afnemen van een Managed VPS wil nog niet zeggen dat bijvoorbeeld je eigen software voortdurend gedebugd wordt.

Tussendoor
15/08/11, 12:33
Wat draait erop? Het afnemen van een Managed VPS wil nog niet zeggen dat bijvoorbeeld je eigen software voortdurend gedebugd wordt.
Er draaien ongeveer zo'n 25, simpele WordPress websites op. Eigenlijk weinig bijzonders en ook niks zwaars qua processen.

websiteondemand
15/08/11, 12:48
Kunnen maar 2 dingen zijn lijkt me. Leverancier geeft geen prioriteit aan jullie óf ze weten echt niet hoe het moet. Als dit is wat erop draait (resources trekken plugins met evt. memory leaks daargelaten), dan moet het met die config prima te doen zijn.

Ik zou nog een paar keer aan de bel trekken daar en deadline stellen als ik jou was.

Tussendoor
15/08/11, 12:52
Kunnen maar 2 dingen zijn lijkt me. Leverancier geeft geen prioriteit aan jullie óf ze weten echt niet hoe het moet. Als dit is wat erop draait (resources trekken plugins met evt. memory leaks daargelaten), dan moet het met die config prima te doen zijn.

Ik zou nog een paar keer aan de bel trekken daar en deadline stellen als ik jou was.
Gezien het aantal tickets die we hebben aangemaakt wordt er wel degelijk aan gewerkt. Ik krijg idd ook het vermoeden dat ze niet duidelijk krijgen wel proces/website/etc de problemen veroorzaakt. Ik heb persoonlijk weinig ervaring als het gaat om linux hosting maar begrijp ik goed dat precies te achterhalen is welke website/proces voor de Apache memory usage zorgt?

Tussendoor
15/08/11, 12:59
En alweer loopt de server vast. Ik heb nog een extra screenshot gemaakt met extra info wat Plesk aangeeft.

9739

ichosting
15/08/11, 13:05
Is het steeds rond dezelfde tijd? Anders zou je eens met server-stats kunnen kijken wat er rond die tijd gebeurt.
Het is een behoorlijk lange periode dus je zou het kunnen proberen.

Staat er niets geks in de logs nu?

websiteondemand
15/08/11, 13:06
Ja, valt zo te herleiden naar domein en dan kunnen ze er dieper induiken. Beroerde plugins of default config van die bak (apache, mysql tuning) niet goed als je het mij vraagt.

Tussendoor
15/08/11, 13:19
Is het steeds rond dezelfde tijd? Anders zou je eens met server-stats kunnen kijken wat er rond die tijd gebeurt.
Het is een behoorlijk lange periode dus je zou het kunnen proberen.

Staat er niets geks in de logs nu?
Nee, helaas. Dat wisselt. Vaak in de nacht maar dus net ook gewoon overdag. Welke server-stats zou ik hiervoor moeten opvragen?


Ja, valt zo te herleiden naar domein en dan kunnen ze er dieper induiken. Beroerde plugins of default config van die bak (apache, mysql tuning) niet goed als je het mij vraagt.
Als ik idd de domeinnaam heb dan kunnen we verder maar dat is volgens de hoster het probleem.

Zie ook ticket conversatie:

[Fri Aug 12 15:21:03 2011] [error] server reached MaxClients setting, consider raising the MaxClients setting

This happened, even though our technicians had previously already raised this setting from 256 to 512 (which is VERY high).

I need you to understand that this means that something within your server is causing this limit to be reached. In other words; the server itself is actually working properly, it’s just getting overloaded by something you run on the server (and we have no control over what you run on it). This could be caused by just about anything, for example; an incorrectly written script (with for example an infinite loop in it), an external attack on one of the websites, sudden extremely high usage of one of the websites, etc.

What we have done now, is to increase this limit further, from 512 to 1024 (for both MaxClients and ServerLimit).

At this point, the only thing we can do to determine whether this is making any difference, is to wait. Since we don’t know where the high usage is coming from (nor do we have any means to measure that, since you control the websites yourself), we cannot reproduce the situation and we simply need to wait for it to happen again (or preferably for it to not happen again, of course). Every time so far, we could just make some modifications and see whether or not that’s taking effect by waiting, and to take further steps after that. One other thing we can still do, is to completely recompile Apache.

ichosting
15/08/11, 13:33
http://server-ip/server-stats ) moet je trouwens wel even inschakelen in je apache config als dat nog niet is gebeurt.
Staat in directadmin onder /etc/httpd/conf/extra/httpd-info.conf meende ik.

Yourwebhoster
15/08/11, 13:35
Hebben ze iets dat de server-status ophaalt als dit gebeurt? Daar valt uit te lezen wat er aan de hand kan zijn, zoals een slow-lorris attack die al je apache workers opeist. Daar is beveiliging tegen indien dat het geval is.

ichosting
15/08/11, 13:38
Hebben ze iets dat de server-status ophaalt als dit gebeurt? Daar valt uit te lezen wat er aan de hand kan zijn, zoals een slow-lorris attack die al je apache workers opeist. Daar is beveiliging tegen indien dat het geval is.

Dit bedoel je:


cd /root
wget ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/installoris
chmod 755 installoris
./installoris

:)

Maar eerst maar eens uitvinden welke site dit veroorzaakt. Het hoeft natuurlijk geen slow-loris te zijn. Al kan het geen kwaad die module te installeren.

Tussendoor
15/08/11, 13:47
Dit bedoel je:



:)

Maar eerst maar eens uitvinden welke site dit veroorzaakt. Het hoeft natuurlijk geen slow-loris te zijn. Al kan het geen kwaad die module te installeren.

En dat kan dus simpelweg via http://server-ip/server-stats? Dan ga ik de hoster vragen om dat te activeren.

ichosting
15/08/11, 13:49
Nou simpel... het geeft je wel meer inzicht in ieder geval.

Tussendoor
15/08/11, 15:32
Ik heb ze gevraagd of dergelijke statistieken op de server geïnstalleerd kunnen worden. Ik krijg nu net weer de melding dat de recente storing van 2 uren terug weer komt door: server reached MaxClients setting

Weet iemand hier een adequate oplossing voor?

Tussendoor
15/08/11, 15:56
Ik krijg zojuist het volgende per e-mail binnen van Plesk:

Server health parameter "Services > Apache CPU usage" changed its status from "green" to "yellow".

top - 14:51:33 up 1:55, 0 users, load average: 0.19, 0.35, 0.22
Tasks: 52 total, 2 running, 50 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 0.3%sy, 0.0%ni, 98.0%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1048576k total, 370760k used, 677816k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5835 apache 16 0 71156 44m 6368 R 71.6 4.4 0:25.10 httpd
1891 mysql 15 0 113m 23m 5356 S 2.0 2.3 5:08.84 mysqld
1 root 15 0 2072 656 568 S 0.0 0.1 0:00.45 init
1360 root 15 0 23744 1020 776 S 0.0 0.1 0:00.17 rsyslogd
1374 root 15 0 25644 6448 4020 S 0.0 0.6 0:00.18 snmpd
1417 sw-cp-se 18 0 8880 5328 1448 S 0.0 0.5 0:10.88 sw-cp-serverd
1427 root 15 0 7076 1040 636 S 0.0 0.1 0:00.00 sshd
1436 root 15 0 2728 904 728 S 0.0 0.1 0:00.04 xinetd
1449 root 15 0 2844 568 464 S 0.0 0.1 0:00.02 couriertcpd
1452 root 18 0 1664 488 416 S 0.0 0.0 0:00.01 courierlogger
1460 root 15 0 2844 572 464 S 0.0 0.1 0:00.00 couriertcpd
1462 root 18 0 1664 484 416 S 0.0 0.0 0:00.00 courierlogger
1468 root 15 0 2844 568 464 S 0.0 0.1 0:00.03 couriertcpd
1470 root 18 0 1664 484 416 S 0.0 0.0 0:00.00 courierlogger
1477 root 15 0 2844 572 464 S 0.0 0.1 0:00.00 couriertcpd
1479 root 18 0 1664 484 416 S 0.0 0.0 0:00.00 courierlogger
1701 root 15 0 13108 9424 1168 S 0.0 0.9 0:00.32 lfd
1713 qmails 16 0 1716 496 396 S 0.0 0.0 0:00.02 qmail-send
1715 qmaill 18 0 1672 476 408 S 0.0 0.0 0:00.00 splogger
1716 root 15 0 1700 380 288 S 0.0 0.0 0:00.00 qmail-lspawn
1717 qmailr 15 0 1700 388 296 S 0.0 0.0 0:00.00 qmail-rspawn
1718 qmailq 18 0 1668 348 284 S 0.0 0.0 0:00.00 qmail-clean
1788 named 20 0 109m 4364 1976 S 0.0 0.4 0:00.37 named
1835 root 22 0 3620 1304 1128 S 0.0 0.1 0:00.01 mysqld_safe
1944 postgres 18 0 20204 3364 2860 S 0.0 0.3 0:00.60 postmaster
1948 postgres 15 0 9984 816 308 S 0.0 0.1 0:00.00 postmaster
1950 postgres 15 0 20204 1076 568 S 0.0 0.1 0:00.03 postmaster
1951 postgres 15 0 10984 796 288 S 0.0 0.1 0:00.00 postmaster
1952 postgres 18 0 10164 984 372 S 0.0 0.1 0:00.00 postmaster
1999 root 15 0 10424 380 236 S 0.0 0.0 0:00.00 vzctl
2000 root 15 0 3620 1476 1244 S 0.0 0.1 0:00.02 bash
2023 root 15 0 33464 29m 2428 S 0.0 2.8 0:00.92 spamd
2025 popuser 18 0 33464 27m 972 S 0.0 2.7 0:00.00 spamd
3125 root 18 0 45504 21m 8896 S 0.0 2.1 0:00.28 httpd
3127 apache 18 0 31596 10m 468 S 0.0 1.0 0:00.00 httpd
3392 drweb 15 0 120m 115m 552 S 0.0 11.3 0:00.02 drwebd.real
3403 root 16 0 55764 16m 4616 S 0.0 1.6 0:01.75 sw-engine
3412 root 18 0 71704 2240 864 S 0.0 0.2 0:28.65 sw-collectd
3429 root 18 0 4404 1112 568 S 0.0 0.1 0:00.00 crond
3437 root 18 0 5584 712 436 S 0.0 0.1 0:00.00 saslauthd
3438 root 18 0 5584 440 164 S 0.0 0.0 0:00.00 saslauthd
7797 apache 15 0 62652 35m 5940 S 0.0 3.5 0:26.66 httpd
12048 apache 15 0 68152 41m 5952 S 0.0 4.0 0:19.05 httpd
13370 apache 15 0 64676 37m 5888 S 0.0 3.7 0:12.61 httpd
13619 apache 15 0 60656 33m 5536 S 0.0 3.3 0:08.54 httpd
15915 root 15 0 4048 1404 1112 S 0.0 0.1 0:00.00 vi
16082 root 18 0 2196 928 720 R 0.0 0.1 0:00.00 top
17754 root 18 0 10424 384 236 S 0.0 0.0 0:00.02 vzctl
17755 root 16 0 3620 1460 1232 S 0.0 0.1 0:00.00 bash
17837 root 18 0 8340 2068 1572 S 0.0 0.2 0:00.00 su
17838 root 18 0 3756 1604 1284 S 0.0 0.2 0:00.07 bash
32472 root 15 -4 2156 556 344 S 0.0 0.1 0:00.00 udevd

t.bloo
15/08/11, 20:49
Als je maxclients bereikt dan is of je VPS te klein, of er is iets gaande dat al je processen vast houdt. 50 processen op een server is helemaal niet veel, een beetje server heeft er zeker meer dan 100. 1GB geheugen zou ook zeker genoeg moeten zijn voor een paar websites die niets raars doen.

Er zijn een paar opties: je lost het vastlopen op of je herstart apache automatisch als het is vastgelopen. Dat laatste is niet optimaal maar wel beter voor je nachtrust. Je zou kunnen beginnen met de slowloris module, de server-stats, en "atop" om terug te kunnen kijken naar onder andere de disk-IO.

Je zou er met de juiste toegang tot de server snel achter moeten kunnen komen welke website tot het probleem leidt en die eens uitschakelen of op een andere server zetten ofzo.