Здравствуйте! Есть интересная проблема, над которой бьюсь уже приличный срок.
Имеется несколько разных серверов доступа на интеловском железе. Работают на терминации pptp и pppoe-туннелей (приблизительно 200-300 туннелей на сервер). Симптомы болезни у всех одинаковые.
Приблизительно сутки все работает прекрасно (иногда дольше, иногда меньше). Через некоторое время mpd отказывается принимать входящие соединения. Еще немного спустя (иногда почти сразу) полностью перестает работать все, что связано с сетью. Вплоть до отсутствия отклика на ping 127.0.0.1. ngctl запущенный без ключей при этом виснет намертво.
Каких-либо странностей в выводах обычных диагностических комманд не замечаю (netstat с различными ключами и пр.). Если нужен какой-то конкретный вывод -- приведу.
В настоящее время на серверах стоит следующее:
FreeBSD (6.3-RELEASE-p1/p2)
mpd5 (Version 5.1)
ipnat (ipf: IP Filter: v4.1.28 (416))
Когда подвисает mpd, в логах вижу приблизительно следующее:94146 May 5 02:14:53 torment mpd: pptp11: send EchoRequest msg
94147 May 5 02:14:53 torment mpd: len=16 msgType=1 magic=0x1a2b3c4d type=5
94148 May 5 02:14:53 torment mpd: id=0x79
94149 May 5 02:14:53 torment mpd: pptp46: send EchoRequest msg
94150 May 5 02:14:53 torment mpd: len=16 msgType=1 magic=0x1a2b3c4d type=5
94151 May 5 02:14:53 torment mpd: id=39
94152 May 5 02:14:53 torment mpd: pptp117: send EchoRequest msg
94153 May 5 02:14:53 torment mpd: len=16 msgType=1 magic=0x1a2b3c4d type=5
94154 May 5 02:14:53 torment mpd: id=14
94155 May 5 02:14:53 torment mpd: pptp117: recv EchoRequest
94156 May 5 02:14:53 torment mpd: id=0xf000000
94157 May 5 02:14:53 torment mpd: pptp117: send EchoReply msg
94158 May 5 02:14:53 torment mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6
94159 May 5 02:14:53 torment mpd: id=0xf000000 result=1 err=0 ignore=0
94160 May 5 02:14:53 torment mpd: pptp46: recv EchoReply
94161 May 5 02:14:53 torment mpd: id=39 result=1 err=0 ignore=0
94162 May 5 02:14:53 torment mpd: pptp11: recv EchoReply
94163 May 5 02:14:53 torment mpd: id=0x79 result=1 err=0 ignore=0
94164 May 5 02:14:53 torment mpd: pptp117: recv EchoReply
94165 May 5 02:14:53 torment mpd: id=14 result=1 err=0 ignore=0... и т.д. И больше ничего, хотя попытки установления соединения идут постоянно.
Умирать по killу при этом mpd отказывается, -9 в т.ч.
В чем может быть дело?
Ситуация конечно не точь в точь....
Сетевухи от интел, freebcd 6.2.
тоже мпд неубивался (и по -9),
сеть практичесски не работала - пингую какой-то локальный интерфейс - пинги не проходят. Как только на нем tcpdump запускаю - сразу интерфейс оживает. Процес, который убить нельзя (как потом заметил и mpd и named и др.) отъедает до 90% ресурсов процессора. Периодичность - примерно сутки. После перезагрузки - как новенький. Из всего криминала - две сетевухи были на одном прерывании - хотя это не повод был для волнения. Заменил все сетевухи на дубовый реалтик - все стало без проблем. Теперь жду нового железа (от интел) ну и соответственно новых проблем :)
>Ситуация конечно не точь в точь....а вот это не похоже?
http://www.opennet.ru/openforum/vsluhforumID1/80013.html>для волнения. Заменил все сетевухи на дубовый реалтик - все стало
>без проблем. Теперь жду нового железа (от интел) ну и соответственно
>новых проблем :)Хм. Интел никогда не подводил(
Кстати говоря, аналогичное поведение наблюдалось и с mpd5 5.0 и с FreeBSD 6.2-RELEASE
> Через некоторое время mpd отказывается принимать входящие соединения. Еще немного спустя
> (иногда почти сразу) полностью перестает работать все, что связано с сетью.
> ... и т.д. И больше ничего, хотя попытки установления соединения идут
>постоянно.
>Умирать по killу при этом mpd отказывается, -9 в т.ч.
>В чем может быть дело?Похоже, что mbufs заканчиваются. Если в top статус у процессов zoneli, то это именно оно. Лечится увеличением kern.ipc.nmbclusters, а вообще про это рассказывал Сысоев на какойто highload конференции (на opennet были ссылки на записи выступлений).
>Похоже, что mbufs заканчиваются. Если в top статус у процессов zoneli, то
>это именно оно. Лечится увеличением kern.ipc.nmbclusters, а вообще про это рассказывал
>Сысоев на какойто highload конференции (на opennet были ссылки на записи
>выступлений).Да, я тоже так по-началу подумал. На хайлоаде был, но Игоря не послушал, к сожалению. Тезисы читал -- вроде все обычно, почти по man tuning.
Вот вывод:
# netstat -m
1018/1037/2055 mbufs in use (current/cache/total)
843/575/1418/25600 mbuf clusters in use (current/cache/total/max)
843/565 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
1940K/1409K/3349K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/5/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routinesСоответственно:
kern.ipc.nmbclusters: 25600