Article ID: 118693, created on Feb 6, 2014, last review on May 8, 2014

  • Applies to:
  • Operations Automation
  • Panels
  • Virtuozzo
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor

Frage

Folgende Meldungen erscheinen in /var/log/messages auf dem Hardware Node:

[2814258.430156] TCP: time wait bucket table overflow (CT101) 
[2814258.449661] TCP: time wait bucket table overflow (CT101) 
[2814258.450743] TCP: time wait bucket table overflow (CT101) 
[2814258.475297] TCP: time wait bucket table overflow (CT101)

Was bedeutet das und wie löse ich es?

Antwort

Diese Meldungen bedeuten, dass die TW-Buckets (TCP-Sockets im Status TIME_WAIT) ihr Limit für den Kernel-Speicher erreicht haben.

Die Menge an aktuellen TIME_WAIT-Verbindungen (tw_count) kann mit dem Dienstprogramm netstat herausgefunden werden:

[root@vz ~]# netstat -antp | grep TIME_WAIT
tcp        0      0 127.0.0.1:8080              127.0.0.1:35550             TIME_WAIT   -
tcp        0      0 127.0.0.1:8080              127.0.0.1:35562             TIME_WAIT   -
tcp        0      0 127.0.0.1:8080              127.0.0.1:35568             TIME_WAIT   -
tcp        0      0 ::ffff:127.0.0.1:37849      ::ffff:127.0.0.1:25         TIME_WAIT   -

[root@vz ~]# netstat -antp | grep TIME_WAIT | wc -l
4

Das Problem kann in einem der folgenden Fälle auftreten:

1) Der pro System geltende tw_count ist größer als die pro System geltende Grenze max_tw_buckets:

    [root@vz ~]# sysctl -a | grep tcp_max_tw_buckets
    net.ipv4.tcp_max_tw_buckets = 262144

Die Grenze ist recht hoch, daher ist es sehr unwahrscheinlich, dass sie erreicht wird. Dennoch kann die Sysctl-Variable, wenn nötig, erhöht werden.

2) Der pro virtuelle Umgebung (VE) geltende Zähler ist größer als die pro VE geltende Grenze max_tw_buckets:

    [root@vz ~]# sysctl -a | grep tcp_max_tw_buckets_ub
    net.ipv4.tcp_max_tw_buckets_ub = 16536

Erhöhen Sie die Sysctl-Variable, um das Problem zu lösen.

3) In der VE beansprucht tw_buckets zu viel Arbeitsspeicher (mehr als der zulässige Teil von kmemsize)

    [root@vz ~]# vzctl exec 101 sysctl -a 2>/dev/null| grep net.ipv4.tcp_max_tw_kmem_fraction
    net.ipv4.tcp_max_tw_kmem_fraction = 384

384 bedeutet 38,4% der kmemsize

In diesem Fall werden keine fehlgeschlagenen Zähler für den Container registriert, daher ist es schwer dies aufzuspüren. Versuchen Sie, den Parameter kmemsize für den Container zu erhöhen und sehen Sie nach, ob die Nachrichten verschwunden sind.

4) Zu wenig kmemsize in der VE - in diesem Fall sollten neue Ausfallzähler für den Parameter kmemsize verzeichnet sein. Finden Sie heraus, ob das zutrifft:

    [root@vz ~]# awk '$6' /proc/bc/101/resources
                kmemsize                 16587096             18132992             24299200             26429120                    126

Die letzte Spalte zeigt an, wie oft der Parameter überschritten wurde. Falls die Grenze erreicht wird, müssen Sie den Parameter kmemsize für den Container erhöhen.

a26b38f94253cdfbf1028d72cf3a498b 2897d76d56d2010f4e3a28f864d69223 d02f9caf3e11b191a38179103495106f e8e50b42231236b82df27684e7ec0beb 5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 0dd5b9380c7d4884d77587f3eb0fa8ef 614fd0b754f34d5efe9627f2057b8642 56797cefb1efc9130f7c48a7d1db0f0c

Email subscription for changes to this article
Save as PDF