[CentOS 5][Apache] No space left on device

[Multispeed]

Sinds een paar maanden heb ik een vaag probleem...

Elke zondag nacht rond half 5 komt mijn webserver met heel veel foutmeldingen

merg] (28)No space left on device: Couldn't create accept lock or [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock

om dit op te lossen doe ik de Semaphore Arrays van apache leeggooien en me httpd een herstart geven. Zoals je kunt voorstellen ben ik geen voorstander van dit wekelijkse probleem dus zocht ik een goede oplossing.

Na onderzoek blijkt dat mijn 1ste webserver 32 Semaphore Arrays heeft

------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 63537152 apache 600 1
0x00000000 63569921 apache 600 1
0x00000000 63602690 apache 600 1
0x00000000 63635459 apache 600 1
0x00000000 63668228 apache 600 1
0x00000000 63700997 apache 600 1
0x00000000 63733766 apache 600 1
0x00000000 63766535 apache 600 1
0x00000000 63799304 apache 600 1
0x00000000 63832073 apache 600 1
0x00000000 63864842 apache 600 1
0x00000000 63897611 apache 600 1
0x00000000 63930380 apache 600 1
0x00000000 63963149 apache 600 1
0x00000000 63995918 apache 600 1
0x00000000 64028687 apache 600 1
0x00000000 64061456 apache 600 1
0x00000000 64094225 apache 600 1
0x00000000 64126994 apache 600 1
0x00000000 64159763 apache 600 1
0x00000000 64192532 apache 600 1
0x00000000 64225301 apache 600 1
0x00000000 64258070 apache 600 1
0x00000000 64290839 apache 600 1
0x00000000 64323608 apache 600 1
0x00000000 63504409 apache 600 1
0x00000000 64356378 apache 600 1
0x00000000 64389147 apache 600 1
0x00000000 64421916 apache 600 1
0x00000000 64454685 apache 600 1
0x00000000 64487454 apache 600 1
0x00000000 64520223 apache 600 1

Dat terwijl mijn 2de webserver er maar 8 heeft

------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 33095680 apache 600 1
0x00000000 25493505 apache 600 1
0x00000000 33128450 apache 600 1
0x00000000 33161219 apache 600 1
0x00000000 33193988 apache 600 1
0x00000000 33226757 apache 600 1
0x00000000 33259526 apache 600 1
0x00000000 33292295 apache 600 1

Nu ben ik een oplossing aan het proberen die het volgende doet, in /etc/sysctl.conf de volgende 2 regels toevoegen;
kernel.msgmni = 1024
kernel.sem = 250 256000 32 1024


Ik hoop dat dit het probleem voorgoed oplost.... Alleen rijst bij mij wel de vraag waarom heeft mijn ene server zoveel arrays en de andere niet

Beide servers draaien:
CentOS 5
Apache 2.2.16
1ste webserver draait kernel:
2.6.18-194.17.4.el5

2de webserver draait kernel:
2.6.18-53.1.4.el5


Misschien dat iemand mij kan uitleggen waarom er zoveel verschil tussen zit en hoe ik dat kan oplossen, en waarom zou het probleem opgelost zijn met:
kernel.msgmni = 1024
kernel.sem = 250 256000 32 1024

[Thc_Nbl]

Heb je al eens gekeken hoeveel inodes je vrij hebt.

Ik had laatst ook een probleem dat er aangegeven werd dat de schijf vol was, met 6GB nog vrij.
doe eens df -h en df -i
df -h geeft je vrije ruimte in Mb of Gb aan.
en
df -i heeft het aantal vrije inodes aan.

Ik moets het aantal inodes verhogen.

[CrankyGamerOG]

Kun je dit even uitvoeren?

code:

ipcs -s | grep apache | awk ' { print $2 } ' | xargs ipcrm sem

graag gedaan

EDIT :

Lezen, dat doe je dus al , nvm

[ Voor 15% gewijzigd door CrankyGamerOG op 11-11-2010 13:19 ]

[Multispeed]

Schijfruimte heb ik genoeg, Maar hieronder even een paste van de commando's

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 38G 18G 19G 48% /
/dev/sda1 71G 54G 15G 79% /backup
tmpfs 950M 0 950M 0% /dev/shm
/dev/sdb2 76G 184M 72G 1% /httpd
/dev/hdc1 294G 246G 34G 88% /backupnieuw

df -i

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb1 10246368 354306 9892062 4% /
/dev/sda1 19202048 1249 19200799 1% /backup
tmpfs 207715 1 207714 1% /dev/shm
/dev/sdb2 20492736 13 20492723 1% /httpd
/dev/hdc1 39075840 598743 38477097 2% /backupnieuw

[Multispeed]

CrankyGamerOG schreef op donderdag 11 november 2010 @ 13:19:
Kun je dit even uitvoeren?

code:

ipcs -s | grep apache | awk ' { print $2 } ' | xargs ipcrm sem

graag gedaan

EDIT :

Lezen, dat doe je dus al , nvm

