Решение проблем с ядром — различия между версиями
(Новая страница: «jjjjjjjjjjjjjjjjjjj») |
(→Поиск и решение проблем в работе ядра биллинговой системы) |
||
| (не показаны 2 промежуточные версии 1 участника) | |||
| Строка 1: | Строка 1: | ||
| − | + | = Поиск и решение проблем в работе ядра биллинговой системы = | |
| + | Биллинг-система состоит из пяти демонов | ||
| + | * core | ||
| + | * rad | ||
| + | * nf | ||
| + | * nfroutine | ||
| + | * rpc | ||
| + | и скриптов. | ||
| + | |||
| + | В нормальном состоянии все 5 демонов должны быть запущены и команда top должна выдавать что-то типа этого: | ||
| + | <pre> | ||
| + | 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 | ||
| + | ..... | ||
| + | </pre> | ||
| + | |||
| + | Проверить запущенность каждого из демонов можно командой. | ||
| + | <pre> | ||
| + | ps aux | grep имя демона | ||
| + | </pre> | ||
| + | К примеру | ||
| + | <pre> | ||
| + | host5:~# ps aux | grep rad | ||
| + | root 11067 0.2 0.7 129212 16188 ? Sl Sep20 11:40 /opt/ebs/data/rad | ||
| + | </pre> | ||
| + | == Анализ лог-файлов == | ||
| + | Серверная часть биллинг-системы использует следующие лог-файлы для логирования событий: | ||
| + | <pre> | ||
| + | /opt/ebs/data/log/ | ||
| + | core_log | ||
| + | rad_log | ||
| + | nf_log | ||
| + | nfroutine_log | ||
| + | rpc_log | ||
| + | |||
| + | </pre> | ||
| + | При отсутствии ошибок в лог-файлы пишутся информационные сообщения о времени обработки данных. | ||
| + | Типичный лог радиуса при авторизации DHCP клиентов: | ||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
| + | Если же вы в третьей колонке видите ERROR или EXCEPTION, это повод связаться с разработчиками и выяснить причину ошибки. | ||
| + | |||
| + | == Потребление ресурсов == | ||
| + | В нормальном рабочем состоянии потребление памяти процессами биллинга может в норме доходить до 200-250 мегабайт на процесс. В выводе команды top это колонка RES. В случае, если потребляемый объём больше указанного - необходимо увеличить производительность сервера и оптимизировать конфигурацию биллинга и postgresql. | ||
| + | |||
| + | Загрузка процессора может сильно отличаться в зависимости от объёма абонентской базы. На этот параметр сильно влияет расширенный уровень логирования log_level=0. Чтобы его уменьшить выставьте эту опцию в конфиг-файле для всех процессов биллинга равную 2. Так же снижать производительность может запись netflow статистики, которая отключается в секции [nf] опцией flow=False. | ||
| + | |||
| + | == Оптимизация сервера БД == | ||
| + | На производительность PostgreSQL большую роль оказывает параметр его конфиг-файла /etc/postgresql/8.4/main/postgresql.conf | ||
| + | <pre> | ||
| + | shared_buffers = 32MB | ||
| + | </pre> | ||
| + | Ограничение в 32 мегабайта сделано по причине того, что некоторые операционные системы при компиляции ядра указывают жёсткое ограничение на объём shared памяти и этого объёма явно мало для эффективной работы. | ||
| + | Размер shared_buffer должен быть от 1/4 до 1/2 оперативной памяти, установленной на компьютер. | ||
| + | Для того, чтобы его изменить, нужно указать ядру новый максимальный размер shared памяти. Это делается в файле /etc/sysctl.conf | ||
| + | Добавьте в конец файла 2 строки | ||
| + | <pre> | ||
| + | kernel.shmmax=объём шаред памяти в байтах | ||
| + | kernel.shmall=объём шаред памяти в байтах | ||
| + | </pre> | ||
| + | После того, как сделали изменения, сделайте systlc -p, чтобы их применить. | ||
| + | После чего укажите в параметре shared_buffers новое значение в мегабайтах, которое будет немного меньше параметров shmmax и shmall и перезапустите Postgresql следующей командой, предварительно остановив процессы биллинга с помощью billing stop или billing force-stop | ||
| + | <pre> | ||
| + | /etc/init.d/postgresql-8.4 restart | ||
| + | </pre> | ||
Текущая версия на 09:55, 26 сентября 2011
Содержание
Поиск и решение проблем в работе ядра биллинговой системы
Биллинг-система состоит из пяти демонов
- 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
