Magas IOWait és Interrupts. Megoldás?

Linux-haladó

Sziasztok!

A következő a problémám:

Van két kis szerver amin munin szerint az iowait átlag 50% egy másikon 120% (ez kétmagos).
A load pedig 15 és 30 között mozog rajtuk.

Mindkettőnél hasonló a proc/interrupts most csak az egyiket vágom be: 

cat /proc/interrupts
           CPU0       CPU1
  0:   96102398   32290987   IO-APIC-edge      timer
  1:          2          0   IO-APIC-edge      i8042
  8:          4          0   IO-APIC-edge      rtc
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          4          0   IO-APIC-edge      i8042
 14:   34382153   34455242   IO-APIC-edge      ide0
 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb5
 17: 2083054431 2124632174   IO-APIC-fasteoi   eth0
 18:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 19:   67205869   66765491   IO-APIC-fasteoi   uhci_hcd:usb3, libata

Tehát kb. 30x annyi megszakítás jön a hálókártya felől mint a vinyók (4db sataról beszélek, de ha hozzáadjuk az ide0 megszakításait akkor is hússzoros) felől.

Itt van még a proc/net/sockstat is: 


cat /proc/net/sockstat
sockets: used 963
TCP: inuse 1083 orphan 20 tw 141 alloc 1126 mem 7919
UDP: inuse 3
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

A kérdésem arra irányul, hogy a hálókártya (alaplapi integrált, Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8168 (rev 01)) okozhatja-e az óriási iowaitet, vagy a megszakítások száma nincs ezzel összefüggésben és egyszerűen a vinyók nem bírják a tempót?

Előre is köszi!

szerk: a hálózati forgalom átlag kb. 50MBit mindkét irányban.

  • 4199 megtekintés

Megvolt, de ebből mit kéne leszűrnöm? 


dstat --nocolor -D sda,sdb,sdc,sdd
----total-cpu-usage---- --dsk/sda-----dsk/sdb-----dsk/sdc-----dsk/sdd-- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq|_read _writ:_read _writ:_read _writ:_read _writ|_recv _send|__in_ _out_|_int_ _csw_
 17   8  12  59   1   3|3448k  344k:3506k  350k: 869k  699k:3254k  600k|   0     0 |  21k   11k|8890  3308
 12   4   0  80   2   3|3096k    0 :4252k    0 :8232k   12k:1660k  968k| 307k 7959k|   0     0 |8882  3196
 12   6   0  78   1   2|3240k  132k:7048k   68k:6108k   72k:1204k 2592k| 333k 7010k|   0     0 |8245  3406
 13   6   0  78   1   4|1544k    0 :4256k    0 :5524k   68k:1756k  312k| 303k 5776k|   0     0 |6886  3162
  8   6   0  82   1   2|2564k 8192B:4236k 8192B:5228k 8192B:2564k  532k| 281k 6172k|   0     0 |7354  3416
 12  10   0  75   1   2|6292k  136k:7312k 8192B:8612k 4096B:3804k  412k| 269k 5789k|   0     0 |7047  3412
 14  10   0  72   0   3|1460k    0 :  13M    0 :6272k    0 :4404k  320k| 272k 6577k|   0     0 |7773  4091
 13   8   0  76   2   2|  12M  104k:5760k   92k:6452k   92k:5412k  448k| 321k 6617k|   0     0 |7975  3745
 11   8   0  76   1   3|4440k    0 :5644k    0 :  10M   16k:2496k 2012k| 343k 7503k|   0     0 |8564  3711
 18   8   0  71   1   2|1676k    0 :4380k    0 :8084k    0 :3496k  868k| 428k 8026k|   0     0 |9137  3333

( turul16 v | 2007. 12. 26., sze – 16:41 )

hdparm -tT /dev/vinyo

Milyen gyorsan tudsz nagy filet masolni particion belul ?
Filrendszer tipusa ? mount opciok ?

kernel verzio ?

hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   1544 MB in  2.00 seconds = 770.48 MB/sec
 Timing buffered disk reads:  128 MB in  3.02 seconds =  42.44 MB/sec

Nagy file másolása: kb. 4MB/sec

Filerendszer: ext2 ill. ext3

Mount opciók: ext2-n semmi külön opció, ext3nál: -async,data=journal

És mindkét filerendszernél hasonlóan magas az iowait.

kernel: 2.6.20.1-1-686 illetve: 2.6.18-4-686

( AMDFan | 2007. 12. 26., sze – 17:23 )

most azon gondolkozom, hogy mennyiben segíthet az írási sebességen az, hogy ha noatime opcióval mountolok.

másrészről továbbra sem vagyok biztos benne, hogy a vinyók miatt nagy az iowait. az a rengeteg interrupt nagyon zavar...
munin statban például ha egymás fölé tenném az interrupts és a load average grafikont akkor észre lehet venni, hogy arányosan változik a load és az eth0 interruptok száma. persze ez nyilván arányos azzal is hogy megnő a hálózati forgalom és így a vinyók terhelése is.