Ja klopt..Maar dat is echt tijdelijk helaas..... Plus hierna MOET ik me httpd herstarten

[CrankyGamerOG]

Multispeed schreef op donderdag 11 november 2010 @ 13:21:
[...]


Ja klopt..Maar dat is echt tijdelijk helaas..... Plus hierna MOET ik me httpd herstarten

Ja klopt, dat is inderdaad nodig omdat het lopende process die sema's nog heeft, na de restart zijn ze vrij, je kunt idd via sysctl het wat verhogen.

[Multispeed]

CrankyGamerOG schreef op donderdag 11 november 2010 @ 13:28:
[...]

Ja klopt, dat is inderdaad nodig omdat het lopende process die sema's nog heeft, na de restart zijn ze vrij, je kunt idd via sysctl het wat verhogen.

Okay afwachten tot zondag dus..... Weet jij misschien wel waarom de ene server zoveel sema's nodig heeft ? in vergelijking met de andere ?

[Multispeed]

Zucht..... Gisteren ochtend toch httpd herstarten...

Wat mij vanavond opviel is dat mijn website weer niet bereikbaar was. /var/log/messages zei niks... /var/log/httpd/error_log en access_log zeiden niks in een tail -f...

Echter toen ik top deed viel mij het volgende op..

code:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  599 apache    20   0 49880  16m 5196 S  0.0  0.9   0:00.18 httpd
  662 apache    16   0 63776  29m 5748 S  0.0  1.5   0:00.76 httpd
  697 apache    18   0 62224  27m 5888 S  0.0  1.5   0:01.81 httpd
  851 apache    16   0 57760  23m 5940 S  0.0  1.2   0:03.11 httpd
 1105 apache    16   0 49840  17m 5464 S  0.0  0.9   0:00.58 httpd
 1119 apache    16   0 57648  22m 5788 S  0.0  1.2   0:00.67 httpd
 1121 apache    16   0 52516  17m 5772 S  0.0  0.9   0:00.91 httpd
 1139 apache    16   0 57168  23m 5968 S  0.0  1.2   0:01.57 httpd
 1156 apache    16   0 57220  23m 5712 S  0.0  1.2   0:00.96 httpd

Waarom is OA die VIRT zo hoog ?

Na een service httpd restart doet mijn website het weer wel

[CrankyGamerOG]

OF de site heeft een mem/ander lek, of je apache is gaar

[Verwijderd]

Je kernel op de 2e server is in elk geval ook lek. Daar zijn minstens twee werkende root exploits voor. Ik zou toch maar die kernel upgraden en de server rebooten.

[CrankyGamerOG]

Verwijderd schreef op dinsdag 16 november 2010 @ 09:26:
Je kernel op de 2e server is in elk geval ook lek. Daar zijn minstens twee werkende root exploits voor. Ik zou toch maar die kernel upgraden en de server rebooten.

omg idd ik zie het nu pas

@TS ik zou als de wiedeweerga die kernels upgraden naar minimaal .25

[Multispeed]

Verwijderd schreef op dinsdag 16 november 2010 @ 09:26:
Je kernel op de 2e server is in elk geval ook lek. Daar zijn minstens twee werkende root exploits voor. Ik zou toch maar die kernel upgraden en de server rebooten.

Ondertussen draaien beide servers op kernel-2.6.18-194.26.1.el5, ik heb alleen wel het idee dat er niet alleen iets is met httpd maar ook met sendmail/dovecot..

Ik krijg ook veel mail niet binnen en na een herstart van sendmail/dovecot weer wel... Het lijkt wel of op een bepaald moment alles vast slaat tot ik die deamons een herstart geef. En ik kom er niet achter wat het probleem is ...

Na het uitzetten van de http://code.google.com/p/modpagespeed/ lijkt het probleem weg.. iig wel van de semaphores die vast blijven zitten...

[ Voor 59% gewijzigd door Multispeed op 16-11-2010 15:23 . Reden: modpagespeed disable ]

[Multispeed]

Ik denk zal nog even dit topic afsluiten met een positief bericht....

Na de wijzigingen in de kernel en het verwijderen van de mod_pagespeed blijft apache nu zondagnacht prima draaien..


PS. Ik zal mijn kernel nu up-to-date houden hoor hahaha TNX!

[Rainmaker]

Is t een idee om dit dan even als bug bij modpagespeed te melden?

Wellicht dat je daarmee toekomstige gebruikers een hoop zoekwerk bespaard

[JohnR]

Rainmaker schreef op dinsdag 23 november 2010 @ 21:44:
Is t een idee om dit dan even als bug bij modpagespeed te melden?

Wellicht dat je daarmee toekomstige gebruikers een hoop zoekwerk bespaard

Nee daar is het nu te laat voor. Troubleshooten doe je door 1 ding tegelijk te veranderen. Nu wil je een bug aanmelden in mod_pagespeed zonder enig idee te hebben of daar uberhaupt een bug inzit. Is het niet een kernelbug geweest waar je tegenaan gelopen bent?