Article ID: 118693, created on Jan 24, 2014, last review on May 11, 2014

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

Question

Les messages suivants s'affichent dans /var/log/messages sur le 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)

Quelle est leur signification et comment les supprimer ?

Réponse

Ces messages signifient que les catégories TW (sockets TCP dans le statut TIME_WAIT) atteignent leur limite pour la mémoire du noyau.

Vous pouvez trouver le nombre de connexions TIME_WAIT (tw_count) à l'aide de l'utilitaire netstat :

[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

Ce problème peut se produire dans l'un de ces cas :

1) Le tw_count par système est supérieur à la limite max_tw_buckets par système :

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

La limite est relativement élevée, il est donc peu probable de l'atteindre. Il est toujours possible d'augmenter sysctl le cas échéant.

2) Le nombre par VE est supérieur à la limite par VE max_tw_buckets :

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

Augmentez le sysctl pour résoudre le problème.

3) Dans un VE, tw_buckets consomme trop de mémoire (plus que la fraction de kmemsize autorisée).

    [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 signifie 38,4 % de kmemsize

Dans ce cas, aucun compteur d'échec ne sera enregistré pour le conteneur. Par conséquent, il sera difficile de retracer le problème. Essayez d'augmenter le paramètre kmemsize pour le conteneur et de voir si les messages disparaissent.

4) kmemsize insuffisante dans le VE : dans ce cas, de nouveaux compteurs d'échecs devraient être enregistrés pour le paramètre kmemsize. Vérifiez ceci :

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

La dernière colonne indique le nombre de fois que le paramètre a été dépassé. Si la limite est atteinte, augmentez le paramètre kmemsize pour le conteneur.

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

Email subscription for changes to this article
Save as PDF