Решение проблем с ядром - История изменений

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

2011-09-26T08:55:31Z

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

Admin в 08:00, 23 сентября 2011

2011-09-23T08:00:07Z

Admin в 07:49, 23 сентября 2011

2011-09-23T07:49:03Z

217.64.134.182: Новая страница: «jjjjjjjjjjjjjjjjjjj»

2011-06-25T13:57:10Z

Новая страница: «jjjjjjjjjjjjjjjjjjj»

Новая страница

jjjjjjjjjjjjjjjjjjj

@@ Строка 1: / Строка 1: @@
-== Поиск и решение проблем в работе ядра биллинговой системы ==
+= Поиск и решение проблем в работе ядра биллинговой системы =
 Биллинг-система состоит из пяти демонов
 * core
@@ Строка 34: / Строка 34: @@
 root     11067  0.2  0.7 129212 16188 ?        Sl   Sep20  11:40 /opt/ebs/data/rad
 </pre>
 == Потребление ресурсов ==

@@ Строка 1: / Строка 1: @@
 == Поиск и решение проблем в работе ядра биллинговой системы ==
-Биллинг-система состоит из пяти демонов и скриптов. В нормальном состоянии все 5 демонов должны быть запущены и команда top должна выдавать что-то типа этого:
+Биллинг-система состоит из пяти демонов
 <pre>
 top - 10:21:15 up 25 days,  2:18,  4 users,  load average: 0.08, 0.06, 0.00

← Предыдущая		Версия 07:49, 23 сентября 2011
Строка 1:		Строка 1:
−	~~jjjjjjjjjjjjjjjjjjj~~	+	== Поиск и решение проблем в работе ядра биллинговой системы ==
		+	Биллинг-система состоит из пяти демонов и скриптов. В нормальном состоянии все 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>
		+
		+	== Потребление ресурсов ==
		+	В нормальном рабочем состоянии потребление памяти процессами биллинга может в норме доходить до 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>