[gentoo-user-de] Grund für hohen IO Wait rausbekommen

[gentoo-user-de] Grund für hohen IO Wait rausbekommen

[support]

Hallo,

wir haben folgendes Setup:
Ein Rechner (Dual Xeon mit 4GB Ram) hängt via Fibre Channel an einem SAN
Ein zweiter identischer Rechner hängt via NFS an Rechner ein. Anbindung
über eine dedizierte 1GB Schnittstelle


Nun haben wir Rechner 1 teilweise eine hohe Last von > 3, obwohl (noch)
kaum Traffic drauf ist (das sind unsere Webserver). Ich schaue mir Top an
und sehe:

top - 15:35:38 up 144 days, 22:41,  1 user,  load average: 3.54, 2.75, 2.34
Tasks: 115 total,   1 running, 114 sleeping,   0 stopped,   0 zombie
Cpu0  :  1.3%us,  1.3%sy,  0.0%ni,  2.7%id, 94.0%wa,  0.0%hi,  0.7%si, 
0.0%st
Cpu1  : 21.7%us,  1.3%sy,  0.0%ni, 75.3%id,  1.7%wa,  0.0%hi,  0.0%si, 
0.0%st


Oha, IO Wait ist aber groß. Gibt es nun einen Weg zu erkennen, was den
Wait so hoch treibt ?

Schon mal Danke
Stonki


-- 
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] Grund für hohen IO Wait rausbekommen

[gentoo]

Hallo!

Check mal die Schreib-/Leseperformance bei den betroffenen Stellen. 
Wahrscheinlich braucht schon ein ls ewig? Wenn ein Verzeichnis auf mehrere 
Webserver exportiert wird, dann entsteht schnell ein Flaschenhals durch die 
Zugriffszeiten der Festplatten. Falls das bei Dir der Fall ist, kann es 
helfen, RAM aufzurüsten (hängt von Menge und Art der Daten ab) und ein Raid 
aus vielen _schnellen_ Platten zu benutzen, auch wenn die kleiner sind. 
Wenn auch viele Schreibzugriffe gemacht werden und die Systeme 
ausfallsicher 'genug' sind ;-) kann es einen sehr großen 
Geschwindigkeitszuwachs bringen, NFS von sync auf async umzustellen.

Am Mittwoch, 27. Juni 2007 15:38 schrieb support@stonki.de:
> Hallo,
>
> wir haben folgendes Setup:
> Ein Rechner (Dual Xeon mit 4GB Ram) hängt via Fibre Channel an einem SAN
> Ein zweiter identischer Rechner hängt via NFS an Rechner ein. Anbindung
> über eine dedizierte 1GB Schnittstelle
>
>
> Nun haben wir Rechner 1 teilweise eine hohe Last von > 3, obwohl (noch)
> kaum Traffic drauf ist (das sind unsere Webserver). Ich schaue mir Top an
> und sehe:
>
> top - 15:35:38 up 144 days, 22:41,  1 user,  load average: 3.54, 2.75, 2.34
> Tasks: 115 total,   1 running, 114 sleeping,   0 stopped,   0 zombie
> Cpu0  :  1.3%us,  1.3%sy,  0.0%ni,  2.7%id, 94.0%wa,  0.0%hi,  0.7%si,
> 0.0%st
> Cpu1  : 21.7%us,  1.3%sy,  0.0%ni, 75.3%id,  1.7%wa,  0.0%hi,  0.0%si,
> 0.0%st
>
>
> Oha, IO Wait ist aber groß. Gibt es nun einen Weg zu erkennen, was den
> Wait so hoch treibt ?
>
> Schon mal Danke
> Stonki
--
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] Grund für hohen IO Wait rausbekommen

[Hans-Werner Hilse]

Hi,

On Wed, 27 Jun 2007 15:38:20 +0200 (CEST)
support@stonki.de wrote:

> Nun haben wir Rechner 1 teilweise eine hohe Last von > 3, obwohl (noch)
> kaum Traffic drauf ist (das sind unsere Webserver). Ich schaue mir Top an
> und sehe:
> [...]
> Oha, IO Wait ist aber groß. Gibt es nun einen Weg zu erkennen, was den
> Wait so hoch treibt ?

Nicht so ganz einfach. Mit einem kgdb-Kernel und etwas Geduld beim
debugging -- möglicherweise. Aber was ist denn mit den
Standard-Geschichten, wie sieht z.B. /proc/interrupts aus? Sonst
irgendwelche Infos in den Kernel-Logs?

-hwh
--
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] Grund für hohen IO Wait rausbekommen

[Bernd Wurst]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

Hallo.

Am Mittwoch, 27. Juni 2007 schrieb support@stonki.de:
> Oha, IO Wait ist aber groß. Gibt es nun einen Weg zu erkennen, was den
> Wait so hoch treibt ?

Für lokale Festplatten würde ich da zu iostat (aus dem Paket 
app-admin/sysstat) raten. Wie du allerdings Fibre-Channel-Devices ansprichst 
und ob das da auch geht, kann ich dank schmalem Geldbeutel und damit 
verbundenem Nichtvorhandensein von Fibre-Channel-Devices nicht 
beantworten. :-)

cu, Bernd

-- 
Die Menschen glauben viel leichter eine Lüge, die sie schon
hundertmal gehört haben, als eine Wahrheit, die ihnen völlig neu ist.
  -  Alfred Polgar

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-user-de] Grund für hohen IO Wait rausbekommen

[Stefan Onken]

Am Mittwoch, 27. Juni 2007 schrieb gentoo@gunter.de:

