Hohe load durch Interrupts

[crotchmaster]

Hi,

eine habe ich noch, oder so ähnlich.

Wie schon in meiner vorherigen Frage gepostet, habe ich eine OpenBSD 3.9 (i386) Kiste die soweit auch ganz gut läuft. Ich bin seit fast einem Tag dabei, die Ursache dafür zu finden, warum auf der Maschine die Interrupts für eine CPU-Auslastung von etwas über 20% sorgen. Ich würde es gern abstellen wollen, finde aber die Ursache dafür nicht. Oder muss ich damit leben?

Maschine ist ein PIII 450MHz, 384MB RAM, 2 4-Fach Netzwerkkarten, 2 IDE-HD als raid0 mittels raidframe.
Laufen tuen darauf: 3x Snort 2.4.x, 3x barnyard 0.2.0, 1x MySQL 5.0.22, 2x Squid, Apache mit PHP4 für BASE (ACID-Nachfolger), symon + syweb

Hier ein paar Ausgaben:
dmesg:

OpenBSD 3.9-stable (CERBERUS) #2: Tue Jul 11 13:29:02 CEST 2006
    toor@cerberus.domain.tld:/usr/src/sys/arch/i386/compile/CERBERUS
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 451 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,SER,MMX,FXSR,SSE
cpu0: disabling processor serial number
real mem  = 402227200 (392800K)
avail mem = 363360256 (354844K)
using 4278 buffers containing 20213760 bytes (19740K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(06) BIOS, date 03/03/00, BIOS32 rev. 0 @ 0xf0520
apm0 at bios0: Power Management spec V1.2 (BIOS mgmt disabled)
apm0: APM power management enable: unrecognized device ID (9)
apm0: APM engage (device 1): power management disabled (1)
apm0: AC on, battery charge unknown
apm0: flags b0102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf0000/0xd92
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0d10/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:04:0 (vendor 0x8086 product 0x122e rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc0000/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 vendor 0x8086 product 0x7190 rev 0x03
ppb0 at pci0 dev 1 function 0 vendor 0x8086 product 0x7191 rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 vendor 0x1002 product 0x4742 rev 0x5c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 4 function 0 vendor 0x8086 product 0x7110 rev 0x02
pciide0 at pci0 dev 4 function 1 vendor 0x8086 product 0x7111 rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <IBM-DJNA-370910>
wd0: 16-sector PIO, LBA, 8693MB, 17803440 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <, ATAPI CDROM.48X, 120Y> SCSI0 5/cdrom removable
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
wd1 at pciide0 channel 1 drive 0: <IBM-DJNA-370910>
wd1: 16-sector PIO, LBA, 8693MB, 17803440 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vendor 0x8086 product 0x7112 (class serial bus subclass USB, rev 0x01) at pci0 dev 4 function 2 not configured
piixpm0 at pci0 dev 4 function 3 vendor 0x8086 product 0x7113 rev 0x02: SMI
iic0 at piixpm0
"unknown" at iic0 addr 0x18 not configured
"w83781d" at iic0 addr 0x2d not configured
"unknown" at iic0 addr 0x48 not configured
"unknown" at iic0 addr 0x49 not configured
ppb1 at pci0 dev 9 function 0 vendor 0x1011 product 0x0024 rev 0x01
pci2 at ppb1 bus 2
de0 at pci2 dev 4 function 0 vendor 0x1011 product 0x0009 rev 0x22: irq 7
de0: Cogent EM440TX  pass 2.2 address 00:00:92:a7:5b:11
de1 at pci2 dev 5 function 0 vendor 0x1011 product 0x0009 rev 0x22
de1: Cogent EM440TX  pass 2.2 address 00:00:92:a7:5b:12
de2 at pci2 dev 6 function 0 vendor 0x1011 product 0x0009 rev 0x22
de2: Cogent EM440TX  pass 2.2 address 00:00:92:a7:5b:13
de3 at pci2 dev 7 function 0 vendor 0x1011 product 0x0009 rev 0x22
de3: Cogent EM440TX  pass 2.2 address 00:00:92:a7:5b:14
ppb2 at pci0 dev 11 function 0 vendor 0x1011 product 0x0024 rev 0x02
pci3 at ppb2 bus 3
de4 at pci3 dev 4 function 0 vendor 0x1011 product 0x0009 rev 0x22: irq 10
de4: Cogent EM440TX  pass 2.2 address 00:00:92:a7:8e:18
de5 at pci3 dev 5 function 0 vendor 0x1011 product 0x0009 rev 0x22
de5: Cogent EM440TX  pass 2.2 address 00:00:92:a7:8e:19
de6 at pci3 dev 6 function 0 vendor 0x1011 product 0x0009 rev 0x22
de6: Cogent EM440TX  pass 2.2 address 00:00:92:a7:8e:1a
de7 at pci3 dev 7 function 0 vendor 0x1011 product 0x0009 rev 0x22
de7: Cogent EM440TX  pass 2.2 address 00:00:92:a7:8e:1b
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lm0 at isa0 port 0x290/8: W83781D
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask fb65 netmask ffe5 ttymask ffe7
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
Kernelized RAIDframe activated
raid0 (root): (RAID Level 1) total number of sectors is 17737600 (8660 MB) as root
dkcsum: wd0 matches BIOS drive 0x80
dkcsum: wd1 matches BIOS drive 0x81
rootdev=0x1300 rrootdev=0x3600 rawdev=0x3602
raid0: Device already configured!

vmstat -iz:

interrupt                       total     rate
irq14/pciide0                   16840        4
irq15/pciide0                   17936        4
irq7/de0                         3840        1
irq10/de4                          37        0
irq1/pckbc0                         0        0
irq4/pccom0                      7478        2
irq3/pccom1                         0        0
irq6/fdc0                           0        0
irq0/clock                     361811      100
irq8/rtc                       463133      128
Total                          871075      241

vmstat 1 10:

procs   memory        page                    disks     traps         cpu
 r b w    avm    fre   flt  re  pi  po  fr  sr wd0 cd0  int   sys   cs us sy id
 1 2 0 239072  97276   237   0   0   0   0   0   5   0  241   802   87 16 23 61
 1 2 0 239076  97276    25   0   0   0   0   0   0   0  231   131   48 82 18  0
 1 2 0 239076  97276     8   0   0   0   0   0   0   0  231    88   44 82 18  0
 1 2 0 239076  97276     7   0   0   0   0   0   0   0  232    81   41 79 21  0
 1 2 0 239076  97276     7   0   0   0   0   0   0   0  230    88   44 80 20  0
 1 2 0 239076  97280   101   0   0   0   0   0   0   0  232   966  167 72 28  0
 1 2 0 239076  97280     7   0   0   0   0   0   0   0  231    90   43 78 22  0
 1 2 0 239076  97280     7   0   0   0   0   0   0   0  240    84   51 77 23  0
 1 2 0 239076  97280     7   0   0   0   0   0   0   0  247    87   56 77 23  0
 1 2 0 239076  97280     7   0   0   0   0   0   0   0  231    84   39 79 21  0

Ich hoffe, ihr könnt mir weiterhelfen.

Gruß c.

 

[worldi]

So wie ich das sehe, ist die Kiste schlichtweg am Limit. Möglicherweise kannst du mit IRQ-Sharing noch bissel was rauskitzeln; SCSI-Adapter und -Platten würden sicherlich auch helfen.

Du kannst Dir ja das hier mal reinziehen: http://www.bsdchina.org/articles/openbsd/tuning_openbsd.pdf


HTH, Gruß W.

 

[Vincent Vega]

So wie ich das sehe, ist die Kiste schlichtweg am Limit. Möglicherweise kannst du mit IRQ-Sharing noch bissel was rauskitzeln

Teilen sich mehrere Geräte einen Interrupt, muss Software entscheiden welches Gerät eben unterbrochen hat. Die Folge ist eher eine höhere Last als eine niedrigere. Aber vielleicht hab' ich ja auch nur Deinen Satz missverstanden.

Ah, jetzt ist auch das verlinkte Dokument da. Die Logik da drin erschließt sich mir aber nicht ganz denn der Interrupt Handler muss trotzdem erst einmal checken von wo der Interrupt kam, d.h. er muss vor und nach seiner Ausführung eine Art Polling durchführen. Ich glaube nicht, dass dies die Interrupt-Last signifikant senkt oder die Leistung generell verbessert.

Polling, d.h. das Blockieren aller Interrupts eines Geräts kann durchaus den Overhead verringern, speziell bei Netzwerkkarten. Man bedenke: Jedes Paket löst einen Interrupt aus!

Da der Threadstarter aber schreibt er betreibe die zwei wd(4) Geräte mit raidframe(4), könnte man jetzt auf raidframe(4) tippen. Zwei Indizien fallen mir gerade auf: Zum einen ist die Anzahls der Faults recht hoch, das mag aber noch nichts bedeuten. Zum andern aber steht die Anzahl der IRQ14- und IRQ15-Zähler im Missverhältnis zu den Clock-Interrupts (wenn ich das mal mit meinen Geräten vergleiche). Ich tippe also, dass raidframe(4) viel CPU verbrät.

 

[crotchmaster]

Hallo,

ich habe mich eben des Problems nochmal angenommen und mir die Kiste nochmal richtig vorgeknöpft..

Ich habe jetzt die Quelle der Interrupts gefunden. Es sind die beiden 4-fach Netzwerkkarten. Wenn ich beide ausbaue, ist das System zu 99% idle, egal ob im normalen Betrieb oder im single user mode und unabhängig davon, ob netzwerkkabel eingesteckt sind oder nicht.

Baue ich eine der Karten wieder ein, steigt die Belastung durch Interrupts wieder auf etwas über 10%, bei beiden wieder auf ca. 21%, auch im sinlge user mode. Ein Rumspielen mit IRQs bzw. Umstecken der beiden Karten brachte keinen Erfolg. Ich werde wohl damit leben müssen, oder mittels Brechstange eine schnellere CPU reinstecken müssen.

Danke trotzdem für Eure Anregungen.

Gruß c.

 

[crotchmaster]

nochmal ein kleiner abschließender Bericht

Ich habe heute nochmal Mr. Google befragt und habe so einiges herausgefunden.

Die beiden 4-fach Karten werden vom de-Treiber ja als Cogent-EM440TX (DEC21140-AE Chips) erkannt. Über Google habe ich herausgefunden, das der dc-Treiber ebenfalls DEC 21x4x-basierte Karten erkennt, aber der de-Treiber eine höhere Priorität hat und dadurch beim GENERIC Kernel solche Karten als de-Devices erkannt werden. Also habe ich einen neuen Kernel gebacken und dafür vorher den de-Treiber entfernt und den dc-Treiber + dcphy aktiviert. Die Kiste bootete auch schön, solange ich die hostname.deX Datei noch nicht in hostname.dcX umbennant hatte. Die Ausgaben von vmstat und top sahen top aus. Kaum noch Belastung durch Interrupts, das System idlete bei 99% rum. Da habe ich mich schon riesig gefreut und flux die hostname.deX Dateien umbenannt und die Kiste neugestartet. Bei 'starting network' blieb die Kiste dann stehen und rührte sich nicht mehr. Das gleiche passierte, als ich in den sinlge user mode startete und ein ifconfig auf ein dc-Device absetzte. Schade, da kann ich mir den Erfolg mit der geringeren Interruptbelastung durch die Karten in die Haare schmieren.

Nun bin ich wieder zum de-Treiber zurückgegangen.

Gruß c.