Решение проблем с ядром
Поиск и решение проблем в работе ядра биллинговой системы
Биллинг-система состоит из пяти демонов
- 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
Потребление ресурсов
В нормальном рабочем состоянии потребление памяти процессами биллинга может в норме доходить до 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