На всякий случай, в дампе может быть конфиденциальная информация, поэтому, если есть колебания, лучше его в техподдержку.
про прокси от 10-ки (не пишет в кеш)
#21
Отправлено 09 Октябрь 2015 - 14:03
#22
Отправлено 09 Октябрь 2015 - 14:13
ОС debian 8 x64. Причина падения ясна - too many open files. ulimit -n 100000 проблему решает.
Мне сложно отослать в саппорт... т.к. я в "кусте" и ключа у меня нет, ключ в вышестоящем территориально отделенном подразделении.
Сообщение было изменено Pavel Novikov: 09 Октябрь 2015 - 14:14
#23
Отправлено 09 Октябрь 2015 - 14:35
ОС debian 8 x64. Причина падения ясна - too many open files. ulimit -n 100000 проблему решает.
Мне сложно отослать в саппорт... т.к. я в "кусте" и ключа у меня нет, ключ в вышестоящем территориально отделенном подразделении.
Благодарим за сообщение, в следующей версии будем увеличивать этот параметр.
#24
Отправлено 09 Октябрь 2015 - 14:42
Благодарим за сообщение, в следующей версии будем увеличивать этот параметр.
Тут надо подумать. Дефолтных 8ki должно хватать на 4к подключений. Для дефолта вполне неплохо.
Pavel Novikov, у Вас сколько станций через прокси ходит?
#25
Отправлено 09 Октябрь 2015 - 14:58
Pavel Novikov, у Вас сколько станций через прокси ходит?
<255 но с этой проблемой я столкнулся еще в 6й версии. Возможно это особенность именно дебиана. А возможно (учитывая что проблема возникает не сразу, а может возникнуть через сутки - двое, даже когда все возможные станции подключились сразу после старта прокси) дескрипторы не закрываются.
А еще не надо забывать о том что куча косячных агентов поднимают сессии и рвут их. А ядро их снимет только через 60 сек.
Сообщение было изменено Pavel Novikov: 09 Октябрь 2015 - 15:01
#26
Отправлено 09 Октябрь 2015 - 15:06
А еще не надо забывать о том что куча косячных агентов поднимают сессии и рвут их. А ядро их снимет только через 60 сек.
Если кривые агенты ещё есть, и от них действительно остаются висячие соединения, то да, такое будет.
Если причина не в этом, а в утечке дескрипторов, то это был бы critical bug.
Ежели не трудно, посмотрите, плз, netstat на предмет всяких CLOSE_WAIT и что там ещё бывает в подобных случаях.
Сообщение было изменено Afalin: 09 Октябрь 2015 - 15:08
#27
Отправлено 09 Октябрь 2015 - 15:09
Например при 42 подключениях
lsof | grep drwcsd-p | wc -l
6071
Если кривые агенты ещё есть, и от них действительно остаются висячие соединения, то да, такое будет.
Но в том то и дело что это кривые агенты работают постоянно. Соединения то должны сбрасываться и дескрипторы закрываться, а получается что - накапливаются?
Сообщение было изменено Pavel Novikov: 09 Октябрь 2015 - 15:12
#28
Отправлено 09 Октябрь 2015 - 15:14
Например при 42 подключениях
lsof | grep drwcds-p | wc -l
6071
Хотелось бы ещё знать, в каком статусе висит большинство. В зависимости от направления – клиент или сервер.
#29
Отправлено 09 Октябрь 2015 - 15:26
Ежели не трудно, посмотрите, плз, netstat на предмет всяких CLOSE_WAIT и что там ещё бывает в подобных случаях.
По netstat висит (и уже давно) 11 CLOSE_WAIT клиент-прокси.
Что касается файлов в lsof - ~90%:
drwcsd-pr 3315 3319 root 1081u sock 0,7 0t0 56952 can't identify protocol
#30
Отправлено 09 Октябрь 2015 - 15:57
Хм. Кстати, 250 станций могут давать не больше 500 разрывов в минуту.
#31
Отправлено 09 Октябрь 2015 - 16:05
Те 11 CLOSE_WAIT так и висят. На тех же портах.
В общем что-то не так.
#32
Отправлено 09 Октябрь 2015 - 16:07
Хм. Кстати, 250 станций могут давать не больше 500 разрывов в минуту.
Разрывов да, а соединений? Порты то на клиенте динамические. С какой периодичностью агент пытается повторно соединиться с сервером?
#33
Отправлено 09 Октябрь 2015 - 16:20
С какой периодичностью агент пытается повторно соединиться с сервером?
Вот этого не скажу. Лучше по логам смотреть, долбятся такие агенты без задержек или таки с таймаутом порядка минуты.
#34
Отправлено 09 Октябрь 2015 - 16:36
По логам одна такая станция может долбиться с разных на своей стороне портов с периодичностью от 8 до 60 секунд. Так то.
#35
Отправлено 09 Октябрь 2015 - 18:10
Что-то как-то это нехорошо.
CLOSE_WAIT накапливаются ли с течением времени?
Ну и, если падает стабильно, то можно залить дамп куда-нибудь на cloud-disk и ссылку скинуть в личку мне или месье Afalin-у.
#36
Отправлено 09 Октябрь 2015 - 18:11
А вообще, можно начать с лога прокси, сделав его дебажным. И тоже в личку, хотя там конфиденциальности поменьше, но мало ли какие могут быть сведения.
#37
Отправлено 13 Октябрь 2015 - 13:54
С возвращением меня
Как включить дебаг на прокси?
Давеча у нас надолго пропадало питание, поэтому не работал прокси. После случившейсся полной перезагрузки прокси в режиме с отключенным кешем, указанного выше безобразия нет. Работает вторые сутки, ни CLOSE_WAIT ни безумного числа открытых неидентифицированных сокетов нет. Сдается мне все начнется если я включу кеш, что делать боязно т.к. после прошлого на нескольких машинах сбойнуло обновление, в результате чего на них было перекачано по ~200МБ, кодга я изменил режим назад.
Однако я это дело включу, отфильтровав пару подопытных по iptables. Т.ч. надо бы параметры для дебага и где их писать. Потом договорюсь, чтобы отправили в саппорт. Уж очень ширины канала жалко, он много для чего другого нужен.
#38
Отправлено 13 Октябрь 2015 - 14:17
Куда надо это вписать, на память не скажу, но демон должен запуститься с "--verbosity=ALL".
#39
Отправлено 13 Октябрь 2015 - 14:35
Куда надо это вписать, на память не скажу, но демон должен запуститься с "--verbosity=ALL".
Ок, спасибо, создал доп. параметр для старта с дебагом в /etc/init.d/dwcp-proxy, завтра начну эксперименты.
#40
Отправлено 19 Октябрь 2015 - 15:24
Странно теперь при включенном кеше безобразия нет. По крайней мере все пишется, сокетов кривых нет, и ошибка с крашем при перезапуске с не пустым кешем больше не возникает. Неужели хард-ресет помог?
Но поясните такой момент: если обновляется какая-то одна база, что - в кеш перекачиваются ВСЕ базы? И с компонентами тоже самое?
А если обновление по 10 раз на дню и скорость с сервером ES 32Кбит?
Сообщение было изменено Pavel Novikov: 19 Октябрь 2015 - 15:28
Читают тему: 0
0 пользователей, 0 гостей, 0 скрытых