Onderwerp: 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.

Code:

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.

Code:

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.

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:





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.