PDA

Bekijk Volledige Versie : Probleemoplosser gezocht



Anoniem
23/12/12, 13:35
Voor mijn website azfanpage.nl ben ik op zoek naar iemand die me kan helpen om te achterhalen waarom mijn website elke dag te maken heeft met server crashes. Ik heb een Wordpress website en PHPBB forum en draai deze op een dedicated server (D Dualcore 2.80 GHz - 1 GB ram - 1000GB ruimte - 50000 GB dataverkeer p.m.). Dagelijks noteer ik tussen de 2000 en 3000 unieke bezoekers en dat lijkt me niet genoeg om deze server te laten smelten.

Ik ben nu al wekenlang bezig om de problemen op te lossen, maar doe dit eigenlijk op de verkeerde manier. Ik zou de bron van het probleem eerst moeten achterhalen voordat ik dingen probeer op te lossen, maar omdat mijn kracht niet ligt in de hardwarematige kant van zaken snap ik niet waar ik moet zoeken. Ik ben dus op zoek naar iemand die aan de serverkant wil kijken waar dingen fout gaan zodat ik weet wat er moet gebeuren om het allemaal te verhelpen. Snap ik niet hoe ik dit moet aanpakken (en die kans is groot) kunnen we in onderling overleg wel tot een goede prijsafspraak komen.

asusk7m550
23/12/12, 15:22
Hallo,

Ik kan je hier wel bij helpen. Wat voor hardware heb je en welke OS gebruik je?
Heb je een idee wat er gebeurt met de server? Heb je een systeem wat vast loopt, herstart of reboot? Wat gebeurt er?

t.bloo
23/12/12, 16:43
Goede vragen, maar waarschijnlijk lastig voor TS om antwoord op te geven. Ik of iemand anders willen gerust even kosteloos kijken op je server of het (met onze kennis) snel te achterhalen is. Ik voorspel dat het domweg te weinig geheugen is en dat het aantal apache processen wegloopt en dit opsnoept. Of zo iets.

asusk7m550
23/12/12, 17:06
Zoiets is idd ook mijn eerste gedachte. De load zal waarschijnlijk om hoog vliegen, waarschijnlijk worden er teveel apache processen gestart. Mogelijk een database probleem, verkeerd gebruikt van keys oid.
Bij te weinig geheugen zal het swap geheugen aan worden gesproken, waardoor je disk io verbruikt en alles nog trager gaat werken.

Anoniem
23/12/12, 17:14
Dank voor jullie reacties!

Eerst even de specs:

Processor: Intel Pentium D Dualcore 2.80 GHz
Schijfruimte: 1000 GB
Datatraffic: 5000 GB
Geheugen: 1 GB RAM


DirectAdmin versie: 1.42.1 - CentOS 6.3 x64
PHP versie: 5.3.19
MySQL versie: 5.5.27

Op het moment dat alles soepel loopt zie ik via Putty dat er constant 72 of 73 processen lopen (is dat normaal?). De serverload is op die momenten zo tussen de 0.15 en 0.60 en dat is volgens mij vrij normaal. Op het moment dat het misgaat loopt het aantal slapende processen zo op tot boven de 300 en dat heeft als gevolg dat de serverload makkelijk over de 100 heen gaat. Dat resulteert logischerwijs in een complete vastloper. De oorzaak is voor mij niet te achterhalen, de ene keer gebeurt het op het moment dat ik een artikel publiceer in Wordpress en het andere moment zonder dat ik ook maar wat doe.

In de logs is vast terug te vinden op welk punt het gebeurt, maar ik bezit niet de kennis om die data om te zetten in oplossingen (snap ik gewoon niet).

Het forum is redelijk groot (+500.000 posts), maar wordt niet heel erg druk bezocht tegenwoordig. Gecombineerd met het aantal bezoekers op de website zit ik maandelijks op zo'n 3000 bezoekers en 400.000 pageviews.

Hebben jullie nog meer info nodig?

Anoniem
23/12/12, 17:18
Ik kreeg van mijn webhoster overigens een lijstje met mogelijke problemen. Ik denk dat dit jullie ook meer zegt:

the monitoring gives quite strong results, it's several things in a row going wrong:

- due to the mysql configuration, a change of one line in the session table locks the whole session table, so other users must wate until this lock is released

- during this lock, more and more requests are piling up, the server load increases => MySQL performance drops even more

- due to massive HTTP requests waiting, the server is running out of memory and finally dies.

=====================

How to solve that.

1. this is one of the cheapest servers we have - it will never be able to handle MASSIVE requests!

2. it would be a good idea to setup - until final resolution - a limitation of maximum number of HTTP processes, so the server does not run out of memory (allthough additional users will not be served!)

3. restructuring the session table (eg. to InnoDB with a good primary key) could solve the problem

4. maybe it is better to use a different SESSION storage.

asusk7m550
23/12/12, 18:04
De load van de server geeft aan hoeveel processen er staan te wachten. Normaal gesproken kun je wel zeggen dat een load beneden 1 goed is (dit ligt wel aan het aantal corescwat he hebt, bij 16 cores is een liad onder 16 goed). Daarboven ga je vertraging krijgen aangezien iets ergens op wacht.

Dit kan een aantal oorzaken hebben:
1. De processor heeft het erg druk, dit komt meestal door een script wat niet goed in elkaar zit.
2. Je wacht op disk i/o. Dit kan te maken hebben met een database welke vaak gebruikt word en geen goede indexing heeft, of idd tabellen lockt. Dit kan ook te maken hebben met het gebruikt van je swap space, dit is om tijdelijk je geheugen te vergroten. Als ik systemen tegen kom die de swapruimte in gebruik gaan nemen, betekend dit meestal op korte termijn een probleem. Mijn tegel is altijd, als je je swap nodig hebt, dan heb je meer geheugen nodig.
3. Je kunt ook wachten op het netwerk, maar dan heb je het over systemen welke veel bandbreedte trekken. In jouw geval verwacht ik niet dat dar het probleem is.

