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

думаю стоит уменьшить количество очередей хотя б по две на сетевую. 4 ядра как то не очень конечно. по идее ядро 0 - под даминет прибить жестко, остальные ядра между сетевыми раскидать, то что б не пересекались и тоже жестко привязать ядрам. ix - это не 10ГБ карточки? им могут помочь драйвера от яндекса, но надо пробовать.

проблема в том что дхцп демон стартует раньше мускула, а мускул дергает events.pl при получении или освобождении айпишников.
вроде как должно помочь

Код:

cat /usr/local/etc/rc.d/isc-dhcpd 
#! /bin/sh

# $FreeBSD: ports/net/isc-dhcp42-server/files/isc-dhcpd.in,v 1.4 2012/11/17 06:00:03 svnexp Exp $
#
# PROVIDE: dhcpd
REQUIRE: DAEMON mysql

поддержу - тоже самое для дхцп+опция82

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

Для напрямку 1 ставиш швидкість 0.1

так правила для 1 направления идут первыми, трафик на тв попадает в маску 0.0.0.0/0 и соответственно будет  резать скорость на 0.1.
вы же предлагаете закинуть правила для второго/третьего направления в начало фаервола, что я считаю, не по фен-шую).
не понятно для чего сделали - если не указана скорость то ставим какое то дефолтное значение - я считаю что если в тарифе не указал скорость для какого то направления то и не надо создавать пайпы и добавлять ипы в таблицу. по такой логике надо интернет (маска 0.0.0.0/0) надо изначально ставить в последнее направление. получается что любой тариф создает пайп в первом направлении.
конкретно в моем случае я пришел к варианту  сделать отдельный влан, без инета ( к примеру серые айпи без NATа) только до тв и все. но в будущем могут быть пакеты тв или еще как то задействуются направления. плюс решение с отдельным вланом такое себе - т.к. до клиента нужно его настроить.

есть такая схема

Приоритет   Сеть               Порт   Направление
300           0.0.0.0/0           0   Интернет      
1000         11.22.33.44/32   0   TV

задача - есть абоны, которым надо только айпитв, интернет надо заблочить.
при такой схеме, при создании тарифа не указывая скорость в первом направлении создается пайп в первом направлении.
при просмотре nofire есть строка

    #  Если у направления не указана скорость - трафик направления попадает в пайп 1го направления

получается что 0.0.0.0/0 надо перенести во второе направление а тв на первое, но тогда в фаерволе трафик всех пользователей пойдет через еще одно правило + надо переделать все тарифы - как бы не очень вариант.
вопрос - что дает для чего нужен приоритет в указании направлений. и самое главное для чего такая конструкция что если не указана скорость все равно создается пайп и соответственно в 21 таблице есть ип клиента с айпитв. можно ли отключит это поведение и чем будет чревато? 

я так понял что только исполнителю приходит сообщение. не знаю как у остальных, у нас на колцентре принимают заявку, а кто будет ее выполнять - не ведают. а вот руководитель уже назначает кому что и когда. вот и хотелось что б изменения тикетов куда нибудь ( телеграм, почта и т.п.) приходило руководителю, а он уже назначает кого куда. ну и собственно как на счет патча за допплату  для фильтра по группам?

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

АП

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

с Новым Годом и ап)

ап

я могу в предоплату 100%, так сказать для надежности. ну очень нужен функционал

ап

для этого есть модуль "группировка списаний"

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

дабы не плодить темы. вот использую режим "пропорциональный" - можно как то сделать что б не было начислений каждый день - жутко не удобно просматривать историю платежей. может, как вариант, при пополнении на, к примеру 100 рублей, услуга продлевалась на соответствующее время(дни, часы) и соответственно списывалось одним платежом.
примерно - услуга имеет срок действия 0 дней 0 часов, а в настройках месяц стоит 300р. значить день 10р, или просто сколько стоит день.
пополнил на 100р 01.11.2021 09:11 срок действия услуги изменился до 10.11.2021 09:11 и соответствующая запись о списании.
или пополнил на 1000р 01.11.2021 09:11, значить конец услуги 2022-02-09 09:11 (+100 дней) одной записью.
при завершении так же - сколько осталось не использовано вернуть на счет в деньгах. в личном кабинете абон видит до когда продлена услуга, ну можно динамически подсчитывать сколько это в деньгах.
ЗЫ. покупал модуль для группировки списаний - но получается что записи просто в одну объединяются и остается такая же простыня(