Dauerhafte hohe Load bzw. Beurteilung Load Average

**Helmi** · 01.01.08, 12:48

Hallo zusammen,

ich arbeite seit geraumer Zeit mit div. Linuxsystemen - seit einigen Jahren mit Servern und seit einem knappen Jahr nun fast ausschließlich mit Linux als Desktop-OS.

Was mir immer noch etwas schwer fällt ist die ordentliche Beurteilung des Load-Average-Wertes. Mir geht es dabei weniger darum zu wissen wie man die bedeutung des Wertes erklärt sondern eher darum die Situation aufgrund des Load Average einschätzen zu können.

Beispielsituation:

Dedicated Server (Apache, PHP, MySQL) steht etwas unter Strom. Last liegt dauerhaft bei 1.5 - 2, manchmal auch bei 4-5.

Hardware: AMD X2 6000+ (DualCore), 8GB Ram, HW-Raid1 mit 2*SATA

Physical Memory ist noch gut was frei, Swap unused, CPU dauerhaft 60-70% idle. Meine halbwage Vermutung ist der Engpass bei den Platten bzw. dem Raid.

Grundsätzlich liefert der Server die primär DB-gestützten Websites ordentlich flott aus. Der hohe Load-Wert klingt allerdings erstmal nach latenter Überlastung.

Hab' ich in meiner Betrachtung ggf. irgendwas übersehen? Sollte mich die hohe Load beunruhigen?

Sorry, wenn das ganze nun etwas doof klingt, aber mir fehlt in dem Punkt einfach so richtig der Durchblick.

**bla!zilla** · 01.01.08, 12:53

Interessant bei dieser Beurteilung sind die wa Werte, die man z.B. bei top finden kann. Sind die hoch, dann wartet die Maschine, bzw. ein Prozess, auf I/O. Egal ob vom Blockdevice oder z.B. der NIC.

**Helmi** · 01.01.08, 13:01

danke für den Hinweis. Nach meiner Beobachtung ist der wa-Anteil recht niedrig - aktuell bei 0% bei ner Last von 2.25

Code:

22.2%us, 11.8%sy,  0.0%ni, 65.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st

**bla!zilla** · 01.01.08, 13:03

Poste mal die Ausgabe von top, sortiert nach CPU Usage.

**Helmi** · 01.01.08, 13:09

Da brauch ich gar nicht schauen - das wird ne Liste von apache-Prozessen sein, und mitten drin der mysqld.

Spaß beiseite - hier ein aktueller Snapshot:

Code:

