Zum Inhalt springen

Txqueuelen: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →

Dirkwagner (Diskussion | Beiträge)

3 Benutzergruppen
150.038 Bearbeitungen
VisuellWikitext
K Textersetzung - „ TCP“ durch „ TCP“
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
'''txqueuelen''' - Transmit Queue Length
''txqueuelen'' –(Transmit Queue Length) Länge der Sendewarteschlange




== Beschreibung ==
== Beschreibung ==
How do I set txqueuelen (the length of the transmit queue) length of the network card device under Linux? How do I set it for a high latency and/or a high speed network for bulk transfer from disturbing interactive traffic like ssh too much?
Wie stelle ich unter Linux die Länge der Sendewarteschlange (txqueuelen) der Netzwerkkarte ein? Wie stelle ich sie für ein Netzwerk mit hoher Latenz und/oder hoher Geschwindigkeit ein, um Massenübertragungen vor störendem interaktivem Datenverkehr wie SSH zu schützen?


You can set the length of the transmit queue of the device using /sbin/ifconfig command as follows:
Sie können die Länge der Sendewarteschlange des Geräts mit dem Befehl /sbin/ifconfig wie folgt einstellen:
# Small value for slower devices with a high latency like modem links and ISDN.
# Kleiner Wert für langsamere Geräte mit hoher Latenz wie Modemverbindungen und ISDN.
# High value is recommend for server connected over the high-speed Internet connections that perform large data transfers.
# Ein hoher Wert wird für Server empfohlen, die über Hochgeschwindigkeits-Internetverbindungen verbunden sind und große Datenübertragungen durchführen.


== Increasing The txqueuelen ==
== Erhöhen der `txqueuelen` ==
Increase the txqueuelength parameter to a value between 1000 and 20000 per interface:
Erhöhen Sie den Parameter `txqueuelen` pro Schnittstelle auf einen Wert zwischen 1000 und 20000:
  ifconfig ${interface} txqueuelen ${size}
  ifconfig ${interface} txqueuelen ${size}
  ifconfig eth1 txqueuelen 10000
  ifconfig eth1 txqueuelen 10000
  ifconfig eth0 txqueuelen 5000
  ifconfig eth0 txqueuelen 5000


=== Setting the txqueuelen permanently ===
=== „txqueuelen“ dauerhaft festlegen ===
Edit /etc/rc.locale, enter:
Bearbeiten Sie die Datei /etc/rc.local und geben Sie Folgendes ein:


<code>vi /etc/rc.local</code>
<code>vi /etc/rc.local</code>


Append the following setting per interface:
Fügen Sie pro Schnittstelle die folgende Einstellung an:
  /sbin/ifconfig eth1 txqueuelen 10000
  /sbin/ifconfig eth1 txqueuelen 10000
  /sbin/ifconfig eth0 txqueuelen 10000
  /sbin/ifconfig eth0 txqueuelen 10000


Vivek Gite is an expert IT Consultant with over 25 years of experience, specializing in Linux and open source solutions. He writes about Linux, macOS, Unix, IT, programming, infosec, and open source. Follow his work via RSS feed.
Vivek Gite ist ein erfahrener IT-Berater mit über 25 Jahren Erfahrung, der sich auf Linux und Open-Source-Lösungen spezialisiert hat. Er schreibt über Linux, macOS, Unix, IT, Programmierung, Informationssicherheit und Open Source. Verfolgen Sie seine Arbeit über den RSS-Feed.


