Всё чаще и чаще в 12 часов ночи начинается одно и то же, админка еле-еле ворочается, невозможно ничего сделать, урфаклиент не цепляется. В базе около 18к аккаунтов, подавляющее большинство из них имеет суточные расчётные периоды со списаниями в конце РП.
Что можно подкрутить, чтобы ядро зашевелилось бодрее? Во что оно может упираться?
Версия 5.2.1-007, Центос5 32 бита. Из железа два Xeon E5506, 8ГБ оперативы (планируется установка 64-битной системы с расширением памяти, чтобы отдать мускулу побольше).
В конфиге стоит dbcount=30, dbcount_sys=30
Оптимизация параметров ядра
Re: Оптимизация параметров ядра
Вы бы сначала посмотрели что является причиной:Витька писал(а):Всё чаще и чаще в 12 часов ночи начинается одно и то же, админка еле-еле ворочается, невозможно ничего сделать, урфаклиент не цепляется. В базе около 18к аккаунтов, подавляющее
В конфиге стоит dbcount=30, dbcount_sys=30
ядру ли памяти не хватает и оно конкурирует с базой, или в базе что не так, например включить Slow Query Log, в случае с mysql.
Хотя 18к списаний будут хорошо грузить и базу и utm_core.
но повлиять кардинально вы сможете, наверное, только на базу.
Возможно cpu affinity и оптимизация нужных индексов вам помогут.
Если не ошибаюсь, у Magnum72 более 30к клиентов, так что шансы есть.
Такая же ситуация. 2.5к клиентов при наступление окончания расчетного периода (начало следующего месяца), в течении одного дня не возможно принимать платежи с терминалов по osmp, админка временами подвисает. В логах одни таймауты по платежам. Версия биллинга 5.2.1–008 update 6, такое же также наблюдалось и на 5.2.1–007.
Ядро БД разнесены на разные машины. БД загружен на 5% (FreeBSD 7.2 64bit, 16GB ОЗУ, два процессора Xeon), Ядро загружено на 10-15% (FreeSD 8.1 32it, 4GB ОЗУ, Core 2 Quad 3.00GHz)
Ядро БД разнесены на разные машины. БД загружен на 5% (FreeBSD 7.2 64bit, 16GB ОЗУ, два процессора Xeon), Ядро загружено на 10-15% (FreeSD 8.1 32it, 4GB ОЗУ, Core 2 Quad 3.00GHz)
У меня немного глупый вопрос. А как делать explain update в мускуле?Magnum72 писал(а):2 lexab: около 100000.
На самом деле все сводится к оптимизации баз данных, это вынос в архивные таблицы не актуальные данные, и построение индексов.
Как строить индексы: открываем дебаг лог во время списания, смотрим часто повторяющиеся запросы и пытаемся их оптимизировать применяя индексы.
Писать аналогичный селект?Да.Витька писал(а):У меня немного глупый вопрос. А как делать explain update в мускуле?
С такой нагрузкой легко справлялся старенький сервер с 4Гб памяти, РП закрывался 10-15 минут. Может дисковая система не поспевает?CarTer писал(а):2.5к клиентов при наступление окончания расчетного периода (начало следующего месяца)
Вот и странно то, что в течении одного дня вся система подтупливает. Особенно заметно на приеме платежей через osmp -- они вообще не проходят.С такой нагрузкой легко справлялся старенький сервер с 4Гб памяти, РП закрывался 10-15 минут.
Теоретически должна быть в норме, стоят sas винты на 14к оборотов.Может дисковая система не поспевает?
Вот что сейчас:
iostat -d -w1 -c7
aacd0 pass0 pass1 pass2
KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s
16.80 25 0.42 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
16.00 5 0.08 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
16.00 4 0.06 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
16.00 265 4.14 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
16.00 2 0.03 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
16.00 4 0.06 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
16.00 4 0.06 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00
vmstat
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr aa0 pa0 in sy cs us sy id
0 0 0 8938M 774M 6 0 0 0 7 7 0 0 108 83 43 0 0 100