olyan program nem létezik amelyik megmutatja, hogy melyik processz melyik I/O devicera vár? vagy ez nagyon hülye kérdés volt? :)

http://www.mjmwired.net/kernel/Documentation/networking/NAPI_HOWTO.txt
Használod ? (drivernel kell bepipalni "Use Rx and Tx Polling (NAPI) (EXPERIMENTAL) (R8169_NAPI) ")

see also : dma engine , talan javithat.

Bar szvsz ez az irq szam kiszolgalhato normalisan, onmagban nem okozhat tul nagy iowaitet.
kb, ethernet framenkent 1 jon, ha jol sacolok.

nekem az sk98lin driverben volt egy bugfeleseg, hogy nagy forgalom utan egyszercsak bejott egy allando 150k-s interrupt (mindig annyi volt terhelestol fuggetlenul), egy modul unload/load megoldotta a dolgot.

de itt ha a terhelessel aranyosan no az interupt, akkor az nemez a problema. irq utkozes? bar ahogy latom a vinyok eleg sokat lapatolnak (4-5M/vinyo), lehet telleg nembir ekkora terhelest a gep.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Raid nélkül annyira nem csoda, hogy lassú...Noatime,nodiratime jó ötlet, használom éles szervereken, nem okozott még bajt.

Az, hogy a hálókártya lenne a korlát, némileg ellentmond a dstat-os eredménynek, ott vannak egész kiemelkedő forgalmak, amikhez nem a legnagyobb iowait értékek tartolzanak...Bár Realteknél nem lehet tudni :)

( AMDFan | 2007. 12. 27., cs – 12:35 )

Úgy tűnik, hogy valóban jó tüneti kezelésként a noatime, persze pár óra alatt ezt még korai kijelenteni.
Az már világosan látszik, hogy a hdd-k a szűk keresztmetszet és nincs köze a hálókártyához.
A problémát érezhetően az okozza amikor írnia kell a vinyónak.
A írási sebességet meg gondolom nem nagyon lehet tuningolni. Vagy igen?

Szerintem meg kéne nézni, hogy nincs-e valami hardveres zűr azokkal a vinyókkal. Egy normál vinyó kb olyan gyorsan ír, mint ahogy olvas. Ha 10x eltérés a kettő között akkor ott valami nincs rendjén. Egyébiránt szerintem a hálókártya sem teljesen okés. Egy SAN szerveren nálam ilyen interrupt értékek vannak: 


           CPU0       CPU1
  0:  953069485  953018276    IO-APIC-edge  timer
  1:         21          7    IO-APIC-edge  i8042
  8:          1          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 12:        113          0    IO-APIC-edge  i8042
 50:          0          0   IO-APIC-level  uhci_hcd:usb5, ehci_hcd:usb6
 58:  126460671  127129745         PCI-MSI  libata
 66:   63063865   63518722         PCI-MSI  sky2
 74:        187          0   IO-APIC-level  HDA Intel
169:        489        238   IO-APIC-level  uhci_hcd:usb1, libata
177:    8564291    8565199   IO-APIC-level  ide2, uhci_hcd:usb2
225:    3056040          0   IO-APIC-level  uhci_hcd:usb3, ehci_hcd:usb7, eth1
233:    1977248    2092957   IO-APIC-level  uhci_hcd:usb4, skge
NMI:      15428      15508
LOC: 1859697642 1859697570
ERR:          0
MIS:

Az iSCSI forgalom a sky2-n megy (Marvell 88E8056 ez sem egy kifejezetten minőségi hálókártya, nem tud interrupt moderation-t és folyamatosan szemetel is a kernel logba), összesen 6 vinyó, ebből 4db raid5-ben adja a kiajánlott tárhelyet. Átlagban kb 20 virtuális gép használja folyamatosan, tehát van terhelés folyamatosan. Ami jól látható, hogy a libata generál több interruptot, mint a hálókártya, de nagyjából összemérhető mennyiséget, nálad viszont két nagyságrenddel több interrupt jön a hálókártyától, mint a vinyótól. Szóval szerintem jól látod, hogy valami nincs ott rendjén.
Nem tudom, hogy átmenetileg kihúzható-e a gép a szolgálatból, mert ha igen, akkor meg kéne próbálni külön letesztelni, hogy mi történik, ha dd-vel olvasol/írsz vinyóra (lehetőleg üres partícióra :) ), illetve netcattal próbaforgalmat csinálni a hálókártyán. Apropó nem tudom kérdezte-e már valaki, hogy a dmesg-be nem szemetel-e sok-sok hibaüzenetet valami?
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Úgy látszik még csak tüneti kezelésnek sem volt jó a noatime, mert a load 30 körül mozog...
Dmesgbe nincs semmi, naponta párszor van csak siráma de semmi egetverő.