top - 14:08:23 up 3 days, 17:43,  1 user,  load average: 1.28, 1.78, 2.14
Tasks: 250 total,   3 running, 246 sleeping,   0 stopped,   1 zombie
Cpu(s): 68.7%us, 20.0%sy,  0.0%ni, 10.8%id,  0.0%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:   8151860k total,  5696668k used,  2455192k free,   288852k buffers
Swap:  2097140k total,        0k used,  2097140k free,  2770556k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                        
31927 www-data  16   0  647m  21m  12m S   17  0.3   0:00.51 apache2                                        
31919 www-data  15   0  647m  21m  12m S   16  0.3   0:00.50 apache2                                        
31559 www-data  15   0  647m  25m  16m S   16  0.3   0:02.52 apache2                                        
31929 www-data  17   0  647m  21m  12m S   16  0.3   0:00.48 apache2                                        
31138 www-data  16   0  647m  24m  15m S   14  0.3   0:04.17 apache2                                        
31561 www-data  17   0  647m  24m  15m S   13  0.3   0:01.88 apache2                                        
31581 www-data  15   0  662m  40m  15m S   13  0.5   0:02.19 apache2                                        
31934 www-data  17   0  646m  20m  11m S    7  0.3   0:00.20 apache2                                        
31937 www-data  17   0  646m  20m  11m S    5  0.3   0:00.16 apache2                                        
31941 www-data  17   0  646m  20m  11m S    5  0.3   0:00.16 apache2                                        
31942 www-data  18   0  646m  20m  11m S    5  0.3   0:00.16 apache2                                        
31944 www-data  16   0     0    0    0 Z    5  0.0   0:00.16 apache2 <defunct>                              
31938 www-data  18   0  646m  20m  11m S    5  0.3   0:00.15 apache2                                        
31939 www-data  18   0  646m  20m  11m S    5  0.3   0:00.15 apache2                                        
31943 www-data  17   0  646m  20m  11m S    5  0.3   0:00.15 apache2                                        
31946 www-data  18   0  646m  20m  11m S    5  0.3   0:00.15 apache2                                        
30329 www-data  15   0  647m  28m  18m S    4  0.4   0:08.74 apache2                                        
31947 www-data  18   0  661m  34m  11m S    4  0.4   0:00.13 apache2                                        
30362 www-data  15   0  647m  26m  17m S    2  0.3   0:05.86 apache2                                        
31948 www-data  16   0  650m  23m  10m R    2  0.3   0:00.06 apache2                                        
31031 mysql     15   0 2189m 424m 6276 S    1  5.3 259:09.01 mysqld                                         
31556 www-data  15   0  647m  24m  15m S    1  0.3   0:00.92 apache2                                        
31650 www-data  15   0  648m  27m  18m S    1  0.3   0:00.76 apache2                                        
31923 www-data  15   0  646m  15m 7680 S    1  0.2   0:00.63 apache2                                        
31949 www-data  17   0  647m  18m 8176 R    1  0.2   0:00.03 apache2                                        
31504 www-data  15   0  647m  26m  17m S    1  0.3   0:01.78 apache2                                        
31932 www-data  16   0  646m  12m 4476 S    1  0.2   0:00.02 apache2                                        
31940 www-data  17   0  646m  11m 3836 S    1  0.1   0:00.02 apache2                                        
 2593 root      10  -5     0    0    0 S    0  0.0   0:56.89 kondemand/0                                    
29898 www-data  16   0  647m  26m  17m S    0  0.3   0:08.85 apache2                                        
30317 www-data  15   0  647m  26m  17m S    0  0.3   0:05.66 apache2                                        
31205 www-data  15   0  647m  27m  17m S    0  0.3   0:02.67 apache2                                        
31558 www-data  15   0  647m  25m  16m S    0  0.3   0:02.12 apache2                                        
31652 helmi     15   0 10724 1444  948 R    0  0.0   0:00.32 top                                            
31925 www-data  15   0  646m  11m 3840 S    0  0.1   0:00.10 apache2                                        
    1 root      15   0  6120  676  556 S    0  0.0   0:01.21 init                                           
    2 root      RT   0     0    0    0 S    0  0.0   0:00.38 migration/0                                    
    3 root      34  19     0    0    0 S    0  0.0   0:00.02 ksoftirqd/0                                    
    4 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0

**marce** · 02.01.08, 06:31

17% für 'nen Apache mit MySQL? Bei uns dümpeln die so bei 0-5% herum...

-> Ich würde mal die Apache und MySQL-Konfig überprüfen - viel eher aber vermuten, daß das Datenbank-Design und die SQL-Abfragen nicht optimal sind...

edit: die 650 MB/Apache-Prozess deuten auch darauf hin, daß da wohl was nicht optimal ist (zu große temp. Daten durch SQL-Abfragen oder anderes, ...) - es sind jedenfalls Werte, die ich bei uns so nicht kenne

**bla!zilla** · 02.01.08, 06:34

Man sieht am mysqld ganz gut das der viel Zeit zieht. Evtl. mal das tuning-primer.sh über die Maschien laufen lassen.

**Helmi** · 02.01.08, 06:59

die tuning-primer.sh läuft schon regelmässig drüber, bei mysql sollte weitestgehend alles passen.

MySQL und Apache verarbeiten zusammen auch knapp 100k PI am Tag mit Wordpress und Vbulletin - die sind beide auch nicht gerade zimperlich was den Resourcenverbrauch angeht.

