VPS met Magento af en toe opeens erg traag

Citaat:

---

Oorspronkelijk geplaatst door davhog

De oorzaak zou zo maar kunnen liggen in de Disk IO, de storage zal ongetwijfeld op een gedeelde storage server zijn geplaatst. Dit apparaat kan zo maar eens wat overbelast zijn met als gevolg dat de performance van alle VPS'en in elkaar dondert.
De MYSQL server op de VPS zal ook de nodige disk IO veroorzaken, probeer eens in mysql met "SHOW PROCESSES;" te kijken of er processen zijn die erg lang lopen. Zo ja dan verwacht dat deze Queries nogal wat Random reads veroorzaken. De eerste vraag die dan in me op komt is: staan je indexen goed.

Ik hoop dat dit een duwtje in de goede richting is voor je.

---

Bedoel je met show processes, show processlist? (show processes; geeft syntax error)
Dit laat volgens mij geen lang lopende processen zien, zie ik dat goed?:
+-----+----------------+-----------+---------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+----------------+-----------+---------+---------+------+-------+------------------+
| 797 | *** | localhost | magento | Query | 0 | NULL | show processlist |
| 816 | *** | localhost | magento | Sleep | 0 | | NULL |
+-----+----------------+-----------+---------+---------+------+-------+------------------+
2 rows in set (0.00 sec)

Echter, zal ik dit nogmaals eens controleren wanneer de website weer traag is. Aangezien hij nu weer even goed loopt.
Het disk IO verhaal ga ik even uitzoeken. Ben hier onbekend mee.

Bedankt

Citaat:

---

Oorspronkelijk geplaatst door davhog

In wat voor opzicht? Magento draaien zonder opcode cache o.i.d. is in mijn ogen ongeschikt voor productie en veroorzaakt echt bijzonder veel disk IO

---

Dat is juist wat ik aangaf. ik heb goede ervaring met php apc (er zijn meerdere manieren om cahing te doen).
en als ik zo alles van TS heb gelezen neem ik aan dat hij geen php apc gebruikte op dat moment. zelfde om zijn mysql te tunen.

Citaat:

---

Oorspronkelijk geplaatst door Royw

Logs worden nu opgeslagen. Op dit moment werkt de website weer even snel. De output is als volgt:

Wat betreft mysqltuner.pl: Wat doet dit precies? Wijzigt dit script iets? Niet dat mn shop er helemaal uit ligt straks ;)
Ik ga even bekijken wat php APC kan betekenen voor me.

---

Nee mysqltuner geeft je enkel advies.
belangrijk is dat je mysql niet meer geheugen kan gebruiken dan je echt hebt (want dan kan het snel mis gaan)
en zet services uit die je niet nodig hebt om extra mem vrij maken wat je daarna weer voor caching kunt gebruiken

Het is geen kwestie van 'mysql meer ram geven dan je hebt' en mysqltuner moet je zien als een handig tooltje om even een paar dingen voor je uit te rekenen. Maar het is geen tool om een mysql db te optimaliseren.
Je kunt er wel een aantal obvious punten uithalen, denk aan de cacheruimte die je toewijst aan je indexen tov. van de ruimte die je indexen echt in beslag nemen (key buffer), het aantal tijdelijke tabellen dat op disk wordt aangemaakt, het aantal query prunes per dag etc.
Maar de rest van de getallen is een redelijk eenvoudige 'worst case' berekening: stel je hebt je max_connecties op 500 staan en je hebt er maximaal 50 in gebruik, dan kun je hier 'visueel' een hoop ram mee 'verdienen' door het aantal te verlagen, maar je performance is geen ruk beter.
Waar je wel nog snel wat mee kunt scoren is het vergroten van je tmp table cache, heap cache, het moven van je /tmp, /var/tmp naar een ramdisk etc. Dat zijn de meest eenvoudige manieren om wat meer uit mysql te halen en het kost je alleen een paar gb ram (die moet je wel hebben dan, hehe).
90% van de verdere mysql optimalisatie zit hem toch in het knutselen van goede queries en de juiste indexen.

Heb je veel grote tabellen dan kan het ook nog wel eens handig zijn om wekelijks een 'mysql optimize' te runnen. Hierdoor worden je indexen opnieuw aangemaakt waardoor de kardinaliteit kan verbeteren waardoor mysql beter de optmiale index voor een query kan bepalen.

APC is voor het php deel heel handig. Niet om echt te besparen op diskio maar met name op cpu cycles te besparen op het compileren van de php scripts. Heb je ram genoeg dan kun je overigens wel wat diskio besparen, maar veel zal het niet zijn omdat linux het sowieso al in zijn filesystem cached. Anyway, veel ram heb je er niet voor nodig, dus ik zou het toch lekker erbij zetten. (Minder cpu cycles voor php = meer cycles voor mysql tenslotte)

Heb je veel bezoek en denk je dat diskio je bottleneck is, dan kun je eventueel nog besluiten om eens het loggen van apache uit te zetten. In de praktijk zijn deze logs toch maar van beperkt nut en het spaart een hoop aan diskio.

Bedankt voor al jullie tips. Ik ga deze eens bekijken.
Dan rest mij nog één vraag:

De website is niet continu traag. Het kan weken goed gaan en dan opeens (meestal 's avonds) loopt hij totaal niet meer.
Gister was dan een uitzondering, aangezien hij toen bijna 24 uur traag is geweest met af en toe een aantal 'goede' uurtjes.
Wat zou deze traagheidsintervallen kunnen veroorzaken? De webwinkel is nog niet een drukbezochte site, dus een hele hoop bezoekers hebben we ook nog niet?
Of het zijn het bepaalde processen, die op elkaar lopen en op een bepaald moment een top bereiken?

Voor Magento zijn nou eenmaal speciale optimalisaties nodig. Daarnaast ga je met klantgegevens om, dus het lijkt met niet handig dat je zonder enige kennis van Linux die gegevens gaat opslaan. Ik zou dus een Magento pakketje bij een van de gespecialiseerde partijen in NL afnemen, uiteindelijk scheelt dat een hoop kosten.

Welke caching/optimalisatie opties heb je al toegepast in het verleden? Soms kan dit ook een indicatie geven wat mogelijk de traagheid veroorzaakt. Overigens is het lastig veel te zeggen zonder meer te weten over de omgeving. Bijvoorbeeld wat er verder op draait en wat de belasting is over een langere periode.

Citaat:

---

Oorspronkelijk geplaatst door Royw

Het kan weken goed gaan en dan opeens (meestal 's avonds) loopt hij totaal niet meer.

---

Als je niets kunt vinden in je eigen VPS, dan kun je er 99% zeker van zijn dat er iets op de rest van de server in de weg zit. Backups die op een andere VPS gedraaid worden bijvoorbeeld. Je ziet nog wel eens dat een VPS die ongebreideld dataverkeer of diskverkeer gebruikt voor problemen zorgt, al is het maar dat de caching van de host server vol zit.

Zou het kunnen zijn dat je Host net een backup aan het nemen van de Node ? :-)