Высокая нагрузка CPU. Задержка пакетов, при небольшом канале

Skip to end of metadata
Go to start of metadata

Вопрос:

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

Ответ:
Многие сетевые карты поддерживают режим паузы. 
В случае, если канал перегружен, коммутатор или маршрутизатор посылает специальный пакет для паузы tx или rx, либо создает искусственную Ethernet коллизию.
Сетевая карта это обнаруживает и задерживает отправку пакета, при этом висит в цикле, из-за этого видимая нагрузка на процессор.
Как только коммутатор сообщает, что «все ОК», пакет отправляется, из-за этого происходит задержка пакета.
Можно посмотреть эту возможность в сетевой карте ethtool -a Eeth2 и можно отключить ethtool -A Eeth2 rx off tx off.
При отключении паузы пакет будет отправлен в любом случае, даже если противоположная сторона не может принять. Это приведет к нормализации времени задержки, но к потери пакетов.
Для того чтобы полностью решить проблему канала, необходимо решать задачу на уровне Ethernet оборудования.

ics_tune.sh

#!/bin/bash
if [ "$1" = "firewall.sh" ] ; then
ethtool -A Eeth2 rx off tx off;
fi

Вопрос:

Повышенная загрузка сервера, в частности , процесс gds_inet_server создает большую нагрузку на процессор, когда сервер простаивает.

Ответ1:

Может быть вызвана тем, что какое-то время назад была удалена группа, в которой находились абоненты. Система пытается проверить статус таких абонентов и тратит много мощности на поиск абоненты с удаленным родителем.
В таком случае нужно смотреть по разделу Аудит в менеджере какую группу удаляли перед тем, как началась проблема.
Также обнаружить можно случайно, попробовав найти одного из таких абонентов поиском. Если при открытии абонента вас перенаправит на корневую группу, значит проблема есть - сообщите специалистам технической поддержки о ней.

Ответ2:

1. Если в лог-файле /var/log/execd встречаются записи вида:

Dec 08 16:30:55 watchdog: SYSTEM.ALARM gds_inet_server gds_inet_server uses 90 cpu, and 87 allowed
Dec 08 17:22:34 watchdog: SYSTEM.ALARM gds_inet_server gds_inet_server uses 92 cpu, and 87 allowed
Dec 08 18:21:00 watchdog: SYSTEM.ALARM gds_inet_server gds_inet_server uses 88 cpu, and 87 allowed
Dec 08 20:56:27 watchdog: SYSTEM.ALARM gds_inet_server gds_inet_server uses 89 cpu, and 87 allowed
Dec 09 11:23:03 watchdog: SYSTEM.ALARM gds_inet_server gds_inet_server uses 88 cpu, and 87 allowed
Dec 09 12:14:15 watchdog: SYSTEM.ALARM gds_inet_server gds_inet_server uses 92 cpu, and 87 allowed

такие записи означают что неверно заданы глобальные настройки, например у группы "Все" не задан тариф.

2. Высокая нагрузка может быть вызвана отсутствием оптимизации работы сервера при выросшей абонентской базе или расширением канала до вышестоящего провайдера.
Для оптимизации работы биллинга необходимо выполнить последующие рекомендации и обратить внимание на следующие моменты:

  1. Не рекомендуется использование snmpd, при ppp-авторизации т.к. сильно нагружает систему;
  2. При использовании внешнего канала более 300 мб/с и ppp-авторизации рекомендуется 6-8 ядерный процессор.
    При подборе процессора следует учесть:
    - ядро - на каждые 500 пользователей с ppp-авторизацией нужно одно ядро,
    - ядро - на поддержание работы самого биллинга,
    - ядро - на обработку статистки bstatd
    - ядро зарезервировать для пиковых нагрузок.
    Также нужно выключить Hyper-threading
  3. При отсутствии возможности провести апгрейд сервера для снижения нагрузки на биллинг нужно перевести абонентов на отдельные сервера доступа - NAS-сервера
  4. При большой абонентской базе рекомендуем в локальном меню, в разделе "Дополнительные настройки" -> "Настройки для разработчиков"
    - установить опцию "проверять смену шейпера через n, пакетов" в значение 10000 - 50000
    - установить опцию "Проверять только каждый n, пакет сессии" в значение 1000 - 50000
  5. Проверить что размер БД не превышает 2ГБ
    du -h /var/db/ics_main.gdb
    

    если размер БД превышен, то выполнить шаги из статьи Уменьшение размера БД, раздел "Уменьшить размер БД"

  6. Проверить фрагментацию БД
    filefrag /var/db/ics_main.gdb
    

    В полученной строрке будет 2 числа, отношение первого числа ко второму будет значением фрагментации.
    Если фрагментация превышает 500, то есть возможность несколько уменьшить фрагментацию БД путем отключения опции "Отключить полную проверку БД при загрузке" в разделе "Дополнительные настройки"
    После этого сделать полную перезагрузку сервера и вернуть флажок опции "Отключить полную проверку БД при загрузке" обратно
    Если после этого фрагментация БД не станет меньше, то рекомендуется вынести статистику и БД на отдельный диск.

  7. Обновить сервер на последнюю актуальную версию, доступную на сайте http://www.carbonsoft.ru/download/

// Высокая загрузка

// задержка пакетов

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.