[devel] q: MySQL in 4.0

[Konstantin A. Lepikhov]

<цитата от="Andrew Kornilov">
> Konstantin A. Lepikhov wrote:
>>> Дефолт я вроде тоже попросил подвинуть. 10 слишком много. Лучше вообще
>>> поставить 0, пусть ядро само решает.
>> Многоуважаемый дон является экспертом в DoS и MySQL? ;) Мне не нравится
> Скажем так, MySQL-и у меня есть и достаточно нагружены. И когда у
> радиуса отрывает крышу от того, что mysql там пыхтит в стороне, мне не
> радостно. iowait, кстати, тоже зашкаливает вполне себе. Себе я поменял,
> конечно, все приоритеты.
вот поэтому iowait у вас и зашкаливает. А что "у raidus'а отрывает крышу"
- это скорее отрывает крышу у авторизатора, поскольку raidus как протокол
никак с mysql не связан и задержки нам предусмотрены.

>> аргументация "это несерьезно" и "сильно тормозит", приведите пожалуйста
>> более веские причины того, что устаивало многих несколько лет.
> Нет уж, это вы приведите описание некого DoS, от которого помогает nice
> 10. Установка nice 10 априори означает работу mysql по остаточному
> принципу и экспертом тут быть не обязательно. Давайте тогда уже и sshd
это вынужденная мера, поскольку неправильно работающий mysql с выкрученным
приоритетом вполне может убить систему. И вообще, MySQL в нашей сборке -
это такой придаток для хранения, типа записной книжки с regexp ;) Вот если
осилю сборку MySQL-Max (что сделать все-таки придется), тогда можно
подумать в этом направлении.

> поставим nice 19, это основной сервис, который долбят с утра до ночи :)
> А устраивало многих несколько лет скорее всего потому, что этот nice не
> виден. Я сам случайно заметил, так смотрел только в колонки CPU/MEM.
>
т.е. у всех использовалось что-то иное, чем LAM, и они с этой проблемой не
сталкивались?

>>>> Я вот задумался прикрутить такой регулятор к апачу на одном
>>>> хосте, куда повадилась толпа индексаторов...
>>>>
>>> В каких-то случаях оно пригодится. Но делать заведомо медленный сервер
>>> из-за гипотетического DoS тоже не самое верное решение, imho.
>> Ситуацию, которую я описал, вполне можно воспроизвести. В случае
>> приоритетов - гораздо выгоднее поставить MySQL в отдельный контейнер и
>> крутить для него iopriority.
> Тут быстрее какие-нибудь apache+php убьют систему, а не mysql. В общем,
> решайте сами. Сделайте хотя бы крутилку в sysconfig, чтобы не нужно было
> на каждом сервере патчить скрипты :)
Почему для apache+php вас не смущает поставить reverse proxy, а вот для
MySQL такая мысль не приходит? Это при том, что в MySQL средства
разграничения нагрузки на порядок продуманнее и удобнее (например, даже
такой топорный вариант как в bugzilla - 2 сервера, один работает только на
чтение, другой на запись).

-- 
WBR et al.