Bekijk Volledige Versie : VPS Memory issue
Hoi, ik heb een probleem met een website op mijn VPS
Het (vrije) geheugen in top na een restart is gemiddeld 700MB(/1GB)
Na het bezoeken van (een van de) sites in willekeurige browser knalt het geheugen meteen 150-200 MB naar beneden, de specs van de site zijn niet grootst dus vind ik dit erg vreemd. De enige reden die ik kon bedenken is een scriptje wat gebruikt wordt voor image resizing (timthumb)
(http://timthumb.googlecode.com/svn/trunk/timthumb.php)
Dit script draait op WordPress (verder zonder cache gerelateerde plugins) Als ik de betreffende site niet bezoek blijft het geheugen wel stabiel, maar zodra ik deze wel heb bezocht knalt ie dus paar honderd MB naar beneden en lijkt het ook alsof hij elke minuut in zakt tot ie na (kwartier?) nog maar op 60MB vrij zit
Daarna wil de machine nog wel eens crashen binnen paar uur.. Het gekke is dat de machine ook wel eens 45 dagen achtereen heeft gedraait en er wezelijk niets veranderd is
Kan ik dit 'makkelijk' pinpointen ? top shift-m zie ik weinig vreemds, php.ini mem limit (scripts) staat op 128MB (standaard)
Iemand een suggestie in welke hoek ik dit moet zoeken ?
top - 12:06:58 up 37 min, 1 user, load average: 0.26, 0.12, 0.27
Tasks: 122 total, 2 running, 120 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 0.0%id, 99.7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1024768k total, 762252k used, 262516k free, 47308k buffers
Swap: 2064376k total, 0k used, 2064376k free, 208672k cached
shift+M
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2651 apache 15 0 306m 43m 5204 S 0.0 4.4 0:03.33 httpd
2649 apache 15 0 307m 43m 5072 S 0.0 4.4 0:04.33 httpd
2648 apache 15 0 307m 43m 5148 S 0.0 4.4 0:06.54 httpd
2647 apache 15 0 306m 43m 5040 S 0.0 4.3 0:05.24 httpd
2654 apache 15 0 306m 43m 4816 S 0.0 4.3 0:04.28 httpd
2652 apache 15 0 307m 42m 5004 S 0.0 4.3 0:04.33 httpd
2650 apache 15 0 306m 42m 5112 S 0.0 4.3 0:03.78 httpd
3250 apache 15 0 306m 42m 4720 S 0.0 4.3 0:02.59 httpd
2653 apache 15 0 306m 42m 4780 S 0.0 4.3 0:03.46 httpd
3200 apache 15 0 305m 41m 4420 S 0.0 4.2 0:00.83 httpd
3315 apache 15 0 288m 29m 4780 S 0.0 2.9 0:00.41 httpd
2385 mysql 15 0 192m 29m 4808 S 0.0 2.9 0:01.29 mysqld
Linux is niet zoals windows als het op geheugen aankomt. Linux zal elk stukje vrij geheugen gebruiken als cache van data die het frequent nodig heeft van je harde schijf. Zodra een programma geheugen nodig heeft wordt een stuk van die cache weggehaald zodat dat programma voldoende geheugen ter beschikking krijgt.
Waarom je server crasht is een aparte kwestie
Linux is niet zoals windows als het op geheugen aankomt. Linux zal elk stukje vrij geheugen gebruiken als cache van data die het frequent nodig heeft van je harde schijf. Zodra een programma geheugen nodig heeft wordt een stuk van die cache weggehaald zodat dat programma voldoende geheugen ter beschikking krijgt.
Waarom je server crasht is een aparte kwestie
Maar gezien precies op het moment dat ik betreffende site aanroep het vrije geheugen 150-200MB aftakelt (vind ik bijzonder veel) lijkt het mij toch vrij logisch dat het in die hoek moet zitten, das toch veel te veel geheugen voor een simpele website om op te eisen?
Wat voor virtualisatie-techniek gebruik je? XEN, KVM, VMware, OpenVZ?
VNE's antwoord klopt. Op zich is het niet vreemd dat je site zoveel 'verbruikt', want in werkelijkheid verbruikt hij dat helemaal niet. Veel servers hebben nagenoeg geen geheugen 'vrij' maar wel SWAP.
Roep je het resizescript aan als je de website bezoekt? Zou niet handig zijn om dat script te runnen bij elke visit. Ik neem aan dat het script alleen draait als je content plaatst. Zo niet, moet je zien te voorkomen dat het script geladen wordt.
Verder is het misschien handig om de logfiles door te spitten (rond de tijd dat hij crashte).
pas gaan wanhopen als "swap: 0k used" gaat veranderen op een linux machine
De apache processen die je hebt draaien zijn allemaal rond de 42-43MB. Een standaard apache proces is slechts 10MB, dus het is duidelijk dat in jouw geval PHP relatief veel geheugen verbruikt. Aangezien al je Apache processen deze omvang hebben is het een standaard onderdeel van je website, niet een incidenteel of eenmalig script. Op zich weinig om je druk over te maken, als je het geheugen hebt. Wel oppassen met het maximale aantal apache server processen in /etc/apache2/apache2.conf, als dat de standaard waarde van 150 heeft gaat je server heel snel uit zijn geheugen lopen en hard swappen bij veel belangstelling. In jouw geval met standaard 700MB RAM vrij na een reboot en een kleine 50MB per proces zou ik die waarde niet hoger zetten dan 20-30. Dan zal je server wel wat sneller verzoeken weigeren, maar niet enorm traag worden bij drukte.
Dit script draait op WordPress (verder zonder cache gerelateerde plugins) Als ik de betreffende site niet bezoek blijft het geheugen wel stabiel, maar zodra ik deze wel heb bezocht knalt ie dus paar honderd MB naar beneden en lijkt het ook alsof hij elke minuut in zakt tot ie na (kwartier?) nog maar op 60MB vrij zit
Daarna wil de machine nog wel eens crashen binnen paar uur.. Het gekke is dat de machine ook wel eens 45 dagen achtereen heeft gedraait en er wezelijk niets veranderd is
Dat je server soms crasht is niet zo raar als ie op een gegeven moment geen geheugen meer heeft; dan gaat de OOM-killer aan de slag en dan is het meestal einde oefening.
Het maken van thumbnails kan wat intensiever zijn voor zowel de processor als de I/O als het geheugen. Als er meerdere van dat soort dingen tegelijk gebeuren en de beschikbare capaciteit is al niet zo veel, dan krijg je al snel een opeenstapeling waardoor elk proces de boel verder gaat vertragen, er meer processen blijven draaien, er steeds meer I/O nodig is en het geheugen volloopt. En dan met bovenstaande als gevolg.
Aan de andere kant kunnen slecht gecode plugins voor wordpress soms ook onzinnig veel resources gebruiken.
Kortom, uitzoeken of je voldoende resources hebt (met name de I/O is bij een VPS vaak de bottleneck) en uitzoeken of het script wellicht een update heeft en/of meer mensen het probleem hebben. :)
Wat voor virtualisatie-techniek gebruik je? XEN, KVM, VMware, OpenVZ?
VNE's antwoord klopt. Op zich is het niet vreemd dat je site zoveel 'verbruikt', want in werkelijkheid verbruikt hij dat helemaal niet. Veel servers hebben nagenoeg geen geheugen 'vrij' maar wel SWAP.
Roep je het resizescript aan als je de website bezoekt? Zou niet handig zijn om dat script te runnen bij elke visit. Ik neem aan dat het script alleen draait als je content plaatst. Zo niet, moet je zien te voorkomen dat het script geladen wordt.
Verder is het misschien handig om de logfiles door te spitten (rond de tijd dat hij crashte).
Hyper-V (argeweb)
Ik heb momenteel ontdekt waar twee slow queries vandaan kwamen, er stonden BLOBs in de database die niet gebruikt werden (ik denk dat een media library in de database werd opgeslagen maar dat vind nu plaats op een filepath)
However.. de machine gaat nog steeds van 700 naar 20mb ram used en swap staat af en toe op 60k en soms op 0k.. dit was altijd 0k...
Mijn php.ini staat op 50 clients, mijn memory limit op 48MB en het php TimThumb script op de betreffende site heb ik nu zo ingesteld:
define ('CACHE_SIZE', 100); // number of files to store before clearing cache
define ('CACHE_CLEAR', 20); // maximum number of files to delete on each cache clear
define ('CACHE_USE', TRUE); // use the cache files? (mostly for testing)
define ('VERSION', '1.25'); // version number (to force a cache refresh)
define ('DIRECTORY_CACHE', './cache'); // cache directory
define ('MAX_WIDTH', 700); // maximum image width
define ('MAX_HEIGHT', 700); // maximum image height
define ('ALLOW_EXTERNAL', FALSE); // allow external website (override security precaution - not advised!)
define ('MEMORY_LIMIT', '30M'); // set PHP memory limit
define ('MAX_FILE_SIZE', 500000); // file size limit to prevent possible DOS attacks (roughly 1.5 megabytes)
define ('CURL_TIMEOUT', 10); // timeout duration. Tweak as you require (lower = better)
Voor graceful service:
top - 17:51:50 up 13:41, 1 user, load average: 0.38, 0.16, 0.05
Tasks: 123 total, 2 running, 121 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.0%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.4%hi, 0.0%si, 0.0%st
Mem: 1024768k total, 940212k used, 84556k free, 45708k buffers
Swap: 2064376k total, 60k used, 2064316k free, 393064k cached
Na graceful service:
top - 17:52:19 up 13:41, 1 user, load average: 0.23, 0.14, 0.05
Tasks: 122 total, 1 running, 121 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.0%us, 0.5%sy, 0.2%ni, 94.8%id, 2.3%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 1024768k total, 603684k used, 421084k free, 45748k buffers
Swap: 2064376k total, 60k used, 2064316k free, 393068k cached
TOP SHIFT-M
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2365 mysql 17 0 261m 40m 5152 S 0.0 4.1 0:29.13 mysqld
32712 apache 17 0 278m 24m 3260 S 0.0 2.4 0:00.21 httpd
32713 apache 15 0 276m 23m 3340 S 0.0 2.3 0:00.22 httpd
32714 apache 15 0 277m 22m 4248 S 0.0 2.2 0:00.28 httpd
32715 apache 18 0 274m 21m 3296 S 0.0 2.1 0:00.26 httpd
2891 root 34 19 250m 15m 2116 S 0.0 1.5 0:00.45 yum-updatesd
30431 root 18 0 261m 10m 5736 S 0.0 1.1 0:00.10 httpd
32710 apache 17 0 263m 8772 2900 S 0.0 0.9 0:00.01 httpd
2192 root 15 0 154m 8012 4192 S 0.0 0.8 0:03.02 snmpd
60k swap is heel weinig, daar zou ik me verder niets van aantrekken. Pas als je tientallen MB's swap gebruikt dan heb je het over enig swap gebruik en zelfs dat hoeft geen punt te zijn, zie onder. Jouw machine zou ook prima zonder swap werken op dit moment gegeven de cijfers van top:
45748k buffers
393068k cached
oftewel 45+393=438MB van je RAM wordt puur ingezet om de machine sneller te laten reageren omdat hij veelgevraagde bestanden zo niet van de schijf hoeft te lezen. Als je webserver processen meer RAM willen verbruiken zal linux eerst de cache gaan verkleinen, voordat je echt zwaar gaat swappen. Je wil juist graag een grote cached en een redelijke hoeveelheid buffers.
Daarbij zul je na een graceful restart van apache altijd minder geheugen gebruiken dan wanneer je site echt wat doet, tenzij je standaard al het maximale aantal apache processen aanmaakt en puur statische content als plaatjes en platte html pagina's staat te serveren. Apache gaat voor php pas geheugen gebruiken als het nodig is, Apache gaat pas meer processen aanmaken als het nodig is. Beiden zorgen voor dit gedrag van geheugengebruik. Ter vergelijking zie mijn output van een fysieke machine met 24GB RAM hieronder:
top - 20:13:46 up 41 days, 1:22, 2 users, load average: 0.71, 0.57, 0.59
Tasks: 250 total, 1 running, 249 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 2.5%sy, 1.0%ni, 95.4%id, 0.4%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 24733860k total, 24560820k used, 173040k free, 268488k buffers
Swap: 6848504k total, 120768k used, 6727736k free, 14496432k cached
14.5GB cached, 268MB aan buffers en toch 120MB swap in gebruik. Geen enkel probleem, wat er ook in die 120MB staat, het zal gewoon echt bijna nooit nodig zijn wil de kernel besluiten dat het daar beter op zijn plek is. De kernel laat die 120MB toch op de schijf staan met 14.5GB geheugen wat hij zo zou kunnen inzetten... de processen op deze machine hebben ook nooit meer dan 51% van het fysieke geheugen gebruikt, dus zoals je ziet kun je ook prima wat swap gebruik hebben zonder dat er ook maar iets aan geheugen tekort is.
bedankt voor alle zeer bruikbare tips.. toch zit er een probleem in de memory / cache usage en heb ik dit nu alsnog gepinpoint op de timthumb.php deze wordt praktisch bij elke aanvraag aangeroepen een plaatje te resizen.. alsof hij de cache plaatjes steeds opnieuw maakt..
de huidige instellingen van dit script staan hierboven heeft iemand misschien een suggestie deze anders in te stellen dan ik nu heb of hem anders maar definitief niet te gebruiken?
Ik ben niet bekend met TimThumb, maar vaak zijn dit soort problemen redelijk hetzelfde voor diverse caching scripts en packages. Allereerst de vraag: zie je in de cache en/of temp directories van TimThumb bestanden verschijnen? Zo niet dan zou dat op permissions van je filesystem kunnen stuklopen en moet je zorgen dat de webserver schrijfrechten op die directories krijgt (even snel testen met chmod 777 doet wonderen). Misschien ook handig om even te vermelden welke versie van TimThumb je gebruikt als je er hiermee nog niet uitkomt?
Ik ben niet bekend met TimThumb, maar vaak zijn dit soort problemen redelijk hetzelfde voor diverse caching scripts en packages. Allereerst de vraag: zie je in de cache en/of temp directories van TimThumb bestanden verschijnen? Zo niet dan zou dat op permissions van je filesystem kunnen stuklopen en moet je zorgen dat de webserver schrijfrechten op die directories krijgt (even snel testen met chmod 777 doet wonderen). Misschien ook handig om even te vermelden welke versie van TimThumb je gebruikt als je er hiermee nog niet uitkomt?
De recentste versie (zie link), en bestanden verschijnen gewoon (al mn dirs staan sowieso standaard 755, en files 644, met apache user rechten dus 777 maakt niks uit.. toch lijkt het alsof sinds het verwijderen van die dooie blobs er minder aan de hand is.. ik monitor t :-) :thumbup: