PDA

Bekijk Volledige Versie : VPS met Magento af en toe opeens erg traag



Royw
11/09/12, 11:09
Hallo allemaal,

Ik heb een Magento website draaien bij strato (http://www.strato.nl/server/virtual-server/ - Linux server M)
Deze draait over het algemeen redelijk.

Echter, af en toe wordt hij opeens ontzettend traag en vaak zelfs niet bereikbaar.
Ik heb 2gb RAM en 1 gb RAM garantie.
Mijn vermoeden is dat iemand anders op dezelfde server veel traffic heeft, waardoor mijn RAM wordt teruggedraaid, die dan net te weinig is voor Magento.
Kan ik dit ergens controleren?

Als ik free -m intik in Shell zie ik deze gegevens:
Lees ik het goed, dat ik niet tegen mijn ram geheugen aan loop?



total used free shared buffers cached
Mem: 2048 519 1528 0 0 0
-/+ buffers/cache: 519 1528
Swap: 0 0 0


Uptime zegt:

10:02:38 up 56 days, 23:29, 1 user, load average: 14.23, 13.87, 11.97 <- dit is erg veel of niet?

en Iftop zegt:


TX: cumm: 18.8KB peak: 33.2Kb rates: 0b 1.27Kb 4.70Kb
RX: 2.83KB 4.24Kb 208b 208b 725b
TOTAL: 21.6KB 34.6Kb 208b 1.47Kb 5.41Kb


Ik ben geen expert in serverbeheer. Deze cijfers geven mij een vermoeden, maar dat weet ik dus niet zeker.
Hebben jullie enig idee waar dit aan kan liggen? Moet ik de server update zodat ik altijd 2gb RAM garantie heb?
Of ligt het probleem ergens anders?

Ik hoor graag van jullie, want een webwinkel ligt plat nu!

SF-Jeroen
11/09/12, 11:16
Zo te zien ligt het niet aan je RAM geheugen, er wordt immers nog niets geswapped. Ik zou eerder denken aan een tekort aan CPU kracht. Kan je eens een top uitdraai geven wanneer het probleem zich voordoet. Daarnaast neem ik aan dat je wel enige optimalisaties speciaal voor Magento hebt gedaan?

vDong
11/09/12, 11:17
Wat je graag wil is dat je de prestaties plot (met bv cacti) zodat je kan zien wat er net voor en net na je "downtime" gebeurd.
Dit is ook handig als je aan je leverancier wil aantonen dat de prestaties onder de maat zijn.

Wat voor virtualisatie is dit eigenlijk? Ik vind het namelijk erg bijzonder dat een server zonder swap,buffers en cache draait.

De load hoeft niets ernstigs te zijn, het is meer een indicatie dat processen aan het wachten zijn op resources. Zonder analyse van de oorzaak erachter kan je niks zeggen of dat getal hoog of laag is

vDong
11/09/12, 11:18
Zo te zien ligt het niet aan je RAM geheugen, er wordt immers nog niets geswapped. Kijk nog eens, welke swapspace kan er heen geswapt worden?

SF-Jeroen
11/09/12, 11:19
Oh iets te snel gekeken. Maar dan nog is er genoeg geheugen vrij, is dit tijdens de problemen?

Royw
11/09/12, 11:26
Top uitdraai

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13761 popuser 18 0 40036 33m 2552 R 4.6 1.6 3:12.76 spamd
1 root 15 0 2472 1324 1160 S 0.0 0.1 0:10.12 init
1177 root 15 0 2304 780 712 S 0.0 0.0 0:06.80 cron
1208 syslog 15 0 1916 648 536 S 0.0 0.0 1:31.22 syslogd
1292 root 15 0 5472 1816 1708 S 0.0 0.1 6:49.17 sshd
1304 bind 20 0 49612 2376 2132 S 0.0 0.1 0:00.07 named
1320 root 15 0 3292 528 500 S 0.0 0.0 0:00.12 couriertcpd
1323 root 18 0 1688 456 436 S 0.0 0.0 0:00.00 courierlogger
1332 root 18 0 3292 508 500 S 0.0 0.0 0:00.00 couriertcpd
1334 root 18 0 1688 456 436 S 0.0 0.0 0:00.00 courierlogger
1342 root 15 0 3292 556 504 S 0.0 0.0 0:10.78 couriertcpd
1344 root 15 0 1688 492 436 S 0.0 0.0 0:03.70 courierlogger
1352 root 18 0 3292 512 500 S 0.0 0.0 0:00.00 couriertcpd
1354 root 18 0 1688 444 436 S 0.0 0.0 0:00.00 courierlogger
1441 root 18 0 50196 16m 9244 S 0.0 0.8 0:00.70 apache2
1442 www-data 15 0 27304 4620 464 S 0.0 0.2 0:00.00 apache2
1445 root 18 0 5736 1524 1416 S 0.0 0.1 1:06.26 master

Server is niet bewust geoptimaliseerd voor Magento. (ik ben redelijk nieuw met magento en vooral op server gebied)
Kan ik dit zelf alsnog doen? of is dit iets wat aan de kant van de hoster ligt? Strato biedt namelijk geen voor magento geoptimaliseerde servers.

t.bloo
11/09/12, 11:27
atop installeren (beste even op een korte tijd zetten in /etc/init.d/atop), terugkijken met atop -r als er een probleem is geweest

je ziet daarin ook wat de disk doet en dat zou wel eens de oorzaak kunnen zijn

Royw
11/09/12, 11:28
Alle statisitieken zijn van nu, en dus tijdens de problemen ja.
Het typische is, dat de problemen over een paar uur ook opeens over kunnen zijn. Hoewel het nu al sinds gisteravond loopt.

t.bloo
11/09/12, 11:28
Strato biedt namelijk geen voor magento geoptimaliseerde servers.
Iets met peanuts...

Goede tip is om de innodb tables in losse files te zetten, dan heeft de disk het minder zwaar. Verder even mysql tunen natuurlijk.

Royw
11/09/12, 11:29
atop installeren (beste even op een korte tijd zetten in /etc/init.d/atop), terugkijken met atop -r als er een probleem is geweest

je ziet daarin ook wat de disk doet en dat zou wel eens de oorzaak kunnen zijn

Ik doe waarschijnlijk iets fout?
root@h1939728:~# /etc/init.d/atop
-bash: /etc/init.d/atop: No such file or directory

SF-Jeroen
11/09/12, 11:30
apt-get install atop

t.bloo
11/09/12, 11:31
(zucht...)

is het een debian/ubuntu installatie? Dan eerst "apt-get install atop" en die file editen laat maar zitten.

Royw
11/09/12, 11:33
(zucht...)
Wat ik zeg, ik ben nieuw met servers.

Atop output:

10418

Royw
11/09/12, 11:37
As we speak, lijkt de website weer normaal te reageren.. :S Bovenstaande resultaten zijn dus van normaal lopende versie...
Vreemd toch??

mgielissen
11/09/12, 11:49
Waarschijnlijk is de gebruikte virtualisatie openvz, dan heb je geen swappage. Waarschijnlijk laat TOP de algemene load zien van de hardwarenode.

Royw
11/09/12, 12:02
En de website is weer traag... Heel wisselend vandaag.

Royw
11/09/12, 12:34
Toen Magento een keer niet kon openen, plaatste Magento deze logfile:
Wellicht zegt dit wat? Dit gebeurt af en toe. Maar meestal is hij gewoon erg traag.


a:4:{i:0;s:109:"SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)";i:1;s:3179:"#0 /var/www/vhosts/domain.nl/httpdocs/lib/Zend/Db/Adapter/Pdo/Mysql.php(96): Zend_Db_Adapter_Pdo_Abstract->_connect()
#1 /var/www/vhosts/domain.nl/httpdocs/lib/Varien/Db/Adapter/Pdo/Mysql.php(300): Zend_Db_Adapter_Pdo_Mysql->_connect()
#2 /var/www/vhosts/domain.nl/httpdocs/lib/Zend/Db/Adapter/Abstract.php(459): Varien_Db_Adapter_Pdo_Mysql->_connect()
#3 /var/www/vhosts/domain.nl/httpdocs/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SET NAMES utf8', Array)
#4 /var/www/vhosts/domain.nl/httpdocs/lib/Varien/Db/Adapter/Pdo/Mysql.php(389): Zend_Db_Adapter_Pdo_Abstract->query('SET NAMES utf8', Array)
#5 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Resource.php(169): Varien_Db_Adapter_Pdo_Mysql->query('SET NAMES utf8')
#6 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Resource.php(110): Mage_Core_Model_Resource->_newConnection('pdo_mysql', Object(Mage_Core_Model_Config_Element))
#7 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(320): Mage_Core_Model_Resource->getConnection('core_read')
#8 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(335): Mage_Core_Model_Resource_Db_Abstract->_getConnection('read')
#9 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(355): Mage_Core_Model_Resource_Db_Abstract->_getReadAdapter()
#10 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Resource/Db/Collection/Abstract.php(134): Mage_Core_Model_Resource_Db_Abstract->getReadConnection()
#11 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Config.php(1350): Mage_Core_Model_Resource_Db_Collection_Abstract->__construct(Object(Mage_Core_Model_Resource_Websit e))
#12 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Config.php(1386): Mage_Core_Model_Config->getModelInstance('core_resource/w...', Object(Mage_Core_Model_Resource_Website))
#13 /var/www/vhosts/domain.nl/httpdocs/app/Mage.php(460): Mage_Core_Model_Config->getResourceModelInstance('core/website_co...', Object(Mage_Core_Model_Resource_Website))
#14 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Abstract.php(208): Mage::getResourceModel('core/website_co...', Object(Mage_Core_Model_Resource_Website))
#15 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/Abstract.php(213): Mage_Core_Model_Abstract->getResourceCollection()
#16 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/App.php(598): Mage_Core_Model_Abstract->getCollection()
#17 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/App.php(456): Mage_Core_Model_App->_initStores()
#18 /var/www/vhosts/domain.nl/httpdocs/app/code/core/Mage/Core/Model/App.php(342): Mage_Core_Model_App->_initCurrentStore('', 'store')
#19 /var/www/vhosts/domain.nl/httpdocs/app/Mage.php(640): Mage_Core_Model_App->run(Array)
#20 /var/www/vhosts/domain.nl/httpdocs/index.php(103): Mage::run('', 'store')
#21 {main}";s:3:"url";s:56:"/paht/path/file.html";s:11:"script_name";s:10:"/index.php";}

SF-Jeroen
11/09/12, 12:37
Doe eens "tail /var/log/mysql.log" en post de output hier.

Royw
11/09/12, 13:15
tail /var/log/mysql.log geeft geen resultaten. Ik heb met vi in het bestand gekeken, ook niets te vinden. Ziet er naar uit dat er dus geen logs worden opgeslagen? of geen logs zijn?

Flaxe_eu
11/09/12, 13:45
dan moet je de log ff aanzetten in je my.cnf

Ik zou ook eens mysqltuner.pl (http://mysqltuner.pl/mysqltuner.pl) runnen als de vps een paar uur draait.
dit kan soms heel wat load schelen als je je mysql voor magento een beetje doet optimize

Flaxe_eu
11/09/12, 13:48
en ik heb goede ervaring met php apc samen met magento shops.
is zo op een server gezet en weinig tot geen config nodig.

davhog
11/09/12, 14:13
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.

davhog
11/09/12, 14:15
en ik heb goede ervaring met php apc samen met magento shops.
is zo op een server gezet en weinig tot geen config nodig.

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

Royw
11/09/12, 14:16
Logs worden nu opgeslagen. Op dit moment werkt de website weer even snel. De output is als volgt:

tail /var/log/mysql.log
137 Query select count(*) into @discard from `psa`.`Cards`
137 Quit
138 Connect debian-sys-maint@localhost on
138 Query select @@version_comment limit 1
138 Query select count(*) into @discard from `psa`.`ClientsTraffic`
138 Quit
139 Connect debian-sys-maint@localhost on
139 Query select @@version_comment limit 1
139 Query select count(*) into @discard from `psa`.`Components`
139 Quit

Denk dat dit nu in orde, of niet?

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.

patrickekkel
11/09/12, 14:21
Als je twijfelt moet je een systeem beheerder inhuren.
Dan weet je zeker dat het goed komt.

Royw
11/09/12, 14:27
Als je twijfelt moet je een systeem beheerder inhuren.
Dan weet je zeker dat het goed komt.

Klopt, als ik de middelen zou hebben, zou ik alles uit handen geven.
Helaas ben ik nu op mezelf aangewezen én wil/kan ik er ook wat van leren. Win win toch?

systemdeveloper
11/09/12, 14:33
Win win toch?
Hoeveel brengt een webshop die down is dan op?

t.bloo
11/09/12, 14:33
Mysqltuner stelt veranderingen voor aan de configuratie, maar past die zelf niet aan. Misschien is het beter als je oefent op een niet productie machine.

(offtopic: ken je die calve reclame van "pietertje"? als je ergens niet handig in bent dan moet je het misschien niet doen)

patrickekkel
11/09/12, 14:45
Zolang het goed gaat is het een win win.
Maar als je dan plat gaat heb je zeker geen win win situatie

Royw
11/09/12, 14:56
Mensen, laten we even in oplossingen denken in plaats van redenen verzinnen waarom ik hier niet aan had moeten beginnen of het moet uitbesteden. Hier kan ik er ook wel 100 van verzinnen, maar ik wil het nu eenmaal leren.

Als je ergens niet handig in bent, máár het wilt leren; Dan kun je dat ook. Daar sta ik voor.
Het spotje van Calvé (overigens erg sterk) gaat over je talenten benutten en zegt niets over stoppen waarmee je minder goed bent.

Ik zal mysqltuner eens proberen.

Royw
11/09/12, 15:05
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

Flaxe_eu
11/09/12, 16:49
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.




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

systemdeveloper
11/09/12, 17:14
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.

Royw
12/09/12, 10:19
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?

SF-Jeroen
12/09/12, 10:23
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.

Mark17
12/09/12, 22:56
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.

t.bloo
12/09/12, 23:14
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.

ptimo3
13/09/12, 02:02
Zou het kunnen zijn dat je Host net een backup aan het nemen van de Node ? :-)