Wat de hosting provider zegt klinkt plausible. Maar ik begrijp niet waar je een lock op de database doet. Daar zal naar gekeken kunnen worden. Als hij bedoel dat je ook je sessies opslaat in de database, kun je ervoor kiezen om dit op schijf op te slaan.

Ook ik denk dat je het beste er iemand naar kunt laten kijken, ik wil ook wel gratis een eerste inschatting msken.

Keizer
23/12/12, 18:31
Wat ik vaak zie dat verlaten fora/blogs zo hard volgespamd worden dat de records in de miljoenen lopen. Ja, dan gaat de boel wel haperen.. Maar toevallig deze week nog een probleem geval gehad waar de programmeur een simpele primary key vergeten was in te stellen.

Misschien helpt dit je wat op weg:

Zoek het MySQL da_admin wachtwoord op:


cat /usr/local/directadmin/conf/mysql.conf

Open de MySQL terminal:


mysql -u da_admin -pPASSWORD (zonder spatie)

Kijk wat er open staat op het moment dat je problemen ondervindt:


SHOW FULL PROCESSLIST;

Waarschijnlijk vind je dan een lijst regels die wachten op "copying to tmp table".

Zoals hierboven gemeld, als het om de sessions tabel gaat, probeer deze weg te schrijven op het filesystem en truncate de tabel.

Als het om een andere uit de klauwen gegroeide tabel gaat die er niet zo toe doet (stats, logs, etc) dan zou je misschien de tabel probleemloos kunnen truncaten. (download altijd een exportje via phpMyAdmin!).

Als de probleemtabel wel belangrijk is dan zou je kunnen controlen of er wel een primary key op het ID veld staat. En als de query LEFT JOIN laat zien dan zou je ook kunnen kijken of er indexes zijn op de velden waarop hij die LEFT JOIN uitvoert.

Verder kan je ook nog heel wat doen met caching etc maar met 1Gb RAM weet ik niet of je daar veel aan gaat hebben.

Waarom eigenlijk een dedicated server en niet een shared pakket op degelijke hardware?

Anoniem
23/12/12, 18:53
Keizer,

Dank voor je uitgebreide antwoord. Ik ben op dit moment samen met asusk7m550 in de slag om te kijken of hij dit op kan lossen voor me, want als ik heel eerlijk ben snap ik maar weinig van de tips die je me nu geeft. Qua caching heb ik al het nodige gedaan (Cloudflare + MaxCDN), dus dat zou al moeten helpen. De keuze voor een dedicated lijkt me achteraf gezien ook niet de slimste oplossing, maar ik ben hier ote overgegaan omdat mijn shared hoster me niet meer wilde hebben omdat dezelfde problemen zich bij hem ook al voordeden. Als er iets structureel niet goed zit in een database maakt het volgens mij niet uit wat voor hosting je hebt lopen, denk dat alles dan uiteindelijk vastloopt.

ju5t
24/12/12, 16:01
En ga voor InnoDB in plaats van MyISAM als je last hebt van table locks of kijk naar iets als low_priority_updates. Of je last hebt van table locks kun je kijken naar de informatie uit mysqladmin extended-status, met -u -p voor je username en wachtwoord, of SHOW STATUS als query, en kijk vooral naar Table_locks_waited en Table_locks_immediate.

Dreas
24/12/12, 16:41
Ik wil ook best kosteloos eens kijken als je me SSH toegang geeft. Geen garanties uiteraard ;) Installeer "atop", die houdt ook een hoop informatie voor je bij over geheugen/CPU/disk.

Anoniem
24/12/12, 17:09
Of je last hebt van table locks kun je kijken naar de informatie uit mysqladmin extended-status, met -u -p voor je username en wachtwoord, of SHOW STATUS als query, en kijk vooral naar Table_locks_waited en Table_locks_immediate.

Als ik die query uitvoer dan krijg ik volgens mij (pin me er niet op vast, ik vraag hulp omdat ik het niet snap) verontrustende cijfers (iig heel hoog):


Table_locks_immediate 415940
Table_locks_waited 43

Is dit verontrustend en zo ja, is dat makkelijk op te lossen?

@Dreas: asusk7m550 houdt alles nu al in de gaten via sar en New Relic, dus ik wacht zijn bevindingen eerst even af.

xaban
24/12/12, 19:59
Mocht niemand er uit komen wil ik er ook wel naar kijken en ook oplossen :) Echter niet kosteloos.

ju5t
25/12/12, 11:03
Table locks zou ik me in dit geval geen zorgen om maken. Kwam meer door wat je provider aan gaf dat het probleem was.

Oh en @asusk7m550: ik lees je bericht nu pas goed. Maar MyISAM locked de tabel, al is het maar heel kort, bij iedere update en insert. Daarom kan InnoDB sneller zijn omdat deze aan row level locking doet. InnoDB heeft wel weer wat extra overhead en omdat het meer kan dan dat en voor simpele databases kan het dus sneller zijn om gewoon op MyISAM te blijven. Maar dat table locking zullen ze bij zijn provider bedoelen. Lijkt nergens op gebaseerd te zijn want 43 keer wachten op een lock ten opzichte van de 415940 waar het direct was lijkt mij niet zo'n groot probleem.