[devel] q: MySQL in 4.0

[devel] q: MySQL in 4.0

[Michael Shigorin]

	Здравствуйте.
Не стоит ли обновить перед выпуском Server 4.0 в алюминии
MySQL до 5.0.41?  Разница между ним и 5.0.37 (более поздним,
чем наличный 5.0.34), включает с дюжину поправленных крэшей
в более-менее редких обстоятельствах.  После выпуска .41 ещё
две мелкие дырки должны были зафиксить, но 5.0.42 не наблюдаю.

Ссылки для удобства:

http://lists.mysql.com/announce/456
http://dev.mysql.com/downloads/mysql/5.0.html#source

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] q: MySQL in 4.0

[Konstantin A. Lepikhov]

<цитата от="Michael Shigorin">
> 	Здравствуйте.
> Не стоит ли обновить перед выпуском Server 4.0 в алюминии
> MySQL до 5.0.41?  Разница между ним и 5.0.37 (более поздним,
> чем наличный 5.0.34), включает с дюжину поправленных крэшей
> в более-менее редких обстоятельствах.  После выпуска .41 ещё
> две мелкие дырки должны были зафиксить, но 5.0.42 не наблюдаю.
>
> Ссылки для удобства:
>
> http://lists.mysql.com/announce/456
> http://dev.mysql.com/downloads/mysql/5.0.html#source
Оно уже собрано и проходит тестирование. Как устроит, залью в Сизиф.

-- 
WBR et al.

Re: [devel] q: MySQL in 4.0

[Andrew Kornilov]

Konstantin A. Lepikhov wrote:
>> Ссылки для удобства:
>>
>> http://lists.mysql.com/announce/456
>> http://dev.mysql.com/downloads/mysql/5.0.html#source
> Оно уже собрано и проходит тестирование. Как устроит, залью в Сизиф.
> 
А можно узнать, почему игнорируется #10941 и зачем это вообще было сделано?

Re: [devel] q: MySQL in 4.0

[Konstantin A. Lepikhov]

<цитата от="Andrew Kornilov">
> Konstantin A. Lepikhov wrote:
>>> Ссылки для удобства:
>>>
>>> http://lists.mysql.com/announce/456
>>> http://dev.mysql.com/downloads/mysql/5.0.html#source
>> Оно уже собрано и проходит тестирование. Как устроит, залью в Сизиф.
>>
> А можно узнать, почему игнорируется #10941 и зачем это вообще было
> сделано?
для того, чтобы DoS на MySQL не убил остальную систему.

-- 
WBR et al.

Re: [devel] q: MySQL in 4.0

[Andrew Kornilov]

Konstantin A. Lepikhov wrote:
>>>
>> А можно узнать, почему игнорируется #10941 и зачем это вообще было
>> сделано?
> для того, чтобы DoS на MySQL не убил остальную систему.
> 
Сам же понимаешь несерьезность аргумента, да и DoS получается
сферический. Это, imho, из разряда security through obscurity. А вот
тормознутость MySQL вполне осязаема :)

Re: [devel] q: MySQL in 4.0

[Eugene Prokopiev]

Konstantin A. Lepikhov пишет:
> <цитата от="Andrew Kornilov">
> 
>>Konstantin A. Lepikhov wrote:
>>
>>>>Ссылки для удобства:
>>>>
>>>>http://lists.mysql.com/announce/456
>>>>http://dev.mysql.com/downloads/mysql/5.0.html#source
>>>
>>>Оно уже собрано и проходит тестирование. Как устроит, залью в Сизиф.
>>>
>>
>>А можно узнать, почему игнорируется #10941 и зачем это вообще было
>>сделано?
> 
> для того, чтобы DoS на MySQL не убил остальную систему.

так вроде предлагается всего лишь вынести возможность "DoS на MySQL" в 
настройки - по мне вполне разумно, у разных пользователей могут быть 
разные приоритеты ...

-- 
С уважением, Прокопьев Евгений

Re: [devel] q: MySQL in 4.0

[Michael Shigorin]

On Thu, May 24, 2007 at 05:22:23PM +0400, Konstantin A. Lepikhov wrote:
> > А можно узнать, почему игнорируется #10941 и зачем это вообще
> > было сделано?
> для того, чтобы DoS на MySQL не убил остальную систему.

Это лучше решать локальному администратору, дефолт-то никто
не просит двигать.

Я вот задумался прикрутить такой регулятор к апачу на одном
хосте, куда повадилась толпа индексаторов...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] q: MySQL in 4.0

[Andrew Kornilov]

Michael Shigorin wrote:
>> > А можно узнать, почему игнорируется #10941 и зачем это вообще
>> > было сделано?
>> для того, чтобы DoS на MySQL не убил остальную систему.
> 
> Это лучше решать локальному администратору, дефолт-то никто
> не просит двигать.

