mysqld низкоуровневая проблема (нужен хороший спец)

у меня была проблема с nginx, он съедал всю память и процессор, он этого мускул писал великий slow query log, и даже падал. При этом в лог были записаны простые запросы, которые немогли сами так грузить БД.

nginx 0.6 версии плохо работает с панелью ISPMananger Pro. Помогло обновление до самой новой стабильной версии.

возможно что-то аналогичное у вас происходит

Забыл добавить - проблемная машина - физически отдельный бд сервер без панели

dantess, поставить диагноз по вашему описанию непросто, пациента необходимо видеть, пощупать.

Из общих рекомендаций:

Поставить MySQL серверы на всесторонний мониторинг - от параметров работы дисковой подсистемы до сетевого стека операционной системы. И смотреть цифры и графики в периоды проблем.

Просмотреть my.cnf на предмет вменяемости.

Просмотреть slow_log, включить логгирование всех запросов, посмотреть, что происходит в проблемные периоды. Просмотреть, какой пользователь и БД наиболее активны. Возможно, включить ограничения на соединениям или т.п.

Проверить настройки ОС на предмет вменяемости.

Вполне возможно, что какая-то блокировка таблиц (смотрите выдачу show processlist от MySQL рута), вариант увеличить максимальное число коннектов не подойдет http://phpsuxx.blogspot.com/2009/12/got-error-1040-too-many-connections.html ? Также есть вариант, что MySQL упирается в лимит числа открытых файлов: http://phpsuxx.blogspot.com/2010/01/mysql-openfileslimit.html

Если честно, я что-то в небольшом шоке от того, что написано по этой ссылке.

Я думаю, что это может дать совершенно обратный эффект. У ТС очередь останавливается на одном количестве коннектов, а тут ещё и до дикого количества может дойти. Потом либо упадёт всё, либо mysql может не выйти из ступора.

пощупать можно через админа - icq 2023149 - сделает все что нужно.

пользователь бд ничего не скажет - грубо говоря он один - его юзают все проекты (ну если грубо).

По кол-ву соединений - лимит 450.

Админ успел засечь 290 в проблемный момент (проблема кратковременная 2-3 мин по ощущениям, но очень противная)

В запросах ничего криминального нет - все те же запросы что и в остальное время в течении суток (возможно, на первый взгляд).

ОС настроена вменяемо (какие настройки нужно озвучить - озвучу).

конфиг бд вот:

[mysqld]
port            = 3306
socket          = /var/db/mysql/mysql.sock
bind-address    = 192.168.0.2
default-character-set = cp1251
init-connect="SET NAMES cp1251"
skip-locking
concurrent_insert=2
open_files_limit = 45000
key_buffer = 384M
max_allowed_packet = 1M
sort_buffer_size = 8M
read_buffer_size = 8M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 64
query_cache_size = 2048M
query_cache_limit = 4M
query_cache_min_res_unit = 512
tmp_table_size = 512M
max_heap_table_size = 512M
table_cache = 6000
max_tmp_tables = 64
max_connections = 450
max_join_size = 100000000
max_sort_length = 20
interactive_timeout = 600
wait_timeout = 90
thread_concurrency = 24
log_error = /var/log/mysql-err.log
long_query_time = 1
log-slow-queries = /var/log/mysql-slow.log
binlog_format=MIXED
log-bin= /var/db/mysql/mysql-bin.log
relay-log = /var/db/mysql/slave-relay.log
relay-log-index = /var/db/mysql/slave-relay-log.index
expire_logs_days        = 10
max_binlog_size         = 500M
server-id       = 2
master-host=192.168.0.1
master-user=..........
master-password=............
master-port=3306
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 2
innodb_buffer_pool_size=512M
innodb_additional_mem_pool_size=30M

Вы пишите, что на сервере: «порядка 50 высоконагруженных вебпроектов»

Я бы в этой ситуации перенес часть проектов на другой сервер и посмотрел бы на коком сервере бы возникала проблема.

Таким образом сузил бы круг поиска проблемы и выяснил какой именно проект вызывает проблему.

Перенес бы проблемный проект на отдельный сервер.

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

попробуйте поменять реплику с мастером поменяйте местами...

проекты очень сильно взаимосвязаны, особенно по бд.

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

при беглом просмотре в запросах никакой клинике не обнаруживается - все запросы в обычных условиях очень быстро отрабатывают.

на реплику никак не завязано (и на ОС - тоже) - проблема возникала и до введения репликации совсем на другой ОС (CentOs)

Что-то схожее было, методом разносторонних комбинаций решилось, решения не было однозначного.

mysqltuner не пробовали? как вариант для гармонизации и исключения момента кривых настроек my.cnf, на пути решения проблемы как таковой?

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

Удачи в решении