> aufzurüsten (hängt von Menge und Art der Daten ab) und ein Raid
> aus vielen _schnellen_ Platten zu benutzen, auch wenn die kleiner
> sind. Wenn auch viele Schreibzugriffe gemacht werden und die
> Systeme ausfallsicher 'genug' sind ;-) kann es einen sehr großen
> Geschwindigkeitszuwachs bringen, NFS von sync auf async
> umzustellen.

das hört sich interessant an (mit dem async), aber was mich wundert 
ist, daß der NFS Server die hohe IO Wait hat - nicht der NFS 
Client. Trotzdem async ?

cu
stonki

-- 
www.stonki.de:    the more I see, the more I know.......
www.proftpd.de:   Deutsche ProFTPD Dokumentation
www.krename.net:  Der Batch Renamer für KDE
www.kbarcode.net: Die Barcode Solution für KDE
--
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] Grund für hohen IO Wait rausbekommen

[Stefan Onken]

Am Mittwoch, 27. Juni 2007 schrieb Hans-Werner Hilse:

> Nicht so ganz einfach. Mit einem kgdb-Kernel und etwas Geduld
> beim debugging -- möglicherweise. Aber was ist denn mit den
> Standard-Geschichten, wie sieht z.B. /proc/interrupts aus? Sonst
> irgendwelche Infos in den Kernel-Logs?

also die logs meckern nichts. Die Interrrups von dem Server mit der 
hohen Load:

mike01:/home/onken # cat /proc/interrupts
           CPU0       CPU1
  0: 3136805453          0    IO-APIC-edge  timer
  1:       4882          0    IO-APIC-edge  i8042
  8:          0          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 12:        868          0    IO-APIC-edge  i8042
 14:   60163282          0    IO-APIC-edge  libata
 15:          0          0    IO-APIC-edge  libata
169:  974461467          0   IO-APIC-level  uhci_hcd:usb2, eth0, 
eth1
177:   79503349          0   IO-APIC-level  ioc0
185:   39776132          0   IO-APIC-level  qla2xxx
193:          0          0   IO-APIC-level  ehci_hcd:usb1
201:          0          0   IO-APIC-level  uhci_hcd:usb3
NMI:    2462166    2462145
LOC: 3136708659 3136708821
ERR:          1
MIS:          0

zum Vergleich der andere:
mike2:/home/onken # cat /proc/interrupts
           CPU0       CPU1
  0: 1662751809          0    IO-APIC-edge  timer
  1:       3234          0    IO-APIC-edge  i8042
  8:          0          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 12:       1028          0    IO-APIC-edge  i8042
 14:   18548472          0    IO-APIC-edge  libata
 15:          0          0    IO-APIC-edge  libata
169:  619769869          0   IO-APIC-level  uhci_hcd:usb2, eth0, 
eth1
177:   38337969          0   IO-APIC-level  ioc0
185:        734          0   IO-APIC-level  qla2xxx
193:          0          0   IO-APIC-level  ehci_hcd:usb1
201:          0          0   IO-APIC-level  uhci_hcd:usb3
NMI:    1021907    1021886
LOC: 1662650777 1662650746
ERR:          1
MIS:

mike01 ist der NFS Server, der das SAN per NFS dem Mike2 
bereitstellt.
        
-- 
www.stonki.de:    the more I see, the more I know.......
www.proftpd.de:   Deutsche ProFTPD Dokumentation
www.krename.net:  Der Batch Renamer für KDE
www.kbarcode.net: Die Barcode Solution für KDE
--
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] Grund für hohen IO Wait rausbekommen

[Hans-Werner Hilse]

Hi,

On Wed, 27 Jun 2007 22:28:12 +0200 Stefan Onken <Support@stonki.de>
wrote:

> also die logs meckern nichts. Die Interrrups von dem Server mit der 
> hohen Load:
> 
> mike01:/home/onken # cat /proc/interrupts
>            CPU0       CPU1
>   0: 3136805453          0    IO-APIC-edge  timer
> [...]
> 169:  974461467          0   IO-APIC-level  uhci_hcd:usb2, eth0, 
> eth1
> 177:   79503349          0   IO-APIC-level  ioc0
> 185:   39776132          0   IO-APIC-level  qla2xxx

Also richtig überlastet war das System aber nie. Sonst hätte die CPU1
sich auch um ein paar Interrupts gekümmert -- jedenfalls sollte sie
damit anfangen, wenn der IRQ-Balancer sauber arbeitet. Vielleicht magst
du zum Testen ja wirklich mal mit den (IO-)APIC-Einstellungen
(Kernel-Konfiguration und Kernel-Parameter) herumspielen...

> NMI:    2462166    2462145

Das ist glaube ich hingegen normal...

> ERR:          1

...und das kann schon mal vorkommen.

Interessantes in den Logs findest du wenn überhaupt auch nur im extrem
frühen Bootvorgang, also dort, wo die CPUs erkannt werden und das
Interrupt-Management angeworfen wird. Vielleicht hast du ja Lust, mal
ein Boot-Log irgendwo auf Webspace für ein, zwei Tage online zu stellen?

Ansonsten scheint das Netzwerkinterface ja wirklich höchst intensiv
beschäftigt zu sein. Wenn die Verbindung zum NFS-Client dazu taugt,
vielleicht mal die Netzwerkpaketgröße 'raufschrauben, also die MTU auf
beiden Seiten ordentlich 'raufsetzen. Macht natürlich keinen Sinn,
falls ein Switch o.ä. zwischendurch die dann wieder die Pakete verwirft.

-hwh
--
gentoo-user-de@gentoo.org mailing list