Onderwerp: Slim om up te graden?

Okee, naja, daar heb ik dus weer toegang aan mijn controlpanel voor nodig..

Vannacht is de server er weer uren uit geweest, nu heb ik echt in de apache error log terug kunnen zoeken en de laatste error voor de crash was deze:
[Fri Aug 12 01:52:05 2011] [error] server reached MaxClients setting, consider raising the MaxClients setting

Blijkbaar moet ik dus de MaxClients verhogen, ik moet zeggen dat ik hier verder nog niet van gehoord heb en daar zo meer informatie over ga zoeken. Heeft het verhogen hiervan nog consequenties of hebben jullie andere tips?

Ik zou eerder zoeken wat er precies al je clients opsoepeert, dat zal vermoedelijk een langlopend script zijn.

Hmm okee, zijn er misschien makkelijke tools om snel te vinden welke scripts zo lang lopen? Anders ga ik gewoon even de meest logische dingen langs.

Begin eens met het programma "atop" te installeren en verander in het init script de tijd van 600 seconde in 60 seconde (en even deze daemon herstarten). Als het dan vast is gelopen kun je met "atop -r" makkelijk terugkijken. Je kunt dan om te beginnen al zien of het het aantal processen is, of de disk, of de load, of het geheugen...

Volgens de output van MySQL heb je 1,396 "Slow_queries". Als die worden gelogd dan kan je opzoeken welke queries het langst duren. Je kan in de MySQL configuratie (andere optie in MyPHPAdmin) zien of en waar het slow query log word bewaard.

Verder is aan de output van MySQL ook te zien dat optimalisatie van de MySQL mogelijk loont, d.w.z. het aanpassen van het my.cnf configuratie bestand om bepaalde buffers te vergroten en zo MySQL efficienter te laten werken. Het eerder genoemde MySQL primer (of tuner) script kan hierbij helpen om te suggeren welke waarden je het beste kan aanpassen (vergeet na het bewerken van de MySQL configuratie niet MySQL te herstarten).

De meeste suggesties hier zijn overigens bedoeld om via de command line (via SSH) te worden uitgevoerd trouwens. Ik denk dat je via een control panel niet heel ver komt om het probleem op te lossen.

@t.bloo Hmm, ik denk dat het de processen zijn, ik heb wat dingen gevonden en die heb ik hieronder allemaal beschreven.

@GHDpro Jep, maar ik heb het idee dat die slow queries vooral het gevolg zijn van een probleem dan dat het de oorzaak is. MySQL Tuner gaf inderdaad een aantal waardes aan die ik zou kunnen veranderen, dus daar ga ik straks naar kijken.
De console die ik bedoelde is een java programmaatje op m'n admin panel die verbindt met mijn server via SSH :P




De laatste dagen heb ik zitten monitoren op het moment dat de pieken zijn (00:10 en rond 00:25).
Ik heb gekeken in de cronjoblog, apache error log en heb top zitten monitoren.

Wat ik heb gezien:
Cronjob-log
Aug 15 00:10:01 vps4263 crond[13632]: (root) CMD (echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue)

Deze wordt alleen op dat tijdstip uitgevoerd en daarom lijkt het me logisch dat dit er iets mee te maken heeft.

Apache error log

[Mon Aug 15 00:10:15 2011] [notice] SIGHUP received. Attempting to restart
[Mon Aug 15 00:10:18 2011] [warn] NameVirtualHost 193.23.143.136:80 has no VirtualHosts
[Mon Aug 15 00:10:18 2011] [warn] NameVirtualHost 193.23.143.136:443 has no VirtualHosts
[Mon Aug 15 00:10:21 2011] [warn] RSA server certificate CommonName (CN) `localhost' does NOT match server name!?
[Mon Aug 15 00:10:24 2011] [notice] Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.17 configured -- resuming normal operations

Ik heb van mijn host gehoord dat ik de warnings kan negeren, maar de SIGHUP en de onderste vind ik maar vaag? Lijkt er op dat hij gewoon restart... Ik heb ook een aantal SIGTERMs gezien.

Top
Ik denk dat dit nog het belangrijkst is.
Wat ik rond 00:10 zie is dit:
Het MySQL proces is altijd degene die het meeste CPU en MEM opslurpt, maar "opeens" lijkt die uit te vallen.. hij wordt niet opnieuw gerestart, want ik zie hem verder onderin te lijst, maar dan heeft hij 0% CPU. Ondertussen worden er gigantisch veel apache processen met httpd aangemaakt. Normaal heb ik zo'n 150 processen lopen, maar dan kunnen het er makkelijk 270 worden, waarbij die nieuwe dus allemaal apache-httpd zijn.
Een aantal minuten later neemt dat weer af en pakt de mysql zijn CPU weer en gaat alles weer normaal.



Dit gebeurt elke dag rond 00:10. Het lijkt me dat die cronjob van DirectAdmin er veel mee te maken heeft, maar ik heb niet veel kunnen vinden via google.
Ziet dit er logisch uit en hebben jullie enig idee hoe ik dit kan oplossen?
Als ik mijn statistieken bekijk dan zie ik trouwens ook elke nacht om 00:10 een grote piek (8x de load van normaal ongeveer)

Ik hoop dat ik hiermee genoeg informatie heb gegeven, voor mij is het allemaal te nieuw en al heb ik mijn ideeën durf ik niks te ondernemen voordat er iets gebeurt wat ik niet wil.

Die tally van directadmin geeft op volle servers altijd een flinke load piek, dat is normaal. Wel heb ik die zelf overal op 7 uur gezet en niet om 0:10 uur omdat er nog wel eens iets mis mee wil gaan en ik de problemen dan liever overdag dan 's nachts heb

http://www.directadmin.com/technotes.html
Zoeken naar: The DirectAdmin Task Queue (dataskq):

@t.bloo Hmm, dat is wel een goed idee inderdaad, omdat er veel Amerikanen op mijn spel spelen is het rond die tijd juist het drukst.
Opzich telt die tally dus alleen maar gebruikte resources, toch?

@Rollerscapes Bedankt! Dat klaart een hoop op.


Nu vraag ik me wel af, deze hoge load hoort misschien zo, maar zijn die fouten bij de apache error log ook normaal? Want dat zorgt ervoor dat het spel down is voor enkele minuten, en soms meer.

Zou dit ook het script kunnen zijn die de MaxClients error oproept?
"[Fri Aug 12 01:52:05 2011] [error] server reached MaxClients setting, consider raising the MaxClients setting"

Dit is echt wel bijna 2 uur later, dus dat lijkt me ook wel weer raar.

Oorspronkelijk geplaatst door Wuggles

Nu vraag ik me wel af, deze hoge load hoort misschien zo, maar zijn die fouten bij de apache error log ook normaal? Want dat zorgt ervoor dat het spel down is voor enkele minuten, en soms meer.

Die fouten bij httpd/apache zijn geen echte fouten, de SIGHUP is normaal, dat wil zeggen dat er een herstart aangevraagd is. De tally kuist de logfiles op van apache en daardoor moet apache herstarten om de nieuwe log files te kunnen gebruiken. Dit is overigens bij elke logrotate die je gebruikt van toepassing, de "no VirtualHosts" kan je inderdaad negeren dit komt omdat er op dat ip nog geen websites (domains, hosts) in gebruik zijn. De localhost fout kan je oplossen door je FQDN te gebruiken in je httpd/apache config.