Дефолт я вроде тоже попросил подвинуть. 10 слишком много. Лучше вообще
поставить 0, пусть ядро само решает.
> Я вот задумался прикрутить такой регулятор к апачу на одном
> хосте, куда повадилась толпа индексаторов...
> 
В каких-то случаях оно пригодится. Но делать заведомо медленный сервер
из-за гипотетического DoS тоже не самое верное решение, imho.

Re: [devel] q: MySQL in 4.0

[Konstantin A. Lepikhov]

<цитата от="Andrew Kornilov">
<skip>
> Дефолт я вроде тоже попросил подвинуть. 10 слишком много. Лучше вообще
> поставить 0, пусть ядро само решает.
Многоуважаемый дон является экспертом в DoS и MySQL? ;) Мне не нравится
аргументация "это несерьезно" и "сильно тормозит", приведите пожалуйста
более веские причины того, что устаивало многих несколько лет.

>> Я вот задумался прикрутить такой регулятор к апачу на одном
>> хосте, куда повадилась толпа индексаторов...
>>
> В каких-то случаях оно пригодится. Но делать заведомо медленный сервер
> из-за гипотетического DoS тоже не самое верное решение, imho.
Ситуацию, которую я описал, вполне можно воспроизвести. В случае
приоритетов - гораздо выгоднее поставить MySQL в отдельный контейнер и
крутить для него iopriority.

-- 
WBR et al.

Re: [devel] q: MySQL in 4.0

[Eugene Prokopiev]

> В случае
> приоритетов - гораздо выгоднее поставить MySQL в отдельный контейнер и
> крутить для него iopriority.

man что?

гугл по этому поводу ничего внятного не говорит

-- 
С уважением, Прокопьев Евгений

Re: [devel] q: MySQL in 4.0

[Andrew Kornilov]

Konstantin A. Lepikhov wrote:
>> Дефолт я вроде тоже попросил подвинуть. 10 слишком много. Лучше вообще
>> поставить 0, пусть ядро само решает.
> Многоуважаемый дон является экспертом в DoS и MySQL? ;) Мне не нравится
Скажем так, MySQL-и у меня есть и достаточно нагружены. И когда у
радиуса отрывает крышу от того, что mysql там пыхтит в стороне, мне не
радостно. iowait, кстати, тоже зашкаливает вполне себе. Себе я поменял,
конечно, все приоритеты.
> аргументация "это несерьезно" и "сильно тормозит", приведите пожалуйста
> более веские причины того, что устаивало многих несколько лет.
Нет уж, это вы приведите описание некого DoS, от которого помогает nice
10. Установка nice 10 априори означает работу mysql по остаточному
принципу и экспертом тут быть не обязательно. Давайте тогда уже и sshd
поставим nice 19, это основной сервис, который долбят с утра до ночи :)
А устраивало многих несколько лет скорее всего потому, что этот nice не
виден. Я сам случайно заметил, так смотрел только в колонки CPU/MEM.

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

Re: [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.

Re: [devel] q: MySQL in 4.0

[Konstantin A. Lepikhov]

<цитата от="Eugene Prokopiev">
>> В случае
>> приоритетов - гораздо выгоднее поставить MySQL в отдельный контейнер и
>> крутить для него iopriority.
>
> man что?
>
> гугл по этому поводу ничего внятного не говорит
man vzctl |grep ioprio.

-- 
WBR et al.

Re: [devel] q: MySQL in 4.0

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Fri, May 25, 2007 at 05:58:03PM +0400, Konstantin A. Lepikhov wrote:

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

И все-таки, почему тебя не устраивает вынести эту настройку в sysconfig,
оставив дефолт в 10? Уж извини, но настройка приоритетов это святое право
администратора, ты лишиь его этой возможности.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Настоящие демоны могут так fork'аться, что их потом без pid-файла не
найти.
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] q: MySQL in 4.0

[Michael Shigorin]

On Fri, May 25, 2007 at 12:18:14PM +0400, Konstantin A. Lepikhov wrote:
> > Дефолт я вроде тоже попросил подвинуть. 10 слишком много.
> > Лучше вообще поставить 0, пусть ядро само решает.
> Многоуважаемый дон является экспертом в DoS и MySQL? ;) Мне не
> нравится аргументация "это несерьезно" и "сильно тормозит",
> приведите пожалуйста более веские причины того, что устаивало
> многих несколько лет.

Костик, буду тоже признателен, если ручку сделаешь (порой и для
дёрганья вниз).  Дефолт менять действительно смысла не вижу,
поскольку сам делаю nice 10 apache.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/