BiTel

Доброго дня,

На почту от биллинга сыпятся валом письма:


Причем у меня в /etc/security/limits.conf:

и:
# ulimit -a


Что делать? В онлайне всего 250 человек.

Вот что показывает BGInetAccess:



Вот BGInetAccess:



Сервер:


Версии:


Линукс Debian на ядре 2.6.32-5-amd64

а место на диске есть?

полно

а что показывает

Отправил вам в личку аттачем вывод lsof

За ночь на почту свалилось 140 писем. Есть идеи?

нужен вывод


где 16950 - это код процесса access.

stark, отправил вам в личку вывод команды

проблема примерно ясна. Сохраните логи log4j access-сервера куда-нибудь на всякий случай(вдруг понадобятся для разбора ) и перезапустите его. Это временно решит проблему, а мы пока разберемся почему он файлы не закрывает.

По списку открытых файлов вроде бы есть проблема.
Но также судя по этому списку, у приложения открыто чуть больше 1000 файловых дескрипторов, что на самом деле не много.
Например, судя по открытым файлам у вас около 250 коммутаторов, от них идет DHCP, для каждого открыты по два файла, это уже до 500 открытых файловых дескрипторов.
А каждые 15 минут создаются новые файлы логов, при этом в этот момент времени предыдущие еще открыты, что может увеличить кол-во открытых дескрипторов.
Плюс различные сокеты.

http://wiki.bitel.ru/index.php/%D0%9E%D ... n_files%22
Может быть еще в каком-нибудь месте есть лимит? Или же какое-то другое приложения (BGBilling) или другое держит открытыми остальные 31000?

можно вывести таким запросом


вместо user - пользователя поставить (root или что у вас там).

Я перегрузил, сейчас пока все норм.

/etc/security/limits.conf у меня такой:


BGInetAccess запущен из под рута.

А sysctl (как http://wiki.bitel.ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%B2_%D0%BB%D0%BE%D0%B3%D0%B5_%22Too_many_open_files%22):

Коммутаторов сейчас 215, кстати а как чистить (старые) файлы в /usr/local/BGInetAccess/data/dhcp? Каталог растет очень шустро...
Я сделал простенький скриптик, который удаляет папки в названии которых нет текущего месяца, но может есть какой-то правильный метод? Из конфигурации?

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

апдейтну пожалуй... пока писем too many open files больше не приходит, но продолжают идти письма:


Увеличил эти значения до 100 и 500 соответственно, теперь:


Какие значения порекомендуете на 250 коммутаторов и 350 онлайн абонентов? С учетом активного роста.

В это время что-нибудь происходит? Бэкап, смена скоростей или что-нибудь еще?
Сохраните в это время вывод jstack несколько раз.

да, бакап базы, через xtrabackup, он вроде как не должен блокировать ввод/вывод.
Сделаю jstack в момент бакапа

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Только что пришло 11 писем от биллинга что:


На данный момент:


На данный момент бакапы не снимаются.

Опять увеличить количество потоков? Свичей сейчас 272.

Нужен вывод jstack для Access и для Accounting.

Отправил вам в личку

Может пора выносить dhcp на отдельный сервер? Как вообще расчитывать значения для количества потоков и размера очереди? Можно указать сразу миллион например?

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

Вчера увеличил lease time для dhcp, сегодня первая ночь когда мне биллинг не написал ни одного письма да будет так...

А сколько был leasetime?

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

Если на абонента разрешена только одна сессия, то можно попробовать указать dhcp.connection.closeOnNew=1, чтобы при получении DISCOVER от абонента текущая сессия закрывалась на биллинге.
В 6.0/6.1 есть InetDhcpProcessor2, который должен работать быстрее, но он пока не полностью проверен.

В последнем билде добавили, что при оповещении о том, что не успевает обрабатывать, дополнительно будет вывод аналогичный выводу jstack, который может помочь решить проблему.

Сглазил... сегодня ночью во время бакапа базы пришло:
ID события: dhcpLstnr.wait.thread
и еще новое:


Насчет:

Это было бы здорово. Только у меня же еще вторая сессия есть у абонента - radius сессия от ISG браса. Что будет с ней в это случае? Она по идее не должна дропнуться, ведь ip у абонента останется тот же. Даже если и дропнется, не страшно, она же сразу пересоздастся с первым ip пакетом?


Для этого достаточно просто обновиться? Или нужно переключаться на InetDhcpProcessor2?

Насколько помню, при этой схеме у вас будет принудительный сброс сессии на ISG, т.к. он задан в самом ServiceActivator (например, ru.bitel.bgbilling.modules.inet.dyn.device.cisco.ipdhcp.ISGServiceActivatorIpDhcp), т.к. адрес может выдаваться динамически и для нового устройства - выдаться новый.
Должна пересоздаться.

Но возможны случаи, когда на Accounting пришел стоп, одновременно пришел Access-Request на Access, а Accounting еще не успел завершить предыдущую сессию и Access решает, что превышено кол-во активных сессий (т.е. проблема возникает именно при моментальной переавторизации). В этом случае рекомендуем использовать radius.connection.checkDuplicate=888 http://bgbilling.ru/v6.1/doc/ch17s13s03s01.html .
Но здесь возникала проблема, что при сбросе старой сессии раньше не рассматривалась разница между DHCP- или RADIUS-сессией и могла сброситься DHCP-сессия. Поэтому добавили возможность проверки на кол-во сессий отдельно по разным типам - в конфигурации модуля - authorization.sessionCountCheck=1. С этим флагом подразумевается, что, ограничение на кол-во сессий действует на каждый тип сессии отдельно. Т.е. вместо ограничения на 2 сессии можно/нужно будет указать 1 сессию (одна DHCP и одна RADIUS и в будущем, например, одна DHCPv6).
Т.е. вместе с radius.connection.checkDuplicate=888 лучше сразу указать в конфигурации модуля authorization.sessionCountCheck=1.
Но DHCP так работает, что шаг вправо, шаг влево может привести к неожиданным последствиям, поэтому следует менять осторожно, какое-то время наблюдать (но как минимум на одной инсталляции authorization.sessionCountCheck=1 уже работает).

Да, достаточно обновиться.