Volt rá példa, hogy 40GB-t másoltam egyik vinyóról a másikra, akkor még nem volt terhelve a gép, és akkor folyamatosan 40MB/sec volt a sebesség.
Ráadásul ha csak az egyik vinyóval lenne gond, akkor nem lenne "igazi load". Arra gondolok, hogy 500as load is lehet egy gépen pl. ha nfsről van valami mountolva de az elérhetetlen, ettől függetlenül a gép nem lassul be.
Az én esetemben viszont érezhető a 30as load, kell neki idő amíg belép SSH-n stb...

Azt hiszem, hogy mindenképpen ki fogok próbálni egy normális hálókártyát.
Milyet tudtok ajánlani amit rendesen támogat a linux és nem aranyáron van?
Nézegettem szerverbe szánt intel hálókártyákat, azok elég horror áron mennek...

Az a para, hogy RHEL5 van azon a gépen (de lehet, hogy már nem sokáig) és a hivatalos redhatos 2.6.18-as kernelbe nem portolják vissza a sky2 driver bugfixeit, így nem tudom, hogy időközben javították-e a kernelben a hibákat. Annyi viszont biztos, hogy a sky2 és a sgke driverek eléggé work in progress jellegűek, minden kernelverzióban vannak kritikus hibajavítások ezekben. Szóval az, hogy meg vagy elégedve vele, az mondjuk az óriási mázli kategória.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Hát figyu azért pendrivenál nem nagyon van seek time, ami vinyónál nem egy elhanyagolható szempont :)
Itt nem az a probléma, hogy nem tud a vinyó 50Mbitet írni, tud az 40MByte-ot is, de ez ugye az ideális eset. Egy hálózati szolgáltatásnál a legritkább eset az amikor 1 socketen keresztül csordogál a 100MBit. Ehelyett akár többszáz socket is nyitva lehet...
A legszarabb 1000 forintos tplink hálókártya is bírja a 100Mbitet ha 1 szálon megy át rajta az adat egy irányba :)

Én igazából csak az intel e1000-esekkel voltam idáig maximálisan megelégedve. Ez tényleg mindent tud, checksum offload, interrupt moderation, jumbo frame, értelmes ethtool status dump, akármi. De a lényeg, hogy idáig a driverével még sosem volt semmi baj, nem hibázik, nem dobál el csomagokat, nem veszti el a linket több hónapos folyamatos üzem esetén sem. Sima 32 bites pci buszon csak ezzel sikerült 840mbit/s-et elérni, más pci-os kártyák jó esetben olyan 750 körül tudnak (realtek), rosszabb esetben inkább csak 550 körül (asszem ez Marvell 88E8016 volt, skge driverrel).
Használtan néha lehet szerezni PCI32-es e1000-est 3-4000 körüli áron, de szemfülesnek kell lenni. Még egy érdekesség, bár hivatalosan tagadják, de a sima 32bit/33MHz-esnek jelölt változat valójában támogat 66MHz-es PCI buszt is, így már 930Mbit/s is simán kijön belőle. Ez kb a maximum gigabit ethernetnél TCP kapcsolat payloadot mérve, a PCI-Express-es kárták is max. ennyit tudnak.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( pinyo_villany | 2007. 12. 28., p – 12:36 )

videokártya nem kavar be? mert több postban is lehetett már olvasni rejtélyes dolgokról (keress rá...), amikor a videokártya okozta a gondot

linux v2.6.22.14 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.15-pancs1

( lacika v | 2007. 12. 28., p – 13:25 )

Egy idevágó kérdésem lenne. A /proc/interrupts -ból nekem egy sor így fest: 


19:     352986  637010561   IO-APIC-fasteoi   aic7xxx, eth0

Ez azt jelentené, hogy a SCSI vezérlőm és a hálózati kártyám ugyan azt az megszakítást használják?
Mert nekem a SCSI diszkek sebessége elég gyatra.

--
http://laszlo.co.hu/

Itt valami fogalmi zavar lehet, amit próbálok eloszalatni. A HW megszakítások egy un. megszakítás vezérlőn keresztül jutnak el a CPU-hoz. Megszakítást sok minden előidézhet, pl. RTC túlcsordulás, regiszter túlcsordulás, külsö 0-1 vagy 1-0 átmenet (élvezérelt), 0-val való osztás stb. A CPU megszakítás vektortáblából eldönti hogy melyik programrészt kell végrehajtani. Megszakítást az operációs rendszer és a felhasználói programok is meghívhatnak (előidészhetnek).
Most nincs emlékképem hogy a processzor INT lába konkrétan mit is takar, ezt meg kéne nézni a kataloguslapján. Emlékeim szerint a 8086-os már 256 megszakítást tudott lekezelni.

Abban sem vagyok biztos hogy a PCI busz használ direktben megszakítást, és az INT lábon amit írsz nem valami külső vezérlőjelet jelölnek meg.

Nem akarok nagy marhaságot írni -már csak ezért sem mert bevallom, nem sok fogalmam van az SCSI protocol felépítéséről, és a PCI-hoz sem konyítok-, de az eszköz lassúlásának nem sok köze lehet a megszakítás kezeléshez. Ott inkább valami adatforgalmi vagy konfigurációs problémákat feltételeznék.