Прожорливое ядро

hammer · Сообщение **hammer** » Пт июл 18, 2008 14:08

5.2.1-004

Уважаемые дамы и господа! Причиной данного топика послужило прожорливое ядро и непродуманность, при написании биллинга и работе его с памятью. А говарю я щас именно о старом мазоле UTM5 - отчеты. Да да, те самые пресловутые отчеты потрафику за расчетный период.
Итак ситуация - в день со шлюзов льет примерно инфы о 50Гб и более трафика (вся информация о трафике необходима!).
На отдельном серваке с ядром стоит Pentium D 2.5 Ггц, 2 Гб ОЗУ. FreeBSD 6.2 RELEASE i386.
Ядро собрано с опциями

Код: Выделить всё

options         MAXDSIZ="&#40;1500*1024*1024&#41;" # Max memory for process              
options         MAXSSIZ="&#40;1500*1024*1024&#41;"                                       
options         DFLDSIZ="&#40;1500*1024*1024&#41;" # Default memory for process

Ну соотвесвенно при попытке формирования отчетов за месяц, скажем, с сервера мускуля приходит слишком много инфы (а нельзя ли тут было сделать, чтобы ядро пополучению новой партии данных от СУБД, результировало предыдущие данные и конконтинировало со следующей партией данных или отдать эту работу СУБД и грамотнее составить запросы... не ну это конечно алес полный, то что видно при данной работе ядра, когда "само все получаю, гружу в память до одурения, потом разгребаю что получило, если в кору не вылетаю") все это барахло грузиться в память и при привышенийй 1.5 Гб занятого ОЗУ, наше ядро благополучно высывается в utm5.core.core. КОнечно ещ планку на 1 Гб подторнуть и поднять планку с 1500 до максимума в 2000 - это самой сабой, но, как понятно, более чем временное решение проблеммы. ЧТо делать товарищи? Переходить на ядра FreeBSD amd64 или IA64 (со сменой железа само сабой -) )? Предположим либы 32-х битные перенесу, но как там с памятью, выделяемой на процесс? Нужны ли какие нибудь такого плана опции ядра или данные ограничения справдливы только для i386 и смена архитектуры сервера для ядра биллинга ответ на все вопросы?

ЗЫ Оптимизацию делаю сам, отрезая данные и складываю в архивную таблицу - а вообщем оптимизацию произвожу из админки, предварительно сделав бекап и контрольные отчеты, для сверки "до и после", но все равно при таком темпе роста базы, данных продцедур хватает для стабильной работы биллинга меньше чем на месяц.

amix · Сообщение **amix** » Пт июл 18, 2008 14:15

Как я писал в пред. теме очень советую обновить ядро до 006 версии.
у меня после обновления ядро стало жрать примерно в 10 раз меньше памяти.
+ цена планок сейчас смешная, я бы добил до 4х гб, и увеличил память на процесс до 2.5Г

hammer · Сообщение **hammer** » Пт июл 18, 2008 14:19

Сразу могу сказать, что перезда на 006 ждал пол-года! Теперь уже, база от 004, мало похожа на дефолтную (добавлены триггеры, таблицы, индексы... ), написано для биллинга столько и доделано, что от самого UTM там отсалось неизмененным только ядро.. и проблеммы только с ним, так что я затрудняюсь сказать, каково это теперь конвертирволать базу с 004 на 006 и что из этого получится. Если есть подробные данные о том какие таблицы и в какой мере затрагиваются, то дайте такую информация, посмотрю, может и сможем переехать на 006.

ЗЫ Написали свой биллинг, он заточен полностью под процессы организации, и почти доведен до идеала. После его внедрения в бой, планируется использовать UTM, как биллинг "для лицензии", но по любому придется. Так что вот сетую вам на такую проблемму.

hammer · Сообщение **hammer** » Пт июл 18, 2008 14:25

amix писал(а):..я бы добил до 4х гб, и увеличил память на процесс до 2.5Г и увеличил память на процесс до 2.5Г

Для AMD максимальный параметр 2048 а для Intel собирается с потолком в 2000 =). К тому же больше 3.5 Гб для Фряхи i386 потолок (ну без PAE). При 4 Гб+ начинается сильное уменьшение производительности. А с включеным PAE наблюдается непригодность FreeBSD, как операционной системы, для эксплуатации -))).

