Решение проблем с ядром

Материал из ExpertBilling
Версия от 10:55, 26 сентября 2011; 212.98.162.97 (обсуждение) (→‎Поиск и решение проблем в работе ядра биллинговой системы)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Поиск и решение проблем в работе ядра биллинговой системы

Биллинг-система состоит из пяти демонов

  • core
  • rad
  • nf
  • nfroutine
  • rpc

и скриптов.

В нормальном состоянии все 5 демонов должны быть запущены и команда top должна выдавать что-то типа этого: 

top - 10:21:15 up 25 days,  2:18,  4 users,  load average: 0.08, 0.06, 0.00
Tasks: 139 total,   1 running, 134 sleeping,   4 stopped,   0 zombie
Cpu(s):  2.2%us,  0.2%sy,  0.0%ni, 97.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2257132k total,  2115932k used,   141200k free,   208968k buffers
Swap:  9871900k total,      800k used,  9871100k free,  1371504k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                          
30022 root      20   0  110m  32m 3880 S    7  1.5 158:34.77 nf                                                                                                                                                                               
30029 root      20   0 93540  11m 3748 S    1  0.5   7:57.67 core                                                                                                                                                                             
30083 postgres  20   0  933m  21m  19m S    1  1.0   1:25.88 postgres                                                                                                                                                                         
11067 root      20   0  126m  15m 3876 S    0  0.7  11:38.73 rad                                       
11069 root      20   0  135m  12m 3830 S    0  0.6   3:11.24 rpc                                       
.....

Проверить запущенность каждого из демонов можно командой. 

ps aux | grep имя демона

К примеру 

host5:~# ps aux | grep rad
root     11067  0.2  0.7 129212 16188 ?        Sl   Sep20  11:40 /opt/ebs/data/rad

Анализ лог-файлов

Серверная часть биллинг-системы использует следующие лог-файлы для логирования событий: 

/opt/ebs/data/log/
                  core_log
                  rad_log
                  nf_log
                  nfroutine_log
                  rpc_log

При отсутствии ошибок в лог-файлы пишутся информационные сообщения о времени обработки данных. Типичный лог радиуса при авторизации DHCP клиентов: 

2011-09-26 16:54:51,822 DEBUG    AUTH:#0: AuthHandler: Access type: DHCP, packet: 1
2011-09-26 16:54:51,822 WARNING  DHCP option82 remote_id, port 14d64d420860 5
2011-09-26 16:54:51,823 INFO     AUTH:#0: AuthHandler: AUTH time: 0.0 USER: F4:6D:04:55:B8:AD NAS: 10.0.0.1 TYPE: DHCP
2011-09-26 16:54:54,829 DEBUG    AUTH:#0: AuthHandler: Access type: DHCP, packet: 1
2011-09-26 16:54:54,830 WARNING  DHCP option82 remote_id, port 14d64d420860 5
2011-09-26 16:54:54,830 INFO     AUTH:#0: AuthHandler: AUTH time: 0.0 USER: F4:6D:04:55:B8:AD NAS: 10.0.0.1 TYPE: DHCP
2011-09-26 16:54:57,909 DEBUG    AUTH:#1: AuthHandler: Access type: DHCP, packet: 1
2011-09-26 16:54:57,910 WARNING  DHCP option82 remote_id, port 14d64d420860 5
2011-09-26 16:54:57,910 INFO     AUTH:#1: AuthHandler: AUTH time: 0.0 USER: F4:6D:04:55:B8:AD NAS: 10.0.0.1 TYPE: DHCP
2011-09-26 16:55:16,233 INFO     ast time : 0.0
2011-09-26 16:55:16,234 INFO     AUTH queue len: 0
2011-09-26 16:55:16,234 INFO     ACCT queue len: 0

Если же вы в третьей колонке видите ERROR или EXCEPTION, это повод связаться с разработчиками и выяснить причину ошибки.

Потребление ресурсов

В нормальном рабочем состоянии потребление памяти процессами биллинга может в норме доходить до 200-250 мегабайт на процесс. В выводе команды top это колонка RES. В случае, если потребляемый объём больше указанного - необходимо увеличить производительность сервера и оптимизировать конфигурацию биллинга и postgresql.

Загрузка процессора может сильно отличаться в зависимости от объёма абонентской базы. На этот параметр сильно влияет расширенный уровень логирования log_level=0. Чтобы его уменьшить выставьте эту опцию в конфиг-файле для всех процессов биллинга равную 2. Так же снижать производительность может запись netflow статистики, которая отключается в секции [nf] опцией flow=False.

Оптимизация сервера БД

На производительность PostgreSQL большую роль оказывает параметр его конфиг-файла /etc/postgresql/8.4/main/postgresql.conf 

shared_buffers = 32MB

Ограничение в 32 мегабайта сделано по причине того, что некоторые операционные системы при компиляции ядра указывают жёсткое ограничение на объём shared памяти и этого объёма явно мало для эффективной работы. Размер shared_buffer должен быть от 1/4 до 1/2 оперативной памяти, установленной на компьютер. Для того, чтобы его изменить, нужно указать ядру новый максимальный размер shared памяти. Это делается в файле /etc/sysctl.conf Добавьте в конец файла 2 строки 

kernel.shmmax=объём шаред памяти в байтах
kernel.shmall=объём шаред памяти в байтах

После того, как сделали изменения, сделайте systlc -p, чтобы их применить. После чего укажите в параметре shared_buffers новое значение в мегабайтах, которое будет немного меньше параметров shmmax и shmall и перезапустите Postgresql следующей командой, предварительно остановив процессы биллинга с помощью billing stop или billing force-stop 

/etc/init.d/postgresql-8.4 restart
Источник — «http://wiki.expertbilling.ru/index.php?title=Решение_проблем_с_ядром&oldid=284»