Home » International » Russian » Зависание системы (сети?) в ядрах старше 64.8 на CentOS (unregister_netdevice: device xxxxx marked to leak и TCP: time wait bucket table overflow (CTXXXX))
 Зависание системы (сети?) в ядрах старше 64.8 на CentOS [message #38566] |
Sun, 03 January 2010 16:09  |
|
|
Здравствуйте, уважаемые.
Проблема такова: на последних ядрах в произвольный момент выскакивают в сислог такие сообщения:
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 - все работает нормально.
Помогите 
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  |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Попробуйте поиграть параметрами 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 #39061 is a reply to message #38566] |
Thu, 11 March 2010 11:25 |
pentarh
Messages: 13
Registered: October 2008
Location: Russia
|
Junior Member |
|
|
Та же херня
Проблемы начинаются, когда аптайм от 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 #39066 is a reply to message #39061] |
Fri, 12 March 2010 07:49 |
|
|
Откатить ядро на 2.6.18-164.10.1.el5.028stab067.4ent - в моём случае помогло. Вообще, как я заметил, проблема остаётся в ядрах с нечетным номером на конце (в вашем случае 3), и убирается в ядрах с четным номером (в моём случае 4). Может это случайно, но последние 4-5 ядер этому правилу следуют 
Предыдущее ядро, где этого вообще не было - 64.8. Можно и его попробовать, раз 67.4 тоже сбоит.
Welcome to xfes.ru OpenVZ repository mirror
[Updated on: Fri, 12 March 2010 07:50] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Thu Nov 07 04:08:08 GMT 2024
Total time taken to generate the page: 0.03863 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
