Home » International » Russian » Зависание системы (сети?) в ядрах старше 64.8 на CentOS (unregister_netdevice: device xxxxx marked to leak и TCP: time wait bucket table overflow (CTXXXX))
| 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 |
|
|
|
Current Time: Thu Jul 25 22:32:28 GMT 2024
Total time taken to generate the page: 0.03300 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
