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

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

Биллинг-система состоит из пяти демонов и скриптов. В нормальном состоянии все 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

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

В нормальном рабочем состоянии потребление памяти процессами биллинга может в норме доходить до 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