Hi, ich habe hier bei einem recht neuen Server gravierende Netzwerk-Probleme: Onboard sind 4 GBit-Netzwerkkarten, der Server wird u.a. als Router eingesetzt und dann ist bei ca. 140 MBit/s das Leistungsmaximum erreicht. CPUs: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (in /proc/cpuinfo sind 12 logische CPUs gelistet) Netzwerkkarten (lspci): 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 2 Netzwerkkarten sind am Haupt-Traffic beteiligt, die 3. geht auf ein kleines Nebennetz, die 4. ist gar nicht in Verwendung. "ethtool" meldet: # ethtool -i eth0 driver: tg3 version: 3.137 firmware-version: 5719-v1.37 NCSI v1.2.37.0 bus-info: 0000:02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no Die Load-Werte (aus "uptime") liegen in Spitzenzeiten nur bei ca. 2-3. IO-Wait ist auch sehr gering (auch lt. iostat) Auf der CPU 0 habe ich einen sehr hohen Soft-IRQ-Anteil bemerkt. Aber auch ein Ändern der CPU-Affinity der betreffenden Netzwerk-Interrupts hat leider beim Durchsatz nichts gebracht. (Info aus: cat /proc/interrupts|egrep "CPU|eth") (Setzen mit "echo 004
/proc/irq/38/smp_affinity" usw.)
Buffer-Space habe ich per sysctl bereits vergrößert. Wo könnten noch Engpässe liegen? Wie kann ich noch Engpässe aufspüren? Wo kann ich den Hebel ansetzen? Viele kleine Router, die Linux als Betriebssystem einsetzen, haben da mehr Datendurchsatz als dieser Server. Vorab schon mal Danke! Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo! Hatte nicht schon mal jemand zufällig dieses Problem? Denke ich vielleicht zu kompliziert? Gruß Günther Am 2015-01-18 um 00:34 schrieb Günther Zinsberger:
Hi,
ich habe hier bei einem recht neuen Server gravierende Netzwerk-Probleme:
Onboard sind 4 GBit-Netzwerkkarten, der Server wird u.a. als Router eingesetzt und dann ist bei ca. 140 MBit/s das Leistungsmaximum erreicht.
CPUs: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (in /proc/cpuinfo sind 12 logische CPUs gelistet)
Netzwerkkarten (lspci): 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 02:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
2 Netzwerkkarten sind am Haupt-Traffic beteiligt, die 3. geht auf ein kleines Nebennetz, die 4. ist gar nicht in Verwendung.
"ethtool" meldet: # ethtool -i eth0 driver: tg3 version: 3.137 firmware-version: 5719-v1.37 NCSI v1.2.37.0 bus-info: 0000:02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no
Die Load-Werte (aus "uptime") liegen in Spitzenzeiten nur bei ca. 2-3. IO-Wait ist auch sehr gering (auch lt. iostat)
Auf der CPU 0 habe ich einen sehr hohen Soft-IRQ-Anteil bemerkt. Aber auch ein Ändern der CPU-Affinity der betreffenden Netzwerk-Interrupts hat leider beim Durchsatz nichts gebracht. (Info aus: cat /proc/interrupts|egrep "CPU|eth") (Setzen mit "echo 004
/proc/irq/38/smp_affinity" usw.)
Buffer-Space habe ich per sysctl bereits vergrößert.
Wo könnten noch Engpässe liegen? Wie kann ich noch Engpässe aufspüren? Wo kann ich den Hebel ansetzen? Viele kleine Router, die Linux als Betriebssystem einsetzen, haben da mehr Datendurchsatz als dieser Server.
Vorab schon mal Danke! Gruß Günther
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 20. Januar 2015, 22:37:45 schrieb Günther Zinsberger:
Hatte nicht schon mal jemand zufällig dieses Problem? Denke ich vielleicht zu kompliziert?
Also wenn man nach tg3 und solchen Problemen googelt kommt leider nicht allzu viel bei rum. Nur ganz alte Sachen, die aber auch von vielen Interrupts berichten, hier allerdings Hardware-Interrupts: https://lkml.org/lkml/2008/3/27/206 Der aktuelle Treiber vom Hersteller ist bei 3.136h und der im Kernel wohl der von dir benutzte bei 3.137. Zu der Firmware finde ich nichts, die wird vielleicht nicht einzeln sondern mit dem BIOS aktualisiert. Gibt es ein BIOS-Update für das Board? Sind die Ausgaben von ethtool zur Geschwindigkeit, Duplex etc. unauffällig? Kannst du einen Hardware-Defekt ausschließen? Was sagt "ethtool -t eth0"? Gruß Jan -- There is no such thing as a fail-safe design. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo! Am 2015-01-24 um 11:39 schrieb Jan Ritzerfeld:
Am Dienstag, 20. Januar 2015, 22:37:45 schrieb Günther Zinsberger:
Hatte nicht schon mal jemand zufällig dieses Problem? Denke ich vielleicht zu kompliziert? Also wenn man nach tg3 und solchen Problemen googelt kommt leider nicht allzu viel bei rum. Nur ganz alte Sachen, die aber auch von vielen Interrupts berichten, hier allerdings Hardware-Interrupts: https://lkml.org/lkml/2008/3/27/206 So schlimm wie in diesem Artikel beschrieben ist es zum Glück bei mir nicht (2 Mbps auf 1 Gbps-Interface), ich habe ca. 120-140 Mbps Durchsatz. Auch das beschriebene Verhalten tritt bei mir nicht auf.
Der aktuelle Treiber vom Hersteller ist bei 3.136h und der im Kernel wohl der von dir benutzte bei 3.137. Zu der Firmware finde ich nichts, die wird vielleicht nicht einzeln sondern mit dem BIOS aktualisiert. Gibt es ein BIOS-Update für das Board?
Sind die Ausgaben von ethtool zur Geschwindigkeit, Duplex etc. unauffällig? Kannst du einen Hardware-Defekt ausschließen? Was sagt "ethtool -t eth0"? "ethtool -t eth0" traue ich mich momentan nicht, da der Server gerade
Im Artikel wird noch die Ausgabe von "lspci -vvv" erwähnt. Bei mir kommt
dann (bei einer der Karten) heraus:
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
Gigabit Ethernet PCIe (rev 01)
Subsystem: Hewlett-Packard Company Device 3372
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
Am Samstag, 24. Januar 2015, 15:49:28 schrieb Günther Zinsberger:
Hallo!
Am 2015-01-24 um 11:39 schrieb Jan Ritzerfeld:
Am Dienstag, 20. Januar 2015, 22:37:45 schrieb Günther Zinsberger:
Hatte nicht schon mal jemand zufällig dieses Problem? Denke ich vielleicht zu kompliziert?
Also wenn man nach tg3 und solchen Problemen googelt kommt leider nicht allzu viel bei rum. Nur ganz alte Sachen, die aber auch von vielen Interrupts berichten, hier allerdings Hardware-Interrupts: https://lkml.org/lkml/2008/3/27/206
So schlimm wie in diesem Artikel beschrieben ist es zum Glück bei mir nicht (2 Mbps auf 1 Gbps-Interface), ich habe ca. 120-140 Mbps Durchsatz. Auch das beschriebene Verhalten tritt bei mir nicht auf.
Hmm. Vielleicht noch einmal kurz zum Offensichtlichen, nur zur Sicherheit: Die Karten handeln schon 1Gbps vollduplex aus? Und in der Ausgabe von dmesg sieht auch alles sauber aus? Und es werden auch nicht besonders viele Pakete als fehlerhaft verworfen?
Im Artikel wird noch die Ausgabe von "lspci -vvv" erwähnt. Bei mir kommt dann (bei einer der Karten) heraus: (...). Kann die Ausgabe leider nicht beurteilen, weil ich mich da zu wenig auskenne. (die "Device Serial Number" habe ich ein wenig nachgebessert, der Rest ist original so)
Ich leider auch nicht. Ich hoffe mal, dass es nicht am Powermanagement liegt. Wenn ich die README des Herstellertreibers richtig verstehe, dann ist die Möglichkeit das auszuschalten der einzige Unterschied zum Treiber im Kernel.
Sollten mir die vielen Zeilen mit "Unknown:" Kopfzerbrechen bereiten?
Mir bereiten sie Kopfzerbrechen. Ich habe sowas noch nie gesehen, aber auch selten lspci -vvv auf Servern ausprobiert. Passt denn wenigstens die Längenangabe vor den ganzen Null-Bytes (^@) zu der Anzahl an Zeilen mit Null-Bytes?
Was sind "GT/s"? (http://de.wikipedia.org/wiki/Megatransfer ?) 2,5 GT/s sollten dann reichen?
PCIe x2 gen2 schafft brutto 1000MB/s und 5GT/s, das steht da ja auch irgendwo. Selbst wenn da nur die Hälfte netto raus käme ...
(...). Auf den genannten Server komme ich momentan nur per Remote drauf. Ohne anschließendem Reboot ist mir diesen Befehl aktuell zu gefährlich. Mal sehen, wann ich das machen kann.
Ah, okay. Eigentlich sollte danach nicht so viel kaputt sein, aber währenddessen kann das wohl passieren.
Hardware-Defekt: prinzipiell ausschließen kann ich gar nichts. Wir hatten nur ähnliche Probleme beim alten Server (Baujahr 2006) und haben es da auf die alte Hardware geschoben. Mit der neuen Hardware ist es aber nur "einen Deut" besser geworden. Ich vermute, dass ich irgendwo mit "angezogener Handbremse" fahre, hab aber keine Ahnung wo.
Sehr spannend. HP kann man da nicht fragen, ob Probleme mit speziellen Kernels oder Distributionen bekannt sind?
Andererorts wird darüber diskutiert, dass mit Linux bei manchen NW-Karten mit 10Gbps aktuell nicht die volle Leistung gefahren werden kann, und ich habe hier schon Probleme mit 1Gbps-Karten ;-).
Ja, echt blöd! Mein WLAN ist ja schneller als dein Gigabit-Ethernet. Von den Intel-Ethernet-Adaptern in meinen ThinkPads mal ganz zu schweigen. Gruß Jan -- When guns are outlawed, only outlaws will have guns. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 2015-01-24 um 18:27 schrieb Jan Ritzerfeld:
Am Samstag, 24. Januar 2015, 15:49:28 schrieb Günther Zinsberger:
So schlimm wie in diesem Artikel beschrieben ist es zum Glück bei mir nicht (2 Mbps auf 1 Gbps-Interface), ich habe ca. 120-140 Mbps Durchsatz. Auch das beschriebene Verhalten tritt bei mir nicht auf. Hmm. Vielleicht noch einmal kurz zum Offensichtlichen, nur zur Sicherheit: Die Karten handeln schon 1Gbps vollduplex aus? Und in der Ausgabe von dmesg sieht auch alles sauber aus? Und es werden auch nicht besonders viele Pakete als fehlerhaft verworfen? Ja, das sollte passen:
# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: g Wake-on: g Current message level: 0x000000ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: yes ...bei eth1 sieht es gleich aus. relevante Teile aus "dmesg": [ 1.485664] tg3 0000:02:00.0 eth0: Tigon3 [partno(NA) rev 5719001] (PCI Express) MAC address 9c:8e:99:5f:12:92 [ 1.485670] tg3 0000:02:00.0 eth0: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [ 1.485674] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [ 1.485677] tg3 0000:02:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit] [...] [ 1.525635] tg3 0000:02:00.1 eth1: Tigon3 [partno(NA) rev 5719001] (PCI Express) MAC address 9c:8e:99:5f:12:93 [ 1.525641] tg3 0000:02:00.1 eth1: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [ 1.525645] tg3 0000:02:00.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [ 1.525648] tg3 0000:02:00.1 eth1: dma_rwctrl[00000001] dma_mask[64-bit] [ 1.589498] tg3 0000:02:00.2 eth2: Tigon3 [partno(NA) rev 5719001] (PCI Express) MAC address 9c:8e:99:5f:12:94 [ 1.589504] tg3 0000:02:00.2 eth2: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [ 1.589508] tg3 0000:02:00.2 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [ 1.589522] tg3 0000:02:00.2 eth2: dma_rwctrl[00000001] dma_mask[64-bit] [ 1.645297] tg3 0000:02:00.3 eth3: Tigon3 [partno(NA) rev 5719001] (PCI Express) MAC address 9c:8e:99:5f:12:95 [ 1.645304] tg3 0000:02:00.3 eth3: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [ 1.645308] tg3 0000:02:00.3 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [ 1.645311] tg3 0000:02:00.3 eth3: dma_rwctrl[00000001] dma_mask[64-bit] [ 1.646951] tg3 0000:02:00.2 san0: renamed from eth2 [ 1.673755] systemd-udevd[147]: renamed network interface eth2 to san0 [ 1.673762] tg3 0000:02:00.3 eno4: renamed from eth3 [ 1.690249] systemd-udevd[145]: renamed network interface eth3 to eno4 [...] [ 2.595725] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [...] [ 6.182104] tg3 0000:02:00.0 eth0: Link is up at 1000 Mbps, full duplex [ 6.182110] tg3 0000:02:00.0 eth0: Flow control is off for TX and off for RX [ 6.182113] tg3 0000:02:00.0 eth0: EEE is disabled [ 6.182152] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [...] [ 15.477358] tg3 0000:02:00.1 eth1: Link is up at 1000 Mbps, full duplex [ 15.477368] tg3 0000:02:00.1 eth1: Flow control is off for TX and off for RX [ 15.477374] tg3 0000:02:00.1 eth1: EEE is disabled [...] [ 36.982221] device eth1 entered promiscuous mode P.S.: IPv6 ist deaktiviert P.P.S.: "promiscuous mode" läuft wegen Accountings. Könnte das so stark bremsen? Da der Port ja an einem Switch hängt sollten es auch nicht mehr empfangene Pakete sein. Hab nochmals nachgesehen: eigentlich ist die Konfiguration in "netacct-mysql" auf "not setting PROMISC mode" gestellt. Woher der "promiscuous mode" wohl kommt?? Tcpdump oder Wireshark laufen zu diesem Zeitpunkt auch nicht. Pakete als fehlerhaft verworfen? Wo kann ich das zuverlässig feststellen? Collectd läuft auch, und da ist der error-count durchgängig auf 0.
Im Artikel wird noch die Ausgabe von "lspci -vvv" erwähnt. Bei mir kommt dann (bei einer der Karten) heraus: (...). Kann die Ausgabe leider nicht beurteilen, weil ich mich da zu wenig auskenne. (die "Device Serial Number" habe ich ein wenig nachgebessert, der Rest ist original so) Ich leider auch nicht. Ich hoffe mal, dass es nicht am Powermanagement liegt. Wenn ich die README des Herstellertreibers richtig verstehe, dann ist die Möglichkeit das auszuschalten der einzige Unterschied zum Treiber im Kernel.
Kann man irgendwo feststellen, ob kurzzeitig immer wieder das Powermanagement aktiv wird?
Sollten mir die vielen Zeilen mit "Unknown:" Kopfzerbrechen bereiten? Mir bereiten sie Kopfzerbrechen. Ich habe sowas noch nie gesehen, aber auch selten lspci -vvv auf Servern ausprobiert. Passt denn wenigstens die Längenangabe vor den ganzen Null-Bytes (^@) zu der Anzahl an Zeilen mit Null-Bytes? Nein, gar nicht. Auf jeden Fall sind es im ersten Block 85 Zeilen. Mit je 2 ^@-Zeichen?? Im 2. Block sind es dann nochmals 85 solche Zeilen. (...). Auf den genannten Server komme ich momentan nur per Remote drauf. Ohne anschließendem Reboot ist mir diesen Befehl aktuell zu gefährlich. Mal sehen, wann ich das machen kann. Ah, okay. Eigentlich sollte danach nicht so viel kaputt sein, aber währenddessen kann das wohl passieren.
Hardware-Defekt: prinzipiell ausschließen kann ich gar nichts. Wir hatten nur ähnliche Probleme beim alten Server (Baujahr 2006) und haben es da auf die alte Hardware geschoben. Mit der neuen Hardware ist es aber nur "einen Deut" besser geworden. Ich vermute, dass ich irgendwo mit "angezogener Handbremse" fahre, hab aber keine Ahnung wo. Sehr spannend. HP kann man da nicht fragen, ob Probleme mit speziellen Kernels oder Distributionen bekannt sind? Naja, es betrifft mehrere Kernels (siehe unten). Andererorts wird darüber diskutiert, dass mit Linux bei manchen NW-Karten mit 10Gbps aktuell nicht die volle Leistung gefahren werden kann, und ich habe hier schon Probleme mit 1Gbps-Karten ;-). Ja, echt blöd! Mein WLAN ist ja schneller als dein Gigabit-Ethernet. Von den Intel-Ethernet-Adaptern in meinen ThinkPads mal ganz zu schweigen.
Meinte z.B. diesen Artikel hier: http://www.pro-linux.de/news/1/21606/linux-318-erhaelt-schnellere-netzwerk-s... "... So kann nach ersten Messungen eine 40 Gbit-Netzwerkkarte vollständig ausgelastet werden..." P.S.: auf diesem Server läuft inzwischen (seit ca. Anfang Jänner) ein selbst kompilierter Kernel 3.18.1 (wie im Pro-Linux-Artikel erwähnt). Ob mir da ein Fehler unterlaufen ist? Vorher hatte ich 3.12.27 drauf, da war es das Selbe. Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Kleine Ergänzung noch zu einem Teilaspekt: Am 2015-01-24 um 22:19 schrieb Günther Zinsberger:
[ 36.982221] device eth1 entered promiscuous mode P.P.S.: "promiscuous mode" läuft wegen Accountings. Könnte das so stark bremsen? Da der Port ja an einem Switch hängt sollten es auch nicht mehr empfangene Pakete sein. Hab nochmals nachgesehen: eigentlich ist die Konfiguration in "netacct-mysql" auf "not setting PROMISC mode" gestellt. Woher der "promiscuous mode" wohl kommt?? Tcpdump oder Wireshark laufen zu diesem Zeitpunkt auch nicht.
"promiscuous mode" zu diesem Zeitpunkt ist nach neuesten Erkenntnissen legitim: das aktiviert "arpwatch" und lässt sich nicht ändern. Bleibt die Frage zu diesem Punkt: könnte das die Performance groß beeinflussen? (das Interface hängt an einem Switch-Port ohne Port-Mirroring) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, 24. Januar 2015, 22:19:14 schrieb Günther Zinsberger:
Am 2015-01-24 um 18:27 schrieb Jan Ritzerfeld:
Am Samstag, 24. Januar 2015, 15:49:28 schrieb Günther Zinsberger:
So schlimm wie in diesem Artikel beschrieben ist es zum Glück bei mir nicht (2 Mbps auf 1 Gbps-Interface), ich habe ca. 120-140 Mbps Durchsatz. Auch das beschriebene Verhalten tritt bei mir nicht auf.
Hmm. Vielleicht noch einmal kurz zum Offensichtlichen, nur zur Sicherheit: Die Karten handeln schon 1Gbps vollduplex aus? Und in der Ausgabe von dmesg sieht auch alles sauber aus? Und es werden auch nicht besonders viele Pakete als fehlerhaft verworfen?
Ja, das sollte passen: (...).
Gut, flow control wird von den Switches her deaktiviert, aber das sollte ja nicht schlimm sein.
P.P.S.: "promiscuous mode" läuft wegen Accountings. Könnte das so stark bremsen? Da der Port ja an einem Switch hängt sollten es auch nicht mehr empfangene Pakete sein. (...).
Korrekt, eigentlich sollte der dann nichts stark ausbremsen. Aber kannst du arpwatch nicht mal testweise deaktivieren?
Pakete als fehlerhaft verworfen? Wo kann ich das zuverlässig feststellen? Collectd läuft auch, und da ist der error-count durchgängig auf 0.
Zuverlässig? Puh. Vielleicht "ethtool -S eth0"? Oder /sys/class/net/eth0/statistics/*?
(...).
Ich leider auch nicht. Ich hoffe mal, dass es nicht am Powermanagement liegt. Wenn ich die README des Herstellertreibers richtig verstehe, dann ist die Möglichkeit das auszuschalten der einzige Unterschied zum Treiber im Kernel.
Kann man irgendwo feststellen, ob kurzzeitig immer wieder das Powermanagement aktiv wird?
Also dass es ausgeschaltet ist/wird steht ja in deinem dmesg-Auszug. Ich würde erwarten, dass das dann auch wieder da auftauchen würden, wenn es wieder aktiviert wird. Aber wer weiß das schon ...
Sollten mir die vielen Zeilen mit "Unknown:" Kopfzerbrechen bereiten?
Mir bereiten sie Kopfzerbrechen. Ich habe sowas noch nie gesehen, aber auch selten lspci -vvv auf Servern ausprobiert. Passt denn wenigstens die Längenangabe vor den ganzen Null-Bytes (^@) zu der Anzahl an Zeilen mit Null-Bytes?
Nein, gar nicht. Auf jeden Fall sind es im ersten Block 85 Zeilen. Mit je 2 ^@-Zeichen?? Im 2. Block sind es dann nochmals 85 solche Zeilen.
Komisch. Ich konnte über Google nichts finden, bei anderen Leuten mit dieser oder ähnlichen Karten kommt habe ich sowas nicht gesehen.
(...).
Sehr spannend. HP kann man da nicht fragen, ob Probleme mit speziellen Kernels oder Distributionen bekannt sind?
Naja, es betrifft mehrere Kernels (siehe unten).
In alten Threads über tg3-Probleme stand, dass man mal das ganze Checksuming und Offloading deaktivieren sollte. Jedenfalls dann, wenn man viele dropped packets hat: ethtool -K eth0 tx off ethtool -K eth0 rx off ethtool -K eth0 gso off ethtool -K eth0 tso off
Andererorts wird darüber diskutiert, dass mit Linux bei manchen NW-Karten mit 10Gbps aktuell nicht die volle Leistung gefahren werden kann, und ich habe hier schon Probleme mit 1Gbps-Karten ;-).
Ja, echt blöd! Mein WLAN ist ja schneller als dein Gigabit-Ethernet. Von den Intel-Ethernet-Adaptern in meinen ThinkPads mal ganz zu schweigen. Meinte z.B. diesen Artikel hier: http://www.pro-linux.de/news/1/21606/linux-318-erhaelt-schnellere-netzwerk -sendefunktion.html "... So kann nach ersten Messungen eine 40 Gbit-Netzwerkkarte vollständig ausgelastet werden..."
Okay, ich denke aber auch nicht, dass das dein Problem ist. :)
P.S.: auf diesem Server läuft inzwischen (seit ca. Anfang Jänner) ein selbst kompilierter Kernel 3.18.1 (wie im Pro-Linux-Artikel erwähnt). Ob mir da ein Fehler unterlaufen ist? Vorher hatte ich 3.12.27 drauf, da war es das Selbe.
Wenn das Problem nur nach deinem Kernel-Update aufgetreten wäre ... da es aber schon vorher da war ... Ansonsten, könnten denn die Switches Probleme machen? Denn die wurden ja nicht ersetzt, sondern nur der Server. Und die Probleme sind geblieben. Vielleicht sind liegt die Ursache außerhalb des Servers? Gruß Jan -- Attitude determines your altitude. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 2015-01-25 um 19:58 schrieb Jan Ritzerfeld:
Am Samstag, 24. Januar 2015, 22:19:14 schrieb Günther Zinsberger:
Ja, das sollte passen: (...). Gut, flow control wird von den Switches her deaktiviert, aber das sollte ja nicht schlimm sein. Guter Ansatzpunkt, glaube ich. Habe einen interessanten Artikel dazu gefunden: https://communities.intel.com/community/wired/blog/2012/01/13/go-with-the-fl... Im Artikel wird auch "rx_missed_errors" erwähnt, siehe unten. P.P.S.: "promiscuous mode" läuft wegen Accountings. Könnte das so stark bremsen? Da der Port ja an einem Switch hängt sollten es auch nicht mehr empfangene Pakete sein. (...). Korrekt, eigentlich sollte der dann nichts stark ausbremsen. Aber kannst du arpwatch nicht mal testweise deaktivieren? habe ich somit gemacht, bringt leider nichts.
Pakete als fehlerhaft verworfen? Wo kann ich das zuverlässig feststellen? Collectd läuft auch, und da ist der error-count durchgängig auf 0. Zuverlässig? Puh. Vielleicht "ethtool -S eth0"? Oder /sys/class/net/eth0/statistics/*? Sehr gute Idee!! Habe im Sys-Dateisystem einen einzigen verdächtigen Wert gefunden, und das könnte es sein!! # cat /sys/class/net/eth0/statistics/rx_missed_errors 557811
Und das, obwohl der Server gestern wegen eines anderen Fehlers rebootet werden musste!! Komischerweise gibt "ethtool -S eth0" diesen Wert mit dem aktuellen Treiber gar nicht aus. Beim Testserver bekomme ich den da schon ausgegeben.
(...).
Ich leider auch nicht. Ich hoffe mal, dass es nicht am Powermanagement liegt. Wenn ich die README des Herstellertreibers richtig verstehe, dann ist die Möglichkeit das auszuschalten der einzige Unterschied zum Treiber im Kernel. Kann man irgendwo feststellen, ob kurzzeitig immer wieder das Powermanagement aktiv wird? Also dass es ausgeschaltet ist/wird steht ja in deinem dmesg-Auszug. Ich würde erwarten, dass das dann auch wieder da auftauchen würden, wenn es wieder aktiviert wird. Aber wer weiß das schon ...
Ahhhh, ist das das "EEE"? (Energy-Efficient Ethernet) # ethtool --show-eee eth0 EEE Settings for eth0: EEE status: enabled - inactive Tx LPI: 2047 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: Not reported # ethtool --show-eee eth1 EEE Settings for eth1: EEE status: enabled - inactive Tx LPI: 2047 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: Not reported Habe es mal disabled: # ethtool --set-eee eth0 eee off # ethtool --set-eee eth1 eee off ...mal sehen, ob es was bringt.
In alten Threads über tg3-Probleme stand, dass man mal das ganze Checksuming und Offloading deaktivieren sollte. Jedenfalls dann, wenn man viele dropped packets hat: ethtool -K eth0 tx off ethtool -K eth0 rx off ethtool -K eth0 gso off ethtool -K eth0 tso off ...hab ich gemacht, mal sehen. Ansonsten, könnten denn die Switches Probleme machen? Denn die wurden ja nicht ersetzt, sondern nur der Server. Und die Probleme sind geblieben. Vielleicht sind liegt die Ursache außerhalb des Servers? Switch wurde auch schon mal probeweise gegen eine andere Marke getauscht. Hat nichts gebracht, wurde wieder zurückgetauscht.
Die beste Erfolgswahrscheinlichkeit sehe ich beim Nachforschen zu den hohen "rx_missed_errors"-Ständen. Nur leider habe ich im Zusammenhang mit "tg3" oder allgemein noch nicht das richtige dazu gefunden... Allgemeine Erklärung dazu: /sys/class/<iface>/statistics/rx_missed_errors: Indicates the number of received packets that have been missed due to lack of capacity in the receive side. See the network driver for the exact meaning of this value. Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 25. Januar 2015, 23:57:18 schrieb Günther Zinsberger:
Am 2015-01-25 um 19:58 schrieb Jan Ritzerfeld:
Am Samstag, 24. Januar 2015, 22:19:14 schrieb Günther Zinsberger:
Ja, das sollte passen: (...).
Gut, flow control wird von den Switches her deaktiviert, aber das sollte ja nicht schlimm sein.
Guter Ansatzpunkt, glaube ich.
Ich habe mit solchen Problemen auch noch nie zu kämpfen gehabt. Wobei, WLAN ist noch viel schlimmer, glaube ich.
(...).
Zuverlässig? Puh. Vielleicht "ethtool -S eth0"? Oder /sys/class/net/eth0/statistics/*?
Sehr gute Idee!!
Die Idee ist ja auch nicht von mir.
Habe im Sys-Dateisystem einen einzigen verdächtigen Wert gefunden, und das könnte es sein!! # cat /sys/class/net/eth0/statistics/rx_missed_errors 557811
Ja, das passt zu dem Artikel, den du gefunden hast. Allerdings sind diese 140 MBits/s ja eigentlich ein Witz, wie du schon festgestellt hattest.
Und das, obwohl der Server gestern wegen eines anderen Fehlers rebootet werden musste!!
Wie hoch ist denn rx_packets? Es kommt ja ein wenig auf das Verhältnis an.
Komischerweise gibt "ethtool -S eth0" diesen Wert mit dem aktuellen Treiber gar nicht aus. Beim Testserver bekomme ich den da schon ausgegeben.
Komisch. Ich habe eher von Problemen mit Firmware-Updates oder sowas bei dem aktuellen Treiber gelesen. Vielleicht ist es gar keine so schlechte Idee mal tatsächlich den Treiber vom Hersteller selbst zu kompilieren, auch wenn die Version erst einmal kleiner erscheint. Nur, den Treiber auf dem Produktivsystem zu ersetzen ist natürlich auch etwas mutig.
(...).
Also dass es ausgeschaltet ist/wird steht ja in deinem dmesg-Auszug. Ich würde erwarten, dass das dann auch wieder da auftauchen würden, wenn es wieder aktiviert wird. Aber wer weiß das schon ...
Ahhhh, ist das das "EEE"? (Energy-Efficient Ethernet) (...).
Ja.
Habe es mal disabled: # ethtool --set-eee eth0 eee off # ethtool --set-eee eth1 eee off ...mal sehen, ob es was bringt.
Im Readme vom Hersteller-Treiber steht noch: | This version of the tg3 driver supports one module parameter that is | not available in the in-kernel driver. The parameter is named | tg3_disable_eee. | To disable Energy Efficient Ethernet (EEE) support, set this module | parameter to 1.
(...).
Ansonsten, könnten denn die Switches Probleme machen? Denn die wurden ja nicht ersetzt, sondern nur der Server. Und die Probleme sind geblieben. Vielleicht sind liegt die Ursache außerhalb des Servers?
Switch wurde auch schon mal probeweise gegen eine andere Marke getauscht. Hat nichts gebracht, wurde wieder zurückgetauscht.
Okay.
Die beste Erfolgswahrscheinlichkeit sehe ich beim Nachforschen zu den hohen "rx_missed_errors"-Ständen. Nur leider habe ich im Zusammenhang mit "tg3" oder allgemein noch nicht das richtige dazu gefunden...
Leider. Ich habe auch schon Stunden gegoogelt und nichts wirklich erhellenderes gefunden.
Allgemeine Erklärung dazu: /sys/class/<iface>/statistics/rx_missed_errors: Indicates the number of received packets that have been missed due to lack of capacity in the receive side. See the network driver for the exact meaning of this value.
Warum der Server zu wenig "Kapazität" hatte ist dann natürlich die große Frage. Die Flow-Control würde ja nur eine kontrolliert langsame Datenübertragung gewährleisten. Bug-Report auf bugzilla.kernel.org? Oder ein Post auf der LKML? Da lesen wahrscheinlich die wirklichen Profis. Gruß Jan -- It's a real shame that Turing machines are so poor at I/O. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, On Sat, 31 Jan 2015, Jan Ritzerfeld wrote:
Am Sonntag, 25. Januar 2015, 23:57:18 schrieb Günther Zinsberger:
Die beste Erfolgswahrscheinlichkeit sehe ich beim Nachforschen zu den hohen "rx_missed_errors"-Ständen. Nur leider habe ich im Zusammenhang mit "tg3" oder allgemein noch nicht das richtige dazu gefunden...
Leider. Ich habe auch schon Stunden gegoogelt und nichts wirklich erhellenderes gefunden.
spricht etwas dagegen mal an einem Wochenende ein paar Meter Kabel um die bisherige Verkabelung herum zu legen? Damit lässt sich dann das Netzwerk (alte Kabel, schlechte Schirmung, gebrochene Leitung, falsche Verdrahtung, Störeinkopplung von extern,...) an sich als Fehlerquelle ausschließen. Dann kann man sich auch wieder voll auf die SW konzentrieren ;) Im einfachsten Fall ist das 1m Kabel vom aktuell unbenutzten Interface zu $Irgendwas. Wobei das Andere interessanter ist. Greetings Daniel -- Liest man die Grabinschriften, dann liegt unser Heil nur in der Wiederbelebung der Toten und Beerdigung der Lebenden. -- unknown -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Daniel Lord
-
Günther Zinsberger
-
Jan Ritzerfeld