OpenVZ Forum


Home » International » Russian » Зависание системы (сети?) в ядрах старше 64.8 на CentOS (unregister_netdevice: device xxxxx marked to leak и TCP: time wait bucket table overflow (CTXXXX))
icon9.gif  Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #38566] Sun, 03 January 2010 16:09 Go to next message
AnVir is currently offline  AnVir
Messages: 20
Registered: October 2009
Location: Russia
Junior Member

From: *uln.ru
Здравствуйте, уважаемые.
Проблема такова: на последних ядрах в произвольный момент выскакивают в сислог такие сообщения:

Jan  3 06:48:56 vdsm5 kernel: unregister_netdevice: waiting for lo=d59ef000 to become free. Usage count = 6 ve=6899
Jan  3 06:49:36 vdsm5 last message repeated 4 times
Jan  3 06:49:36 vdsm5 kernel: unregister_netdevice: device d59ef000 marked to leak
Jan  3 06:49:36 vdsm5 kernel: free_netdev: device lo=d59ef000 leaked
Jan  3 06:49:36 vdsm5 kernel: neighbour leakage
Jan  3 07:16:28 vdsm5 kernel: Route hash chain too long!
Jan  3 07:16:28 vdsm5 kernel: Adjust your secret_interval!
Jan  3 07:30:28 vdsm5 kernel: Fatal resource shortage: kmemsize, UB 28684.
Jan  3 08:01:01 vdsm5 kernel: Fatal resource shortage: kmemsize, UB 28684.
Jan  3 08:10:08 vdsm5 kernel: Fatal resource shortage: kmemsize, UB 28684.
Jan  3 08:10:09 vdsm5 kernel: Fatal resource shortage: kmemsize, UB 28684.
Jan  3 08:11:55 vdsm5 kernel: TCP: time wait bucket table overflow (CT28684)
Jan  3 08:45:29 vdsm5 kernel: TCP: time wait bucket table overflow (CT28684)
Jan  3 11:37:13 vdsm5 kernel: TCP: time wait bucket table overflow (CT28684)


Причем, первые - всегда, а касаемые определенного CTID - не всегда. Могут выскакивать 3-4 раза, а иногда - только один раз. После чего система либо виснет, либо отрубается сеть - точно сказать не могу, просто пинги не идут до удаленного сервера. Появляется через несколько часов аптайма (от 1 до 10). Контейнеров на ноде - около 50, все мелкие, нода - интел quad 4x2.6, два sata диска по 500 гб, 8 гб мозга, CentOS 5.4.
Пробовал ядра PAE и Enterprize - пофигу, виснет и всё. Лечится только откатом ядра до 2.6.18-128.2.1.el5.028stab064.8. Хз, что там они сделали, но суда по google - проблема не только у меня. Заметил, что несколько пролонгирует время работы такая примочка:
sysctl net.ipv4.tcp_mem="786432 1048576 1572864" - но опять же не сильно.
Собственно, вопрос: кто сталкивался, как лечили и вообще есть ли лекарство? Ну очень динамит - т.к. в новом ядре есть фичи, которые хотелось бы иметь, а тут такая засада...
Для статистики: таких идентичных серверов у меня пять, проблема есть на ВСЕХ. Могу кинуть dmesg для более точного описания оборудования - но, опять же судя по гуглю, дело не в железе а в CentOS+ovzkernel, да и на еще одном сервере где такой же софт но нет OVZ - все работает нормально.
Помогите Sad


Welcome to xfes.ru OpenVZ repository mirror
Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #38567 is a reply to message #38566] Sun, 03 January 2010 18:32 Go to previous messageGo to next message
AnVir is currently offline  AnVir
Messages: 20
Registered: October 2009
Location: Russia
Junior Member

From: *uln.ru
Очередное сообщение из сислога, перед зависанием:
vdsm5 kernel: unregister_netdevice: waiting for lo=c2e8e000 to become free. Usage count = 4 ve=7043Jan 3 21:30:16 vdsm5 kernel: unregister_netdevice: waiting for lo=c2e8e000 to become free. Usage count = 4 ve=7043
Подскажите хоть, куда копать Sad


Welcome to xfes.ru OpenVZ repository mirror
Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #38575 is a reply to message #38567] Mon, 04 January 2010 12:09 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *pppoe.mtu-net.ru
Попробуйте поиграть параметрами net.ipv4.tcp_tw_recycle и net.ipv4.tcp_tw_reuse.
Посмотрите еще net.ipv4.tcp_max_tw_buckets.