== Comments ==
== Kommentare ==
* Yevgen Oct 22, 2009 @ 9:56 You can use also this command: ip link set eth1 txqueuelen 10000 ↩ ∞
* Yevgen                           22. Okt. 2009 um 9:56 Uhr Du kannst auch diesen Befehl verwenden: ip link set eth1 txqueuelen 10000 ↩ ∞
* iwbcman Jan 10, 2011 @ 17:09 Thx for posting this howto for setting txqueuelen. It should be noted however that increasing the txqueuelen value is a sure fire way to oversaturate your network interface buffers which may cause excessive jitter and DNS resolve timeouts. The default Linux txqueuelen value of 1000 is already way to high, and reducing this value to some much smaller number will reduce the likelihood of your network interface buffers being oversaturated. Personally I have had good results setting the value to 200. Basically [[TCP]] must be able to have packets dropped quickly in order for the server to know that there is network congestion occurring. The size of the value determines how much buffering takes place(where # of packets translates to number of seconds of data being buffered). When this value is too high the feedback mechanism, which forms the basis for the network congestion avoidance algorithms in [[TCP]], fails, meaning instead of packets being dropped thereby signalling that there is congestion. When the server is unaware of congestion due to excessive buffering the inevitable retransmission of packets only occurs once the problem has gotten too severe- and thus gigantic latencies are introduced, latencies equivalent to the number of seconds buffered according to the value set in txqueuelen. So the smaller the txqueuelen value, the better are the chances that [[TCP]]’s congestion avoidance algorithms can do their job-hence resulting in higher transfer speeds, and the less likely that the buffers will be overfilled leading to gigantic timeouts when retransmission inevitably occurs. Google Jim Gettys and bufferbloat for a better explanation. ↩ ∞
* iwbcman                           10. Jan. 2011 um 17:09 Danke für die Veröffentlichung dieser Anleitung zur Einstellung von „txqueuelen“. Es sollte jedoch beachtet werden, dass eine Erhöhung des „txqueuelen“-Werts mit Sicherheit zu einer Übersättigung der Puffer Ihrer Netzwerkschnittstelle führt, was übermäßigen Jitter und Timeouts bei der DNS-Auflösung verursachen kann. Der Standardwert von 1000 für „txqueuelen“ unter Linux ist bereits viel zu hoch, und eine Reduzierung dieses Wertes auf einen deutlich kleineren Wert verringert die Wahrscheinlichkeit, dass die Puffer Ihrer Netzwerkschnittstelle überlastet werden. Ich persönlich habe mit dem Wert 200 gute Erfahrungen gemacht. Grundsätzlich muss [[TCP]] in der Lage sein, Pakete schnell zu verwerfen, damit der Server erkennt, dass eine Netzwerküberlastung vorliegt. Die Größe des Werts bestimmt, in welchem Umfang Pufferung stattfindet (wobei die Anzahl der Pakete der Anzahl der Sekunden entspricht, in denen Daten gepuffert werden). Ist dieser Wert zu hoch, versagt der Rückkopplungsmechanismus, der die Grundlage für die Algorithmen zur Vermeidung von Netzwerküberlastung in [[TCP]] bildet, was bedeutet, dass Pakete nicht verworfen werden und somit keine Überlastung signalisiert wird. Wenn der Server die Überlastung aufgrund übermäßiger Pufferung nicht erkennt, erfolgt die unvermeidliche erneute Übertragung von Paketen erst, wenn das Problem bereits zu gravierend geworden ist – wodurch enorme Latenzen entstehen, die der Anzahl der Sekunden entsprechen, die gemäß dem in `txqueuelen` festgelegten Wert gepuffert wurden. Je kleiner also der Wert von `txqueuelen` ist, desto besser sind die Chancen, dass die Algorithmen zur Vermeidung von Überlastung in [[TCP]] ihre Aufgabe erfüllen können – was zu höheren Übertragungsgeschwindigkeiten führt – und desto unwahrscheinlicher ist es, dass die Puffer überfüllt werden, was zu enormen Timeouts führt, wenn die erneute Übertragung unvermeidlich eintritt. Suchen Sie nach „Jim Gettys“ und „Bufferbloat“, um eine bessere Erklärung zu erhalten. ↩ ∞
* Maroon Jan 13, 2011 @ 14:01 Sir, As for the proxy servers (squid), what is recommended? to increase the tx queue length? or the oposite? Knowing that we are using server hardware… Please advise ↩ ∞
* Maroon                           13. Jan. 2011 um 14:01 Uhr Sehr geehrter Herr, was wird in Bezug auf die Proxy-Server (Squid) empfohlen? Soll die Länge der TX-Warteschlange erhöht werden? Oder das Gegenteil? In Anbetracht der Tatsache, dass wir Server-Hardware verwenden … Bitte um Rat ↩ ∞
** NANO Nov 28, 2012 @ 2:02 blow fish the length of word is hashed all the way to the name state itself … outside the algorithm the words are recognizable but the word like PHISH and FISH would be towards human decision. ↩ ∞
** NANO                           28. Nov. 2012 um 2:02 Uhr Blowfish: Die Länge des Wortes wird bis hin zum Status „name“ selbst gehasht … Außerhalb des Algorithmus sind die Wörter erkennbar, aber bei Wörtern wie „PHISH“ und „FISH“ wäre die Entscheidung beim Menschen. ↩ ∞
* Dave Täht Feb 13, 2011 @ 2:39 Smaller will make your [[TCP]] stack more responsive. [[TCP]] does plenty of buffering for you already. Unmanaged FIFO buffers greater than, say, 32, are bad. You can use bigger buffers, but you should then use a qdisc of some sort to balance your flows. I can’t imagine a valid reason for any level of FIFO buffering at present. Try also enabling ECN and SACK. The previous poster – while otherwise very correct – also missed using ethtool to reduce your dma tx queues. See also: <nowiki>http://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips</nowiki> ↩ ∞
* Dave Täht                           13. Februar 2011 um 2:39 Eine kleinere Länge macht Ihren [[TCP]]-Stack reaktionsschneller. [[TCP]] übernimmt bereits einen Großteil der Pufferung für Sie. Unverwaltete FIFO-Puffer, die größer sind als beispielsweise 32, sind schlecht. Sie können zwar größere Puffer verwenden, sollten dann aber eine Art qdisc einsetzen, um Ihre Datenströme auszugleichen. Ich kann mir derzeit keinen triftigen Grund für FIFO-Pufferung in irgendeinem Umfang vorstellen. Versuche auch, ECN und SACK zu aktivieren. Der vorherige Poster – der ansonsten zwar völlig Recht hatte – hat es versäumt, ethtool zu verwenden, um deine DMA-Sende-Warteschlangen zu verkleinern. Siehe auch: <nowiki>http://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips</nowiki> ↩ ∞
* MK2 Apr 21, 2011 @ 23:15 I find a slightly cleaner way to make this permanent is to vi /etc/network/interfaces and add the following line below the interface you want to change: up ifconfig $IFACE txqueuelen 10000 The up allows any following command to be executed when the interface is brought up. This way the line is in the same place as the rest of the interface configuration. ↩ ∞
* MK2                           21. April 2011 um 23:15 Uhr Ich finde, eine etwas sauberere Methode, dies dauerhaft zu machen, ist, die Datei /etc/network/interfaces mit vi zu öffnen und die folgende Zeile unterhalb der Schnittstelle hinzuzufügen, die du ändern möchtest: up ifconfig $IFACE txqueuelen 10000 Das „up“ sorgt dafür, dass jeder nachfolgende Befehl ausgeführt wird, wenn die Schnittstelle hochgefahren wird. Auf diese Weise befindet sich die Zeile an derselben Stelle wie der Rest der Schnittstellenkonfiguration. ↩                           ∞
* ddale Jul 21, 2011 @ 14:41 If I want to snmp poll TxQueueLen, what is the number that will be returned – number of packets in the queue? The number of bytes being used by the queue? ↩ ∞
* ddale                           21. Juli 2011 um 14:41 Wenn ich TxQueueLen per SNMP abfragen möchte, welcher Wert wird dann zurückgegeben – die Anzahl der Pakete in der Warteschlange? Oder die Anzahl der von der Warteschlange belegten Bytes? ↩                           ∞
* nima0102 Sep 17, 2011 @ 12:11 Hi Thanks for your good instruction May you give me more information about reasons of “PACKET DROP” ? If NIC gets one corrupted packet, is number increased? or system does not count corrupted packet at all? Thanks in advance ↩ ∞
* nima0102                           17. September 2011 um 12:11 Uhr Hallo, vielen Dank für Ihre gute Anleitung. Könnten Sie mir bitte weitere Informationen zu den Gründen für „PACKET DROP“ geben? Wenn die Netzwerkkarte ein beschädigtes Paket empfängt, erhöht sich dann der Wert? Oder zählt das System beschädigte Pakete gar nicht mit? Vielen Dank im Voraus ↩                           ∞
* Maciej Sep 19, 2011 @ 8:38 I second iwbcman’s comment. Read on the consequences of blindly setting txqueuelen to high values. ↩ ∞
* Maciej                           19. September 2011 um 8:38 Uhr Ich schließe mich dem Kommentar von iwbcman an. Informieren Sie sich über die Folgen einer blindlings vorgenommenen Einstellung von „txqueuelen“ auf hohe Werte. ↩                           ∞
* Agostino Sep 20, 2011 @ 16:38 Not sure, remember that the device is always handled by a CPU. It is useful to set the txqueuelen to small values for slower devices with a high latency (modem links, ISDN) to prevent fast bulk transfers from disturbing interactive traffic. Therefore careful tuning is required to ensure that the sizes of the queues are optimal for your network connection. The default of 100 is inadequate for long distance, high throughput pipes. Also you have to consider the receiver side, we have a similar queue for incoming packets. This queue will build up in size when an interface receives packets faster than the kernel can process them. If this queue is too small (default is 1000), we will begin to loose packets at the receiver, rather than on the network. I have doing more and more testing and personally i have more better performance and lowest cpu load on stress server quad core and giga ethernet at about 4650mi distance from me with this 2 setting: ifconfig eth0 txqueuelen 2000 echo 2000 > /proc/sys/net/core/netdev_max_backlog Bye. ↩ ∞
* Agostino 20. September 2011 um 16:38 Uhr Ich bin mir nicht sicher, aber denken Sie daran, dass das Gerät immer von einer CPU gesteuert wird. Bei langsameren Geräten mit hoher Latenz (Modemverbindungen, ISDN) ist es sinnvoll, `txqueuelen` auf kleine Werte zu setzen, um zu verhindern, dass schnelle Massenübertragungen den interaktiven Datenverkehr stören. Daher ist eine sorgfältige Feinabstimmung erforderlich, um sicherzustellen, dass die Größe der Warteschlangen für Ihre Netzwerkverbindung optimal ist. Der Standardwert von 100 ist für Fernverbindungen mit hohem Durchsatz unzureichend. Außerdem muss die Empfängerseite berücksichtigt werden; wir haben eine ähnliche Warteschlange für eingehende Pakete. Diese Warteschlange wächst an, wenn eine Schnittstelle Pakete schneller empfängt, als der Kernel sie verarbeiten kann. Ist diese Warteschlange zu klein (Standardwert ist 1000), gehen Pakete eher auf der Empfängerseite als im Netzwerk verloren. Ich habe immer mehr Tests durchgeführt und persönlich erziele ich auf einem Stress-Server mit Quad-Core-Prozessor und Gigabit-Ethernet in einer Entfernung von etwa 4650 Meilen von mir die bessere Leistung und die geringste CPU-Auslastung mit diesen beiden Einstellungen: `ifconfig eth0 txqueuelen 2000` und `echo 2000 > /proc/sys/net/core/netdev_max_backlog`. Tschüss. ↩ ∞
* vv Apr 2, 2012 @ 22:40 when i try ifconfig ${interface} txqueuelen ${size} ifconfig eth1 txqueuelen 10000 ifconfig eth0 txqueuelen 5000 i get this: SIOCSIFTXQLEN: No such device My question if i add lines /sbin/ifconfig eth1 txqueuelen 10000 /sbin/ifconfig eth0 txqueuelen 10000 in rc.local its enoguht for increase it? ↩ ∞
* vv                           2. April 2012 um 22:40 Uhr Wenn ich versuche, `ifconfig ${interface} txqueuelen ${size}`, `ifconfig eth1 txqueuelen 10000` und `ifconfig eth0 txqueuelen 5000` auszuführen, erhalte ich folgende Meldung: SIOCSIFTXQLEN: Kein solches Gerät Meine Frage: Reicht es aus, die Zeilen /sbin/ifconfig eth1 txqueuelen 10000 /sbin/ifconfig eth0 txqueuelen 10000 in rc.local einzufügen, um den Wert zu erhöhen? ↩                           ∞
* Rajesh Chaudhary Mar 18, 2015 @ 9:16 This way you can only change the txqueuelen temporarily , /etc/rc.local runs at boot time, but when you restart your interface it will again set the txqueuelen value to default. here is the permanent way of fixing it. in below example i am setting txqueuelen to 5000 permanently. This value will remain same even after reboot of server or just interface restart/reset. edit /etc/sysconfig/network-script/ifup and place your command ” ifconfig eth2 txqueuelen 5000″ in beginning of the file ,just above line “unset WINDOW # defined by screen, conflicts with our usage” ↩ ∞
* Rajesh Chaudhary 18. März 2015 um 9:16 Uhr Auf diese Weise können Sie den Wert von `txqueuelen` nur vorübergehend ändern. `/etc/rc.local` wird beim Systemstart ausgeführt, aber wenn Sie Ihre Schnittstelle neu starten, wird der Wert von `txqueuelen` wieder auf den Standardwert zurückgesetzt. Hier ist die dauerhafte Lösung für das Problem. Im folgenden Beispiel setze ich `txqueuelen` dauerhaft auf 5000. Dieser Wert bleibt auch nach einem Neustart des Servers oder einem Neustart/Reset der Schnittstelle unverändert. Bearbeiten Sie die Datei `/etc/sysconfig/network-script/ifup` und fügen Sie Ihren Befehl „ifconfig eth2 txqueuelen 5000“ am Anfang der Datei ein, direkt über der Zeile „unset WINDOW # defined by screen, conflicts with our usage“ ↩                           ∞
* Diego Oct 10, 2016 @ 15:37 # cat <> /etc/rules.d/71-net-txqueuelen.rules SUBSYSTEM==”net”, ACTION==”add”, KERNEL==”eth*”, ATTR{tx_queue_len}=”10000″ EOF
* Diego                           10. Okt. 2016 um 15:37 Uhr # cat <> /etc/rules.d/71-net-txqueuelen.rules SUBSYSTEM==”net”, ACTION==”add”, KERNEL==”eth*”, ATTR{tx_queue_len}=”10000″ EOF

Version vom 11. Juli 2026, 08:47 Uhr

txqueuelen –(Transmit Queue Length) Länge der Sendewarteschlange


Beschreibung

Wie stelle ich unter Linux die Länge der Sendewarteschlange (txqueuelen) der Netzwerkkarte ein? Wie stelle ich sie für ein Netzwerk mit hoher Latenz und/oder hoher Geschwindigkeit ein, um Massenübertragungen vor störendem interaktivem Datenverkehr wie SSH zu schützen?

Sie können die Länge der Sendewarteschlange des Geräts mit dem Befehl /sbin/ifconfig wie folgt einstellen:

  1. Kleiner Wert für langsamere Geräte mit hoher Latenz wie Modemverbindungen und ISDN.
  2. Ein hoher Wert wird für Server empfohlen, die über Hochgeschwindigkeits-Internetverbindungen verbunden sind und große Datenübertragungen durchführen.

Erhöhen der `txqueuelen`

Erhöhen Sie den Parameter `txqueuelen` pro Schnittstelle auf einen Wert zwischen 1000 und 20000: 

ifconfig ${interface} txqueuelen ${size}
ifconfig eth1 txqueuelen 10000
ifconfig eth0 txqueuelen 5000

„txqueuelen“ dauerhaft festlegen

Bearbeiten Sie die Datei /etc/rc.local und geben Sie Folgendes ein:

vi /etc/rc.local

Fügen Sie pro Schnittstelle die folgende Einstellung an: 

/sbin/ifconfig eth1 txqueuelen 10000
/sbin/ifconfig eth0 txqueuelen 10000

Vivek Gite ist ein erfahrener IT-Berater mit über 25 Jahren Erfahrung, der sich auf Linux und Open-Source-Lösungen spezialisiert hat. Er schreibt über Linux, macOS, Unix, IT, Programmierung, Informationssicherheit und Open Source. Verfolgen Sie seine Arbeit über den RSS-Feed.

Kommentare

  • Yevgen 22. Okt. 2009 um 9:56 Uhr Du kannst auch diesen Befehl verwenden: ip link set eth1 txqueuelen 10000 ↩ ∞
  • iwbcman 10. Jan. 2011 um 17:09 Danke für die Veröffentlichung dieser Anleitung zur Einstellung von „txqueuelen“. Es sollte jedoch beachtet werden, dass eine Erhöhung des „txqueuelen“-Werts mit Sicherheit zu einer Übersättigung der Puffer Ihrer Netzwerkschnittstelle führt, was übermäßigen Jitter und Timeouts bei der DNS-Auflösung verursachen kann. Der Standardwert von 1000 für „txqueuelen“ unter Linux ist bereits viel zu hoch, und eine Reduzierung dieses Wertes auf einen deutlich kleineren Wert verringert die Wahrscheinlichkeit, dass die Puffer Ihrer Netzwerkschnittstelle überlastet werden. Ich persönlich habe mit dem Wert 200 gute Erfahrungen gemacht. Grundsätzlich muss TCP in der Lage sein, Pakete schnell zu verwerfen, damit der Server erkennt, dass eine Netzwerküberlastung vorliegt. Die Größe des Werts bestimmt, in welchem Umfang Pufferung stattfindet (wobei die Anzahl der Pakete der Anzahl der Sekunden entspricht, in denen Daten gepuffert werden). Ist dieser Wert zu hoch, versagt der Rückkopplungsmechanismus, der die Grundlage für die Algorithmen zur Vermeidung von Netzwerküberlastung in TCP bildet, was bedeutet, dass Pakete nicht verworfen werden und somit keine Überlastung signalisiert wird. Wenn der Server die Überlastung aufgrund übermäßiger Pufferung nicht erkennt, erfolgt die unvermeidliche erneute Übertragung von Paketen erst, wenn das Problem bereits zu gravierend geworden ist – wodurch enorme Latenzen entstehen, die der Anzahl der Sekunden entsprechen, die gemäß dem in `txqueuelen` festgelegten Wert gepuffert wurden. Je kleiner also der Wert von `txqueuelen` ist, desto besser sind die Chancen, dass die Algorithmen zur Vermeidung von Überlastung in TCP ihre Aufgabe erfüllen können – was zu höheren Übertragungsgeschwindigkeiten führt – und desto unwahrscheinlicher ist es, dass die Puffer überfüllt werden, was zu enormen Timeouts führt, wenn die erneute Übertragung unvermeidlich eintritt. Suchen Sie nach „Jim Gettys“ und „Bufferbloat“, um eine bessere Erklärung zu erhalten. ↩ ∞
  • Maroon 13. Jan. 2011 um 14:01 Uhr Sehr geehrter Herr, was wird in Bezug auf die Proxy-Server (Squid) empfohlen? Soll die Länge der TX-Warteschlange erhöht werden? Oder das Gegenteil? In Anbetracht der Tatsache, dass wir Server-Hardware verwenden … Bitte um Rat ↩ ∞
    • NANO 28. Nov. 2012 um 2:02 Uhr Blowfish: Die Länge des Wortes wird bis hin zum Status „name“ selbst gehasht … Außerhalb des Algorithmus sind die Wörter erkennbar, aber bei Wörtern wie „PHISH“ und „FISH“ wäre die Entscheidung beim Menschen. ↩ ∞
  • Dave Täht 13. Februar 2011 um 2:39 Eine kleinere Länge macht Ihren TCP-Stack reaktionsschneller. TCP übernimmt bereits einen Großteil der Pufferung für Sie. Unverwaltete FIFO-Puffer, die größer sind als beispielsweise 32, sind schlecht. Sie können zwar größere Puffer verwenden, sollten dann aber eine Art qdisc einsetzen, um Ihre Datenströme auszugleichen. Ich kann mir derzeit keinen triftigen Grund für FIFO-Pufferung in irgendeinem Umfang vorstellen. Versuche auch, ECN und SACK zu aktivieren. Der vorherige Poster – der ansonsten zwar völlig Recht hatte – hat es versäumt, ethtool zu verwenden, um deine DMA-Sende-Warteschlangen zu verkleinern. Siehe auch: http://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips ↩ ∞
  • MK2 21. April 2011 um 23:15 Uhr Ich finde, eine etwas sauberere Methode, dies dauerhaft zu machen, ist, die Datei /etc/network/interfaces mit vi zu öffnen und die folgende Zeile unterhalb der Schnittstelle hinzuzufügen, die du ändern möchtest: up ifconfig $IFACE txqueuelen 10000 Das „up“ sorgt dafür, dass jeder nachfolgende Befehl ausgeführt wird, wenn die Schnittstelle hochgefahren wird. Auf diese Weise befindet sich die Zeile an derselben Stelle wie der Rest der Schnittstellenkonfiguration. ↩ ∞
  • ddale 21. Juli 2011 um 14:41 Wenn ich TxQueueLen per SNMP abfragen möchte, welcher Wert wird dann zurückgegeben – die Anzahl der Pakete in der Warteschlange? Oder die Anzahl der von der Warteschlange belegten Bytes? ↩ ∞
  • nima0102 17. September 2011 um 12:11 Uhr Hallo, vielen Dank für Ihre gute Anleitung. Könnten Sie mir bitte weitere Informationen zu den Gründen für „PACKET DROP“ geben? Wenn die Netzwerkkarte ein beschädigtes Paket empfängt, erhöht sich dann der Wert? Oder zählt das System beschädigte Pakete gar nicht mit? Vielen Dank im Voraus ↩ ∞
  • Maciej 19. September 2011 um 8:38 Uhr Ich schließe mich dem Kommentar von iwbcman an. Informieren Sie sich über die Folgen einer blindlings vorgenommenen Einstellung von „txqueuelen“ auf hohe Werte. ↩ ∞
  • Agostino 20. September 2011 um 16:38 Uhr Ich bin mir nicht sicher, aber denken Sie daran, dass das Gerät immer von einer CPU gesteuert wird. Bei langsameren Geräten mit hoher Latenz (Modemverbindungen, ISDN) ist es sinnvoll, `txqueuelen` auf kleine Werte zu setzen, um zu verhindern, dass schnelle Massenübertragungen den interaktiven Datenverkehr stören. Daher ist eine sorgfältige Feinabstimmung erforderlich, um sicherzustellen, dass die Größe der Warteschlangen für Ihre Netzwerkverbindung optimal ist. Der Standardwert von 100 ist für Fernverbindungen mit hohem Durchsatz unzureichend. Außerdem muss die Empfängerseite berücksichtigt werden; wir haben eine ähnliche Warteschlange für eingehende Pakete. Diese Warteschlange wächst an, wenn eine Schnittstelle Pakete schneller empfängt, als der Kernel sie verarbeiten kann. Ist diese Warteschlange zu klein (Standardwert ist 1000), gehen Pakete eher auf der Empfängerseite als im Netzwerk verloren. Ich habe immer mehr Tests durchgeführt und persönlich erziele ich auf einem Stress-Server mit Quad-Core-Prozessor und Gigabit-Ethernet in einer Entfernung von etwa 4650 Meilen von mir die bessere Leistung und die geringste CPU-Auslastung mit diesen beiden Einstellungen: `ifconfig eth0 txqueuelen 2000` und `echo 2000 > /proc/sys/net/core/netdev_max_backlog`. Tschüss. ↩ ∞
  • vv 2. April 2012 um 22:40 Uhr Wenn ich versuche, `ifconfig ${interface} txqueuelen ${size}`, `ifconfig eth1 txqueuelen 10000` und `ifconfig eth0 txqueuelen 5000` auszuführen, erhalte ich folgende Meldung: SIOCSIFTXQLEN: Kein solches Gerät Meine Frage: Reicht es aus, die Zeilen /sbin/ifconfig eth1 txqueuelen 10000 /sbin/ifconfig eth0 txqueuelen 10000 in rc.local einzufügen, um den Wert zu erhöhen? ↩ ∞
  • Rajesh Chaudhary 18. März 2015 um 9:16 Uhr Auf diese Weise können Sie den Wert von `txqueuelen` nur vorübergehend ändern. `/etc/rc.local` wird beim Systemstart ausgeführt, aber wenn Sie Ihre Schnittstelle neu starten, wird der Wert von `txqueuelen` wieder auf den Standardwert zurückgesetzt. Hier ist die dauerhafte Lösung für das Problem. Im folgenden Beispiel setze ich `txqueuelen` dauerhaft auf 5000. Dieser Wert bleibt auch nach einem Neustart des Servers oder einem Neustart/Reset der Schnittstelle unverändert. Bearbeiten Sie die Datei `/etc/sysconfig/network-script/ifup` und fügen Sie Ihren Befehl „ifconfig eth2 txqueuelen 5000“ am Anfang der Datei ein, direkt über der Zeile „unset WINDOW # defined by screen, conflicts with our usage“ ↩ ∞
  • Diego 10. Okt. 2016 um 15:37 Uhr # cat <> /etc/rules.d/71-net-txqueuelen.rules SUBSYSTEM==”net”, ACTION==”add”, KERNEL==”eth*”, ATTR{tx_queue_len}=”10000″ EOF
Abgerufen von „https://wiki.foxtom.de/index.php?title=Txqueuelen&oldid=171388“