Всем привет.
Вобщем есть вдс под управлением дебиан.
Под ним 2 десятка баз данных и столько же сайтов. Базы не маленькие, некоторые больше 1 гб и активно обновляются. Иногда на столько активно что мускулный сервис еле работает а то и вообще падет и ресурсов не хватает даже для nginx.
Собственно появилось желание ограничить пользователей каждой базы определенным процесорным лимитом или лимитом оперативы.
Сам мускул предоставляет возможность сделать лимиты по количеству запросов.
Но запросы не самый удачный вариант, ибо не всегда их количество определяет загрузку сервера.
Есть ли под дебиан спецаильный сервис для лимитированния нагрузки на БД?

miwaonlineforward12Всем привет.
Вобщем есть вдс под управлением дебиан.
Под ним 2 десятка баз данных и столько же сайтов. Базы не маленькие, некоторые больше 1 гб и активно обновляются.

А докупить/проапгрейдить ВДС что мешает?
ресурсов вдс зачастую хватает с головой. Там 24 гб оперативы и проц ай7.
Траблы вызалят иногда, часто это связанно в ошибками кодинга. На сервере ряд самписных движков и другого самописного софта. Ошибки в их кодинге могут скушать ресурсы практически любого вдс :)

vkleforward12Траблы вызалят иногда, часто это связанно в ошибками кодинга. На сервере ряд самписных движков и другого самописного софта. Ошибки в их кодинге могут скушать ресурсы практически любого вдс :)Ошибки наверняка могут приложить не только СУБД. Именно поэтому есть смысл разделять по юникс-пользователям. Каждому - свой лимит ресурсов.
пока смотрю в сторону Cgroups

miwaonlineforward12пропущено...

ресурсов вдс зачастую хватает с головой. Там 24 гб оперативы и проц ай7.
Траблы вызалят иногда, часто это связанно в ошибками кодинга. На сервере ряд самписных движков и другого самописного софта. Ошибки в их кодинге могут скушать ресурсы практически любого вдс :)
С ошибками и нюансами кодинга конечно спорить сложно, но меня в первую очередь волновала бы дисковая подсистема. Пара десятков баз данных с активной работой могуть забить дисковую очередь наглухо и все ваши гигагерцы с гигабайтами будут тупо ждать ответа диска/дисков.

Так что я бы в первую очередь смотрел загрузку по дискам (ну и проц/память тоже, конечно) в момент затыков, а уже потом думал. Но думал бы опять же скорее в сторону железа. Или поиска узких мест в самописном софте.
баги в софте отловили. Но могут появится новые баги, ибо софт развивается и пишут его часто авральными темпами. Касательно вашего замечания о расходе оперативы и нагрузки на винты то это конечно правильно. На сервере стоит atop. И периодически я на него смотрю. Не все я там еще понимаю но документацию изучаю. Еще настроил протоколирование запросов. Каждые 15 секунд читатю список процесов с мускула и сохраняю в лог. Дабы понять кто больше всего одеяло тянят на себя.

bga83forward12Каждые 15 секунд читатю список процесов с мускула и сохраняю в лог. Дабы понять кто больше всего одеяло тянят на себя.
логичнее было бы логировать долго выполняющиеся запросы, с целью анализа их оптимизации
у меня в логах все запросы, а также срок их выполнения и статусы. Разбором полетов заниматся буду.

вобщем пока выручает меня лимит запросов в час, установленный на мускульную базу пробелемного сайта. Который полюбили во всех смыслах слова, ддосеры. Смотрел логи сервера. Атакуют его с 3-5 айпишников и много потоков создают. В общей сложности иногда пару сотен запросов в секунду. Айпишники разных стран Европы и Китая. Хотя сайт тупо на русском, и комерческого интереса для иностранцев не представляет вообще.
Пока баню айпишники и на 2-3 дня это помагает. Иногда на пол дня. Так или иначе теперь другие БД сервера не нагружены, когда проблемная БД выбирает лимит запросов.

VGrey,

спасибо. Сейчас займусь конфигурацией сервера, согласно ваших предложений.

сапорт помог сделать ограничение с помощью модуля mod-evasive.
Посмотрим как будут вести себя досеры.