49 ответов в этой теме

[Kirill Polubelov]

На всякий случай, в дампе может быть конфиденциальная информация, поэтому, если есть колебания, лучше его в техподдержку.

[Pavel Novikov]

ОС debian 8 x64. Причина падения ясна - too many open files. ulimit -n 100000 проблему решает.

 

Мне сложно отослать в саппорт... т.к. я в "кусте" и ключа у меня нет, ключ в вышестоящем территориально отделенном подразделении.

Сообщение было изменено Pavel Novikov: 09 Октябрь 2015 - 14:14

[kr0n]

ОС debian 8 x64. Причина падения ясна - too many open files. ulimit -n 100000 проблему решает.

 

Мне сложно отослать в саппорт... т.к. я в "кусте" и ключа у меня нет, ключ в вышестоящем территориально отделенном подразделении.

Благодарим за сообщение, в следующей версии  будем увеличивать этот параметр.

[Afalin]

Благодарим за сообщение, в следующей версии  будем увеличивать этот параметр.

Тут надо подумать. Дефолтных 8ki должно хватать на 4к подключений. Для дефолта вполне неплохо.

 

Pavel Novikov, у Вас сколько станций через прокси ходит?

[Pavel Novikov]

Pavel Novikov, у Вас сколько станций через прокси ходит?

<255 но с этой проблемой я столкнулся еще в 6й версии. Возможно это особенность именно дебиана. А возможно (учитывая что проблема возникает не сразу, а может возникнуть через сутки - двое, даже когда все возможные станции подключились сразу после старта прокси) дескрипторы не закрываются.

 

А еще не надо забывать о том что куча косячных агентов поднимают сессии и рвут их. А ядро их снимет только через 60 сек.

Сообщение было изменено Pavel Novikov: 09 Октябрь 2015 - 15:01

[Afalin]

А еще не надо забывать о том что куча косячных агентов поднимают сессии и рвут их. А ядро их снимет только через 60 сек.

Если кривые агенты ещё есть, и от них действительно остаются висячие соединения, то да, такое будет.

Если причина не в этом, а в утечке дескрипторов, то это был бы critical bug.

 

Ежели не трудно, посмотрите, плз, netstat на предмет всяких CLOSE_WAIT и что там ещё бывает в подобных случаях.

Сообщение было изменено Afalin: 09 Октябрь 2015 - 15:08

[Pavel Novikov]

Например при 42 подключениях

 

lsof | grep drwcsd-p | wc  -l

6071

 

 

 

Если кривые агенты ещё есть, и от них действительно остаются висячие соединения, то да, такое будет.

Но в том то и дело что это кривые агенты работают постоянно. Соединения то должны сбрасываться и дескрипторы закрываться, а получается что - накапливаются?

Сообщение было изменено Pavel Novikov: 09 Октябрь 2015 - 15:12

[Afalin]

Например при 42 подключениях

 

lsof | grep drwcds-p | wc  -l

6071

Хотелось бы ещё знать, в каком статусе висит большинство. В зависимости от направления – клиент или сервер.

[Pavel Novikov]

Ежели не трудно, посмотрите, плз, netstat на предмет всяких CLOSE_WAIT и что там ещё бывает в подобных случаях.

По netstat висит (и уже давно) 11 CLOSE_WAIT клиент-прокси.

 

Что касается файлов в lsof - ~90%:

drwcsd-pr 3315 3319        root 1081u     sock                0,7      0t0      56952 can't identify protocol

[Afalin]

Хм. Кстати, 250 станций могут давать не больше 500 разрывов в минуту.

[Pavel Novikov]

Те 11 CLOSE_WAIT так и висят. На тех же портах.

 

В общем что-то не так.

[Pavel Novikov]

Хм. Кстати, 250 станций могут давать не больше 500 разрывов в минуту.

Разрывов да, а соединений? Порты то на клиенте динамические. С какой периодичностью агент пытается повторно соединиться с сервером?

[Afalin]

С какой периодичностью агент пытается повторно соединиться с сервером?

Вот этого не скажу. Лучше по логам смотреть, долбятся такие агенты без задержек или таки с таймаутом порядка минуты.

[Pavel Novikov]

По логам одна такая станция может долбиться с разных на своей стороне портов с периодичностью от 8 до 60 секунд. Так то.

[Kirill Polubelov]

Что-то как-то это нехорошо.

CLOSE_WAIT накапливаются ли с течением времени?

Ну и, если падает стабильно, то можно залить дамп куда-нибудь на cloud-disk и ссылку скинуть в личку мне или месье Afalin-у.

[Kirill Polubelov]

А вообще, можно начать с лога прокси, сделав его дебажным. И тоже в личку, хотя там конфиденциальности поменьше, но мало ли какие могут быть сведения.

[Pavel Novikov]

С возвращением меня

 

Как включить дебаг на прокси?

 

Давеча у нас надолго пропадало питание, поэтому не работал прокси. После случившейсся полной перезагрузки прокси в режиме с отключенным кешем, указанного выше безобразия нет. Работает вторые сутки, ни CLOSE_WAIT ни безумного числа открытых неидентифицированных сокетов нет. Сдается мне все начнется если я включу кеш, что делать боязно т.к. после прошлого на нескольких машинах сбойнуло обновление, в результате чего на них было перекачано по ~200МБ, кодга я изменил режим назад.

 

Однако я это дело включу, отфильтровав пару подопытных по iptables. Т.ч. надо бы параметры для дебага и где их писать. Потом договорюсь, чтобы отправили в саппорт. Уж очень ширины канала жалко, он много для чего другого нужен.

[Afalin]

Куда надо это вписать, на память не скажу, но демон должен запуститься с "--verbosity=ALL".

[Pavel Novikov]

Куда надо это вписать, на память не скажу, но демон должен запуститься с "--verbosity=ALL".

 

Ок, спасибо, создал доп. параметр для старта с дебагом в /etc/init.d/dwcp-proxy, завтра начну эксперименты.

[Pavel Novikov]

Странно теперь при включенном кеше безобразия нет. По крайней мере все пишется, сокетов кривых нет, и ошибка с крашем при перезапуске с не пустым кешем больше не возникает. Неужели хард-ресет помог?

 

Но поясните такой момент: если обновляется какая-то одна база, что - в кеш перекачиваются ВСЕ базы? И с компонентами тоже самое?

 

А если обновление по 10 раз на дню и скорость с сервером ES 32Кбит?

Сообщение было изменено Pavel Novikov: 19 Октябрь 2015 - 15:28