netstat -tan|perl -nae 'm/(TIME_WAIT|FIN_WAIT)/ && do { $a{$F[3]}++; }; END { print "Local:\n"; for $k (keys %a) { print "$k = $a{$k}\n"; } }'


С помощью этого однострочника можно посмотреть, какой сервис создает много закрытых сокетов.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Mon, 04 January 2010 12:19]

Report message to a moderator

Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #38965 is a reply to message #38567] Wed, 24 February 2010 20:24 Go to previous messageGo to next message
alevchuk is currently offline  alevchuk
Messages: 22
Registered: February 2007
Location: University of California,...
Junior Member
From: *ucr.edu
http://forum.openvz.org/index.php?t=msg&th=7589
Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #38971 is a reply to message #38566] Thu, 25 February 2010 08:17 Go to previous messageGo to next message
AnVir is currently offline  AnVir
Messages: 20
Registered: October 2009
Location: Russia
Junior Member

From: *uln.ru
В ядре 028stab067.4 проблему исправили, работает нормально.
В 028stab068.3 снова появилось. Как-то уж очень регулярно...


Welcome to xfes.ru OpenVZ repository mirror
Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #39061 is a reply to message #38566] Thu, 11 March 2010 11:25 Go to previous messageGo to next message
pentarh is currently offline  pentarh
Messages: 13
Registered: October 2008
Location: Russia
Junior Member
From: 208.88.227*
Та же херня Sad
Проблемы начинаются, когда аптайм от 1 до 10 дней... dmesg начинает пестрить сообщениями:

Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=77.235.108.58
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=77.235.108.58
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=77.235.108.58
Dropped packet, source wrong veid=500 src-IP=78.140.x.x dst-IP=89.111.189.148
Dropped packet, source wrong veid=500 src-IP=78.140.x.x dst-IP=89.111.189.148
Dropped packet, source wrong veid=500 src-IP=78.140.x.x dst-IP=89.111.189.148
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=95.105.35.57
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=95.105.35.57
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=95.105.35.57
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.163.102.251
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.163.102.251
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.163.102.251
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=93.81.52.167
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=93.81.52.167
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=93.81.52.167
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=95.182.32.22
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=95.182.32.22
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=95.182.32.22
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=109.169.169.123
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=109.169.169.123
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=109.169.169.123
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.112.194.117
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.112.194.117
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.112.194.117
Dropped packet, source wrong veid=500 src-IP=78.140.x.x dst-IP=65.217.158.132
Dropped packet, source wrong veid=500 src-IP=78.140.x.x dst-IP=65.217.158.132
Dropped packet, source wrong veid=500 src-IP=78.140.x.x dst-IP=65.217.158.132
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=195.68.160.238
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=195.68.160.238
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=195.68.160.238
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=92.54.109.187
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=92.54.109.187
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=92.54.109.187
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.112.71.189
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.112.71.189
Dropped packet, source wrong veid=139 src-IP=78.140.x.x dst-IP=188.112.71.189


как видно, там присутствуют два "проблемных" контейнера. В обоих контейнерах начинаются проблемы с сетью. Эти два контейнера отличаются тем, что в обоих функционирует ТОЛЬКО openvpn (tun/tap) и функционирует довольно нагруженно.

Далее это распространяется на всю ноду. В статистике ifconfig появляются dropped пакеты:
eth0      Link encap:Ethernet  HWaddr 00:24:E8:40:B4:26  
          inet addr:195.225.x.x  Bcast:195.225.x.x  Mask:255.255.255.0
          inet6 addr: fe80::224:e8ff:fe40:b426/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:172611303 errors:0 >>>>> dropped:47434 <<<<<< overruns:0 frame:0
          TX packets:194043419 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:73706439813 (68.6 GiB)  TX bytes:150409625960 (140.0 GiB)
          Interrupt:98 Memory:da000000-da012800


Далее начинаются проблемы с сетью уже на самой ноде, SSH работает на ручнике. Dmesg пестрит такими финтами:

