Bekijk Volledige Versie : Load binnen 2 minuten >150
Beste,
Ik heb een dedicated server waar heel wat klanten hun (gescripte) website op draaien. Het is een oud beestje: P4 2.0GHz, 512MB ram, 512MB swap.
Nu draait dit over het algemeen als een zonnetje, de load komt niet over de 0.50, gemiddeld 470MB RAMm in gebruik, en een paar honderd KB aan swap in gebruik.
Echter komt het steeds vaker voor dat de server plotseling compleet overbelast raakt. Als ik soms met SSH ingelogd ben, en met top de load in de gaten houdt, klapt de boel in enkele momenten in elkaar. De swap staat direct 100% vol, de RAM is voor 99% gevuld, load stijgt met 2 punten per seconde, tot ~150, en de server reageert niet meer. Reboot kan alleen plaatsvinden door de stroom eraf te halen.
Nu heb ik natuurlijk niet de scripts van de klanten in de hand, dus ik kan alleen maar globale checks uitvoeren.
- LSOF blijft constant (~27k)
- aantal processen (zowel apache als mysqld) blijft constant
- CPU usage 3% (maar ja, met een volle swap staat de CPU dan ook eindeloos te wachten)
- ping blijft <12ms
- virtueel/shared geheugen per process is ook niet hoger dan normaal, dus hoe die swap gevuld wordt is mij een raadsel
De server vliegt er ongeveer 2x per week uit: op zowel rustige ('s nachts) als drukke momenten (laat in de middag).
Als er een process in een infinite loop terecht zou komen, zou je een load van 1.00 verwachten, geen 150.00! Een infinite loop in een SQL procedure wellicht in een table met MEMORY storage? Wat zijn de andere opties?
Hoe kan ik de oorzaak analyseren?
De load van linux is niet helemaal gelijk aan processor gebruik, het geeft aan hoeveel processen er in de run queue staan (of te wel, worden uitgevoerd). Als er een process blijft hangen (kan in principe zelfs idle zijn) dan wordt de queue steeds groter. Het is wel een indicatie van hoe druk een machine het heeft.
Als je 4 cpu's in een machine hebt zitten is een load van 4 heel normaal, het systeem kan namelijk 4 processen tegelijk afhandelen zonder problemen.
Als een proces zelf niet zo veel geen geheugen lijkt in te nemen zou je eerder denken aan een memory lek ergens.
Ook geen gekke cron's oid's? Of is het niet op bepaalde tijden maar totaal willekeurig? Check anders ook de logs eens, of er geen gekke dingen in terug te vinden zijn.
Welke PID zie je in top staan die het meest % tot zich neemt?
Maak anders eens een Screenshot van "top" als de load weer hoog is.
Dan kunnen wij misschien zien welk proces dit veroorzaakt
Installeer HTOP op de desbetreffende server. Hiermee kun je alle processen goed in de gaten houden qua load en dergelijke. Succes.
Er staan dus blijkbaar 150+ processes in de queue.
Ik zal eens een "ps aux | wc" uitvoeren als ik weer eens het geluk heb om ingelogd te zijn op het moment dat de server er bijna uitklapt.
(is er een commando om "ps aux" als een SQL "group by" output te laten genereren, zoals bijv: 20x apache, 5x mysqld, 15x dovecot, etc... zodat ik kan zien welk process er uit de hand loopt, ipv handmatig met grep op elke process naam)
De momenten zijn/lijken inderdaad compleet willekeurig, en daarnaast heb ik natuurlijk niet de cronjobs van alle klanten in de hand.
In "top" staat ook niets bijzonders, ook de cumulatieven (total CPU time) zijn erg laag. Probleem is natuurlijk ook dat Apache en MySQL vaak hun forked processes afsluiten, waardoor die cumulatieven niet veel informatie geven.
In de logs (zowel van de users als van de sys) staan alleen maar een hoop FileNotFound regels, en vreemde domain queries op de DNS (allemaal met .de als TLD van game clan sites, aan de namen te zien).
Ik heb in een andere thread gelezen dat ApacheTOP weer kan geven welke account / welk script (?) de boosdoener is. Geeft dat ook nog zinnige informatie als de CPU usage tijdens de 'grind' bijna op 0% staan, of als het probleem door MySQLd veroorzaakt wordt?
Ik heb overigens 1 screenshot van zo'n crash. Die staat echter op de PC op m'n werk, dus die kan ik morgen pas posten.
Ik zet mijn geld op een probleem met de harddisk. Komen er veel processen die disk gebruiken met status D in "top" of "ps aux" terecht? De kans is groot dat ze staan te wachten op een harddisk die het even niet meer weet. De elektronica van de harddisk kan namelijk proberen om een defecte sector zelf te recoveren en dat kan minuten duren bij bijvoorbeeld "consumenten" SATA schijven.
Post de S.M.A.R.T. informatie eens hier?
Update: installeer ook "atop", hiermee kun je de belasting van de server later weer terugkijken.
smartctl -iHcA -d ata /dev/sda
smartctl version 5.36 [i686-redhat-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: ST380815AS
Serial Number: 9QZ2547Q
Firmware Version: 3.AAA
User Capacity: 80,026,361,856 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 7
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sun Oct 26 14:01:47 2008 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 430) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 27) minutes.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 119 100 006 Pre-fail Always - 234133909
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 16
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 249110191
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 9725
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 24
187 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
189 Unknown_Attribute 0x003a 100 100 000 Old_age Always - 0
190 Unknown_Attribute 0x0022 071 061 045 Old_age Always - 505217053
194 Temperature_Celsius 0x0022 029 040 000 Old_age Always - 29 (Lifetime Min/Max 0/26)
195 Hardware_ECC_Recovered 0x001a 071 069 000 Old_age Always - 63128587
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0
Volgens mij behoorlijk slechte waarden (?), vooral de PRE_FAIL.
Kan dit echter ook het plotseling vollopen (tot op de laatste KB) van de swap verklaren?
dat ziet er niet goed uit!
Even wat uitleg over wat het betekent. Kolom Id is een label waarmee je tussen verschillende fabrikanten de juiste regels kunt vergelijken. Value is meestal een berekende waarde die omlaag telt, begint bij 100 of 200. Behalve in dit geval bij de temperatuur natuurlijk. Worst is wat het zegt, de slechtste waarde die de drive heeft gezien tijdens zijn leven. Threshold is de grens die de fabrikant geeft voor het ernaast genoemde type. Komt de waarde onder de threshold, dan is je drive aan het falen of oud aan het worden. Pre-fail en Old-age staat er dus ook bij nieuwe drives.
De Raw value is waar het hier om gaat. Een Raw_Read_Error_Rate van 234133909 is dat je drive tweehonderd miljoen keer een sector niet kon lezen!
Soms zijn dergelijke fouten te herstellen door de ECC controle, maar het wordt erger als er meerdere afwijkingen zijn zoals in dit geval de Seek_Error_Rate.
Mijn advies is: snel een backup maken op een externe schijf en deze disk vervangen.
Bedankt voor alle adviezen.
Elke seconde komen er 20-50 raw seek errors bij, de raw read errors zijn echter de laatste 3 uur gelijk gebleven. Misschien stijgen die alleen vlak voor de crash.
Mocht het vervangen van HDD het probleem onverhoopt niet oplossen, dan ga ik met atop/htop/apachetop aan de slag.
GlennMatthys
27/10/08, 09:05
Seagate harde schijven geven altijd verdachte waarden voor Raw_Read_Error_Rate. Doe eens een long test. Welke berichten staan er in dmesg of in /var/log die verdacht lijken?
We hebben nog een 2e server met identieke hardware (Seagate disk), waar de raw_read_error op 0 staat. Die heeft dan ook al een uptime van een paar honderd dagen, ipv 2-3 dagen bij onze problematische server.
De screenshot van TOP staat hier:
http://katav.nl/top_extreme_load.png
(http://katav.nl/top_extreme_load.png)
Die vele D's in de status kolom kunnen natuurlijk ook worden veroorzaakt door het compleet vollopen van de swap lijkt me. Het probleem / de aanvraag ligt nu bij het hosting center.
Die D-tjes zijn je load en dat is de oorzaak voor het vollopen van je swap denk ik. Doordat er zoveel task geswapped worden, gaat de memory op.
toevallig geen loop in een script ?
Wij hebben dit ooit eens gehad.
result :)
Het verschil is, dat jouw loop R processen oplevert en we hier te maken hebben met D processen. Veel processen in de run queue (R) is helemaal niet erg, zolang ze maar niet blocking zijn (D).
dreamhost_nl
27/10/08, 19:23
toevallig geen loop in een script ?
Wij hebben dit ooit eens gehad.
result :)
Dat is ook mijn gedachte... daarnaast staan er evenveel MySQL processen. Heb je mytop al geïnstalleerd en eens bekeken tijdens zo'n hoge server load?
Mogelijk dat je hierdoor gelijk ziet wie de user is die het probleem genereert.
en je swap partitie zit ook helemaal vol..
Een soort gelijke storing heb ik zelf gehad, bij mij was de oorzaak het script cj-overkill wat veel op adultsites wordt gebruikt...
na een herinstall waren de problemen weg
dreamhost_nl
29/10/08, 15:23
Zo'n script zou m.i. voor een constante hoge server load zorgen en geen piek.
Bij mij liep het juist in heel korte tijd ( binnen paar uur ) naar een load ver boven de 100 totdat de hele server vast liep, en had met top misschien wel 75x httpd aktief staan..
Je kan het ook vaak zien aan de i/o wait die erg oploopt. Maar inderdaad, asap schijfje vervangen en gaan met de spreekwoordelijke banaan (tijd voor een redundant setupje?)
Ik weet simpelweg niet welke scriptjes er allemaal op de sites van de klanten staan, dus even upgraden naar een laatste versie zit er niet in.
De hosters zeiden echter (zoals al door iemand was opgemerkt in deze thread) dat 'al' hun Seagate schijven (onder FedoraCore 5) dergelijke SMART waardes geven. In FC6 staan ze mooi op 0.
We hebben inmiddels alweer een uptime van 9 dagen (schokkend), dus ik heb nog geen crash meegemaakt die ik kan analyseren.
Het blijkt een script te zijn van een externe server die binnen enkele seconden 184 hits veroorzaakt op een site van een klant, waarvan de pagina's dmv behoorlijke queries opgebouwd worden (fulltext en regexp op tabellen met miljoenen rijen, en grote TEXT columns). Daarnaast maakt die site voor elke pageview een nieuwe DB connection. Elke MySQLd fork neemt 17MB in beslag, dus met 184x 17MB ( = 3GB) schiet de server compleet de swap in, en komt hij er ook niet meer uit (helaas).
Het verkeer komt allemaal vanaf dezelfde range X.Y.Z.{0-255}. Alle referers komen van search.live.com/ met allerlei aan die website gerelateerde keywords. Het is waarschijnlijk een tool die de ranking analyseert EN de contents van de resultaten binnen haalt. Ook een HTTP versie van 1.0 met als user agent MSIE 6.0 lijkt erop te duiden dat dit een bot/tool is.
Dus die IP range staat nu dus fijn in de firewall :ban:
GlennMatthys
03/11/08, 16:23
De echte oplossing was geweest om die loodzware pagina's te optimaliseren. Gebruik maken van caching, betere SQL (wtf @ regex op miljoenen rijen?) of simpelweg het aantal gegevens meer beperken. Beste zou dus een combinatie van alles zijn.
Ik kan moeilijk in de scripts van een klant gaan knutselen... toch?
Ik kan hooguit de klant op de hoogte stellen van dit probleem en lief vragen om zijn script te optimaliseren. De klant heeft er waarschijnlijk de ballen verstand van (die gebruikt wordpress voor een webwinkel... pff), dus dat gaat niet opschieten.
Simpelste oplossing is IP range in de firewall, en als dat niet genoeg blijkt, de klant een waarschuwing geven.
Ik kan moeilijk in de scripts van een klant gaan knutselen... toch?
Je zou het 'm kunnen aanbieden.. tenslotte zorgt zijn site er voor dat jouw server & services uit de lucht gaan en het kan leiden tot hardwareschade (en uiteraard reputatieschade).
Ik kan hooguit de klant op de hoogte stellen van dit probleem en lief vragen om zijn script te optimaliseren. De klant heeft er waarschijnlijk de ballen verstand van (die gebruikt wordpress voor een webwinkel... pff), dus dat gaat niet opschieten.
Mijn oplossing zou zijn (en is in het verleden geweest): de klant max. 24 uur geven om het probleem op te lossen en anders een andere host te zoeken. Je gaat je spullen toch niet voor een paar euro hostingvergoeding naar de maan laten helpen door een klant die er 'de ballen verstand' van heeft?
Brengt me terug op het eerste; als jij je klant kan overtuigen dat zijn site niet goed in elkaar zit, dan help je 'm, tegen een passende vergoeding, dat op te lossen. En anders zoekt hij/zij z'n heil maar elders. Shared hosting is keuzes maken; laat je de klanten die wel goed doen/willen lijden onder het geprutst van die éne,..?
Verder denk ik dat eerder gegeven advies om de schijf te vervangen niet zo'n slecht idee is..
Ik heb het eigenlijk veel te druk met andere projecten, om in de scripts van iemand te gaan neuzen. Ik denk dat het het beste is als er inderdaad een deadline gesteld wordt.
Helaas ben ik zelf niet bevoegd om iemand van de server af te wippen...