Потоки MYSQL безбожно жрут память

[tony2001]

>помнится на RH можно было включать threads view.
ты уверен, что там его *выключать* можно?
насколько я помню, там как раз нет выбора.

 

[betik]

Автор оригинала: admin
Какой лимит? У тебя хостинг за 5$ чтоли?

Я уже предложил разделить этот процесс...
При таком раскладе получается слегка асинхронный,
но работающий процесс...
1 - фетчер
2 - сокет демон
3 - бд упдатер

У меня доступ к серверу без рут-прав.
Админ мудак, простите. Сказал заказчику, что при снятии ограничения на одновременные потоки может загореться винчестер. а заказчик - юрист...
Он как бы верит свято. (можно в хумор сразу)
Да и спорить и доказывать я ничего им не хочу...

Просто мне самому интересно... Как это можно ограничить... А то что можно разделить - это понятно... В общем-то я бы и разделил и нашёл бы решение с созданием временных файлов и апдейтом раз в час "технологическую минуту"... Но делать бесплатно и не для себя - нет никакого желания...

На счёт top - почитал я wht...
Насколько сумел понять - top в RH линуксе (как минимум) считает что потоки и процессы - это одно и тоже... в freeBSD и openBSD такого нет...
Но у меня, видимо, именно процессы - одновременно работают несколько демонов, каждый из которых соединяется с базой...

Короче, потоки это или процессы - не знаю, но память жрут, каждый по 12 МБ. Когда она кончается они начинают её стрёмно делить... у некоторых остаётся по 12, а у некоторых по 0,12...
ps -A | grep mysqld показывает тех же, которых показывает топ.

 

[tony2001]

исходя из того, что это всё-таки потоки, а не процессы, беспокоиться тебе не о чем.

 

[betik]

Тони, а кто ест память?
Сервер реально тормозит при запуске...

 

[Screjet]

betik
Потоки все работают в одном адресном пространстве, когда ты делаешь коннект к БД ты видишь новый поток, естественно ресурсы потребления памяти у потока такие же как у процесса.

Кстати во фряхе, начиная с пятерки так же можно наблюдать потоки топом.

зы. Незабудь сисадмину дать почитать тред

 

[betik]

Screjet, тогда я непонимаю...
Если в топе 10 mysqld по 12МБ каждый, то на деле всего откусывается не 10x12Мб памяти, а всего 1x12?

Почему тогда топовский монитор показывает, что память откусывается от общей? Было 512 стало 512 - 10x12... Или это он чвоими какими-то мерками считает, так же как и потоки?
Но почему тогда сервер тормозит сразу... Реально видно как он тормозит...

 

[Screjet]

betik
Значит, твой mysql работает на fork'ах
Это очень похоже на то, как в бсд работает муська на linuxthreads.

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

Более точные ответы на твои вопросы нужно искать на сисадминских форумах.

 

[betik]

С сисадминами на форумах общаться, что палкой по лбу себя лупить... На наших форумах во всяком случае.
Знакомый сисадмин сказал что мускул вообще глючное... и что лучше вместо мукула и пхп на сервер порнухи закачать побольше - толку больше =\...

ЗЫ - дал ссылку на топик заказчику... посмотрим что будет.

 

[slach]

delay_key_write ON
означает, что у тебя индексы сидят в памяти пока идет update и insert, дальше заданы таймауты
по идее это увеличивает скорость, но в твоем случае может действительно жрет память

join_buffer_size 131072
key_buffer_size 8388600
8 метров на индексы
и 130 кб на JOIN
я бы лучше увеличил join_buffer_size
до пары метров

max_connections 100
ну в принципе нормально

max_join_size 4294967295
может и многовато ... но по моему это отношения к памяти не имеет

вот все что заслуживает внимания
может имеет смысл это все потвикать через my.cnf
поглядеть на результат

 

[betik]

tnx, сёдня попробую