Probleemoplosser gezocht

[asusk7m550]

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]

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]

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.

[asusk7m550]

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]

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?

[ju5t]

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]

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.

[xaban]

Mocht niemand er uit komen wil ik er ook wel naar kijken en ook oplossen Echter niet kosteloos.

[ju5t]

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.