taf_321

Вот и сравнивайте сравнимое. Когда у каждого оператора на 5-15к абонентов будет по департаменту по уходу за MySQL численностью до 1к, вот тогда и приходите с этим примером.

Для начала мыскль там крутится на весьма узких задачах, за ним ухаживает целый департамент и все равно ни одной недели без факапа. А уж после недавнего выпуска с фиксом 40 (!!!!!) CVE смотреть на мыскль как на серьезную платформу это от великого ума. Мария и перкона проблем не решает, а добавляет во весь этот лядский цирк тонкий аромат прогрессирующей фрагментации.

Разработчики не думали про смену FB на что-то нормальное? При всей заслуженности FB, использовать ее для крупных проектов и критических задач в 2020-е годы это отдельный вид эктрима.

Содержимое discount_transactions_all и discount_transactions_iptraffic_all я бы не рекомендовал трогать и менять, так как можно получить в итоге кривые данные при генерации отчетов. Если старые данные уже отсеяны в архивные таблицы, то пусть лежат. Реально они занимают не так и много места.

Указанные параметры задаются через админку: Настройка -> Настройки системы. Если их нет, то можно добавить самостоятельно. У нас тарифные планы все исключительно безлимитные, поэтому параметр traffic_agregation_interval выставлен в 7200. В итоге в таблицы discount_transactions_all и discount_transactions_iptraffic_all записи вносятся раз в два часа по каждому активному клиенту. Главным засирателем базы у меня был родной нетуповский радиус, который на каждый Acc-Update вместо банального UPDATE в базе генерил Session-Stop - Session-Start. Разрабам по этому поводу в свое время писал, и даже тикет создавался с развестистой перепиской, но они поклали прибор объявив такое поведение правильным. В итоге переехал на FreeRADIUS.

По законодательству РФ данные нужно хранить минимум три года + данные за текущий (в максиме получается данные за четыре года). То, что уже нагенерено лучше не трогать. Может имеет смысл обратить внимание на то, что генерит слишком много записей? К примеру, увеличить промежуток агрегации (ЕМНИП, за это отвечает параметр traffic_agregation_interval). И еще помедитировать над количеством списаний в течении расчетного периода для типа списания "в течении всего расчетного периода" (flow_discounts_per_period)

160 это еще семечки. Тормоза происходят из-за того, что при создании интерфейса в лучших традициях unix-way используется потоковый вызов всяких утилит, на каждую из которых формируется системное окружение. Лечение одно - оформить создание толпы этих интерфейсов через batch-файл для ip.   Будет так же тормозить. Лучше заставить все делать только ip, благо он это умеет. Нарисовать batch с чем-то вроде link add link eth0 name eth0.100 type vlan id 100 link set dev eth0.100 up ...и так далее со всеми остановками, где надо можно добавлять нечто addr add 192.168.100.1/24 brd 192.168.100.255 dev eth0.100 И при старте системы или accel'я делать вызов ip -force -batch batch-file

Я бы в пункте 3 загрузился бы с какого-нибудь LiveCD, провел бы манипуляции по разбиению пространства на новых носителях и создания там новой ФС. А потом тупо скопировал бы содержимое старого диска на новый пофайлово (cp, rsync или банальный mc по вкусу). После чего на новом месте вносятся правки на тему uuid новых устройств/файловых систем (у меня это свелось к правке в /etc/fstab и /etc/default/grub). И далее в каком-нибудь /mnt монтируем все новые файловые системы чтобы был и полный / и /usr и /var c /home если они разнесены по разным ФС), в эту же иерархию через -o bind пробрасываем существующие /dev /proc и /sys. Далее просто chroot /mnt и уже из-под chroot'а колдунствуем на тему grub-install/grub-mkconfig и перегенерацию initrd. И совсем не понял смысла с жонглированием дисками из гнезда в гнездо.

И как результат ниже перечисленные запретительные правила не отрабатывают. Опять же мое IMHO, но лучше рисовать правила как для stateless FW. Оно как бы надежнее, и в случае чего можно достаточно просто отказаться от conntrack, ибо нужен он как неизбежное зло только для NAT.

Надо добавить разрешающее правило для icmp type 3, иначе получится собственная Path MTU Discovering Black Hole. Правило INPUT -i $IF_EXT -m set --match-set BOGONS src -j DROP лучше поставить сразу после INPUT -i $IF_LOOP -j ACCEPT. Правило -m state --state ESTABLISHED,RELATED -j ACCEPT должно идти самым последним в цепочке.

Чисто IMHO: городить портянки в баше, описывая правила через iptables -A это уже не по фэншую. На мой взгляд лучше вынести описание правил в отдельный файл и загружать правила через ip[6]tables-restore /path/to/rules. То же самое и с ipset. Читабельность улучшается на порядки.

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

В любом случае разумного обоснования покупки М2 просто нет. Китайцы в той же нише давно уже впереди и в плане ценника и в плане точности измерения и в удобстве работы.

Но при чем тут bird?

И еще, куда запятую в перечислении пролюбили?