Какие таймауты нужны mysql, что бы apache не уходил в swap.

[ivankin]

Какие таймауты нужны mysql, что бы apache не уходил в swap.

Проект на 20 000 хостов в день и 300 000 хитов. Нагрузка на mysql - 150 запросов в секунду. Оперативная память - 2Гб.
Основные таблицы - около 200К записей. В день 2К инсертов и апдейтов.

При пиковой нагрузке происходит следующее - mysql занимает 30%, остальное занимает apache, потом apache сваливается в swap. При этом в mysql в процессах с сотню select со временем выполнения 30-300 секунд и парочка insert|update, которые это все залочили.

В настройках mysql стоит
max_connections=300
net_read_timeout=12
net_write_timeout=20
wait_timeout=30
interactive_timeout=30

Вопрос. Почему mysql ждет эти запросы и выстраивает apache в очередь, а не возвращает ошибку?

 

[Alexandre]

нагрузка не большая
база небольшая
.

Нагрузка на mysql - 150 запросов в секунду

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

вообще, надо избавляться от апача, либо ставить фронт-сервер или прокси

 

[Gas]

ivankin
так известна первопричина? 1) сначала идёт _сложный insert/update_ который лочит на долго таблицу(ы), а за ним выстраиваются чередой апачи с php, которые ждут окончания запроса и не влезают в память; 2) большое количество одновременных запросов, php не успевает генерить страницы, накапливается очередь апачей которые падают в swap, в это время проскакивает _простой insert/update_ который из-за общих тормозов системы долго выполняется и добивает локом всё ?

Если первый вариант и запросы модификации данных затрагивают относительно небольшой объём записей - можно попробовать сменить engine на innodb, всё таки row level locking.
Общие советы: заменить apache на nginx или lighttpd (потребление памяти должно сократиться), оптимизировать скрипты и запросы, добавить кеширования. Посещаемость не персональной странички, можно уже и отдельный сервер под базу поставить.

 

[ivankin]

Автор оригинала: Gas
ivankin
так известна первопричина? 1) сначала идёт _сложный insert/update_ который лочит на долго таблицу(ы), а за ним выстраиваются чередой апачи с php, которые ждут окончания запроса и не влезают в память; 2) большое количество одновременных запросов, php не успевает генерить страницы, накапливается очередь апачей которые падают в swap, в это время проскакивает _простой insert/update_ который из-за общих тормозов системы долго выполняется и добивает локом всё ?

Если смотреть на processlist - то скорее второй вариант.

Понятно, как дальше масштабировать проект. Но непонятно, что сейчас происходит - почему php ждет эти запросы, не обрываясь max_execution_time и не получая от mysql ошибки.

Пусть бы часть пользователей получала 500 ошибку. но не убивала бы сервер.

 

[Alexandre]

Пусть бы часть пользователей получала 500 ошибку. но не убивала бы сервер.

тоже не выход