unregister_netdevice: waiting for venet0=ffff81043dbc9000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for venet0=ffff81043dbc9000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for venet0=ffff81043dbc9000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for venet0=ffff81043dbc9000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for venet0=ffff81043dbc9000 to become free. Usage count = 4 ve=134
unregister_netdevice: device ffff81043dbc9000 marked to leak
free_netdev: device venet0=ffff81043dbc9000 leaked
unregister_netdevice: waiting for lo=ffff8108315e0000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for lo=ffff8108315e0000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for lo=ffff8108315e0000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for lo=ffff8108315e0000 to become free. Usage count = 4 ve=134
unregister_netdevice: waiting for lo=ffff8108315e0000 to become free. Usage count = 4 ve=134
unregister_netdevice: device ffff8108315e0000 marked to leak
free_netdev: device lo=ffff8108315e0000 leaked
neighbour leakage


При попытке остановить любой контейнер, он останавливается минуты две, плюясь сообщениями:
for i in `vzlist | grep -v HOSTNAME | grep -v ServiceCT | awk '{print $1;}'`; do  vzctl stop $i; done


Stopping Container ...

Message from syslogd@ at Thu Mar 11 11:40:00 2010 ...
v-2-do12-d1338-10 kernel: unregister_netdevice: waiting for venet0=ffff8103d6b69800 to become free. Usage count = 3 ve=114
Message from syslogd@ at Thu Mar 11 11:40:40 2010 ...
v-2-do12-d1338-10 last message repeated 4 times
Message from syslogd@ at Thu Mar 11 11:40:40 2010 ...
v-2-do12-d1338-10 kernel: unregister_netdevice: device ffff8103d6b69800 marked to leak
Message from syslogd@ at Thu Mar 11 11:40:40 2010 ...
v-2-do12-d1338-10 kernel: free_netdev: device venet0=ffff8103d6b69800 leakedContainer was stopped
Container is unmounted


Останавливать контейнеры командой "service vz stop" прямое самоубийство, равно как делать софт-ребут. Т.к. эта команда дает стоп одновременно на все контейнеры. А это приводит к полному зависанию системы минут на 40. Если посчастливится попасть на ssh, то видно в топе 0% cpu idle, весь проц жрет system и процессы vzctl и vzquota.

Ядро 2.6.18-028stab068.3 x86_64 (последнее на момент поста)
ПО: лицензированное Parallels Virtuozzo Containers. 25 контейнеров на ноде. Технари воротят носом.

Так же, эта фигня проявляется на ноде с OpenVZ 2.6.18-164.10.1.el5.028stab067.4 x86_64, но не так жостко.

Че мля делать?! За что деньги то плачу...

[Updated on: Thu, 11 March 2010 11:42]

Report message to a moderator

Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #39062 is a reply to message #39061] Thu, 11 March 2010 12:50 Go to previous messageGo to next message
pentarh is currently offline  pentarh
Messages: 13
Registered: October 2008
Location: Russia
Junior Member
From: *goinwest.ru
Засабмитил баг
http://bugzilla.openvz.org/show_bug.cgi?id=1451
Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #39066 is a reply to message #39061] Fri, 12 March 2010 07:49 Go to previous messageGo to next message
AnVir is currently offline  AnVir
Messages: 20
Registered: October 2009
Location: Russia
Junior Member

From: *uln.ru
Откатить ядро на 2.6.18-164.10.1.el5.028stab067.4ent - в моём случае помогло. Вообще, как я заметил, проблема остаётся в ядрах с нечетным номером на конце (в вашем случае 3), и убирается в ядрах с четным номером (в моём случае 4). Может это случайно, но последние 4-5 ядер этому правилу следуют Smile
Предыдущее ядро, где этого вообще не было - 64.8. Можно и его попробовать, раз 67.4 тоже сбоит.


Welcome to xfes.ru OpenVZ repository mirror

[Updated on: Fri, 12 March 2010 07:50]

Report message to a moderator

Re: Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #39141 is a reply to message #38566] Thu, 18 March 2010 13:22 Go to previous message
pentarh is currently offline  pentarh
Messages: 13
Registered: October 2008
Location: Russia
Junior Member
From: *goinwest.ru
Короче смотрите в lspci че за сетевуха стоит. Ядро ovz не при чем, говорят мы имеем дело с неразрешенным багом в драйвере bnx2

http://kbase.redhat.com/faq/docs/DOC-26837
Previous Topic: hostname внутри VPS
Next Topic: Проблемы со Snort
Goto Forum:
  


Current Time: Fri Jul 19 10:23:59 GMT 2019