amix · Сообщение **amix** » Пт июл 18, 2008 14:33

hammer писал(а): Для AMD максимальный параметр 2048 а для Intel собирается с потолком в 2000 =). К тому же больше 3.5 Гб для Фряхи i386 потолок (ну без PAE). При 4 Гб+ начинается сильное уменьшение производительности. А с включеным PAE наблюдается непригодность FreeBSD, как операционной системы, для эксплуатации -))).

Вот , позволю себе опровергнуть ваше утверждение.

>cat /var/run/dmesg.boot | grep CPU
CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU)
Logical CPUs per core: 2
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
p4tcc1: <CPU Frequency Thermal Control> on cpu1
SMP: AP CPU #1 Launched!

>limits -H
Resource limits (current):
cputime infinity secs
filesize infinity kB
datasize 2621440 kB
stacksize 2621440 kB
coredumpsize infinity kB
memoryuse infinity kB
memorylocked infinity kB
maxprocesses 5547
openfiles 11095
sbsize infinity bytes
vmemoryuse infinity kB

hammer писал(а):Если есть подробные данные о том какие таблицы и в какой мере затрагиваются, то дайте такую информация, посмотрю, может и сможем переехать на 006.

В дистрибе ж есть sql скрипт в котором все изменения структуры базы.

hammer · Сообщение **hammer** » Сб июл 19, 2008 20:33

1 - это ничего что Xeon имеет архитектуру IA64? Попробуйте собрать ядро с параметром в 2500 хотя бы на i386 - получите сообщение "variable overload"... Это все что мне надо узнать, что на архитектура IA64 таких ограничений нет. (см. выше впорос).

2 - про скрипт я вообще то знаю, ещё от времен с экпериментами от 005, там аналогичная поделка - но свои заключения переносить на рабочкую базу о безопасности изменения структуры для остальных приложений, не особо хочется.
Переснтанет адекватно работать личный кабинети отчеты, а так же различные вещи типа смены тарифов и обещанных платежей и целая куча разного фукционала. Пересанет работать CRM по связке DHCP и свичей DLINK, а так же служащая для первоначального включения абонентов в сеть и занос в систему разных параметров... Перестанут рабоать скрипты контроля доступа и скрипт оптимизаии придется пределывать.. а оптимизация в конечном итоге, получается сходная с той которая реализована в 006. Вобщем так - если у вас пара сотен пользователей и утсановлен голый биллинг на тазике, то можно конечно экперементировать... а когда это уже отлаженная большая система, то менять в ней как то ничего не хочется, ибо придется менять и переисывать абсолютно все - поэтому для работы и был написан собсвенный биллинг.

mikkey finn

чота мне кажецо, что у господина Хаммера каша в голове из архитектур...
Биллинг под IA64 не писался никогда =) серьезно. Да и не найдется дурака, у которого есть деньги на Itanium2 и нет денег на "написать и сертифицировать свое".
Что насчет лимитов на процесс...

Код: Выделить всё

hw.machine&#58; i386
hw.model&#58; Intel&#40;R&#41; Pentium&#40;R&#41; D  CPU 2.66GHz
hw.ncpu&#58; 2
hw.byteorder&#58; 1234
hw.physmem&#58; 2120634368
hw.usermem&#58; 1917337600
hw.pagesize&#58; 4096
hw.floatingpoint&#58; 1
hw.machine_arch&#58; i386
hw.realmem&#58; 2129592320

MAXDSIZ нельзя ставить больше чем hw.physmem
Данный sysctl взят с тазика с 2Г ОЗУ.
Если на тазике стояло бы больше, что можно было бы больше ставить. Причем не обячзательно пересобирать ведро. достаточно засунуть строку в loader.conf
http://usunet.ru/forum/index.php?showtopic=2220
Ну и про распределение памяти во фре:
http://docs.freebsd.org/cgi/getmsg.cgi? ... sd-hackers
Да, кстати, ведро собрано с опцией MAXDSIZ=2*1000*1000*1000
Есть ощущение, что если добавить память, то через лоадер можно и больше воткнуть.