Подвисания mpd/netgraph, lup, 07-Май-08, 14:45 [смотреть все]Здравствуйте! Есть интересная проблема, над которой бьюсь уже приличный срок. Имеется несколько разных серверов доступа на интеловском железе. Работают на терминации 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 в т.ч. В чем может быть дело?
|
- Подвисания mpd/netgraph, kaats, 18:35 , 07-Май-08 (1)
- Подвисания mpd/netgraph, lup, 20:20 , 07-Май-08 (2)
>Ситуация конечно не точь в точь.... а вот это не похоже? https://www.opennet.ru/openforum/vsluhforumID1/80013.html >для волнения. Заменил все сетевухи на дубовый реалтик - все стало >без проблем. Теперь жду нового железа (от интел) ну и соответственно >новых проблем :) Хм. Интел никогда не подводил( Кстати говоря, аналогичное поведение наблюдалось и с mpd5 5.0 и с FreeBSD 6.2-RELEASE
- Подвисания mpd/netgraph, AMDmi3, 23:44 , 07-Май-08 (3)
- Подвисания mpd/netgraph, lup, 19:53 , 08-Май-08 (4)
>Похоже, что 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
|