@marce: Woran das liegt, dass vereinzelte Apache-Prozesse immer etwas härter an die CPU greifen weiss ich leider auch nicht, wie du siehst sind das aber ja nicht alle. Was den Speicherverbrauch angeht, hab ich natürlich versucht möglichst viel dorthin zu verlegen (in den Ram), da mit den 8GB recht viel davon vorhanden ist die Zugriffe dahin allemal schneller sind als auf die Platte. Die Performance der Websites ging dadurch auch deutlich nach oben - um den hohen Speicherverbrauch der Apache-Prozesse mach ich mir erstmal weniger Gedanken.

Dass das ganze bzgl. dem Code nicht optimal ist ist klar - durch WP und VBulletin lässt sich das auch nur teilweise durch Verbesserungen beeinflussen - darum geht's aber auch gar nicht in erster Linie.

Mir gings auch primär um die Beurteilung der Loadwerte und deren Einschätzung. Diesbzgl. bin ich leider noch nicht weitergekommen

**marce** · 02.01.08, 07:05

Zum Thema "Load" und wie man die Werte beurteilt gab's in einer X (glaube in einer der letzten 6 Ausgaben) mal ein sehr interessanten Artikel... Exakte Ausgabe müsste ich suchen...

"Grob" gesagt ist bei einer DualCore-Maschine eine Load unter 2 akzeptabel - wobei das auch so einfach nicht zu sagen ist... Interessant sind auf jeden Fall die Zeiten, wo die Load eben stark ansteigt und dann die Gründe dazu finden...

**Helmi** · 02.01.08, 07:13

Die Gründe dafür sind vordergründig einfach zu finden - die Load steigt an, weil zu Spitzenzeiten ungefähr 600 Leute gleichzeitig im Forum unterwegs sind - parallel dazu ca. 200 auf dem Wordpress-Blog. Zu den ohnehin recht Leistungshungrigen Standardinstallationen der beiden kommen dann noch eine Hand voll Addons, die natürlich das ganze auch nicht schlanker machen.

Detaillierter gesprochen dürften die Gründe dann bei ca. 60-80 Requests/s auf dem Apache und bis zu 100 Queries/s auf dem MySQL. Wobei bei letzterem ca. 70/s Cache-Hits sind.

Wenn Du bzgl. der X was rauskriegst würde ich mich über nen kurzen Hinweis freuen. Danke!

**marce** · 02.01.08, 07:32

wenn es wirklich "normale" Usecases sind - ok (also keine DB-Dumps, Locate und UpdateDB-Jobs und was man sonst so manchmal findet).

Update: es war keine iX sondern im LinuxMagazin:

http://www.linuxmagazin.de/heft_abo/...tik?category=0

Zum Thema php und MySQL-Optimierung selbst sollte sich auch ein bisschen was "Hi-Leveligeres" noch hier im Forum finden - ich meine mich an einen Thread zu erinnern, wo es unter anderem um andere Optimizer-Engines für php ging (und AFAIK auch belegt mit ein paar Messwerten) - die Frage ist dann immer noch, ob die von euch verwendete Software sich damit verträgt.

Ansonsten: 2 Cores, 2 große Applikationen - da ist natürlich irgendwann der Task-Scheduler die entscheidende Schnittstelle - evtl. auch in die Richtung mal schauen (sofern man nicht das Problem einfach durch Hardware erschlagen will)...

**Helmi** · 02.01.08, 07:40

Ja in sachen PHP-Optimizer bin ich auch schon dran. Aktuell läuft der Eaccelerator und bringt auch einiges (leider nicht allzu viel). Ich würde gerne Xcache einsetzen, der wollte aber beim ersten Anlauf auf der Maschine nicht laufen - evtl. amd64-bedingt. Das muss ich mir in Ruhe auf ner Testmaschine nochmal anschauen.

Danke für den Link bzgl. Linuxmagazin.