☰

RoundCube слишком много спящих соединений в MySQL

tag-icon • tag-icon mysql httpd roundcube
RoundCube слишком много спящих соединений в MySQL

у нас есть почтовая служба со следующими данными:

    1-Centos 6.4
    2:Postfix 2.6.6
    3:roundcube 0.8 
    4:dovecot 2.0.9.7
    5:mysql-server 5.1.71

все в порядке, но в часы пик количество спящих соединений RoundCube увеличивается с 1, 2 или 3 до 270 менее чем за 10 минут, а количество открытых файлов Apache (измеренное с помощью lsof) увеличивается с 4000 до 20000 в это же время пик.

это apache conf: (apache работает в режиме prefork)

PidFile run/httpd.pid
Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>
TraceEnable off
LimitRequestLine 1024
LimitRequestFields 100
LimitRequestFieldsize 1024
LimitRequestBody 10241024

а вот конфиг mysql:

secure_auth=1
local_infile=0
max_connections        = 600
max_allowed_packet    = 16M
key_buffer        =256M
wait_timeout=240
interactive_timeout=180
connect_timeout=10
innodb_buffer_pool_size=2G

когда количество неактивных соединений RoundCube увеличивается до >100, большинство служб (веб, почта, MySQL) выходят из строя...

спасибо за любые предложения.

решение1

Ответ:

Я изменил параметр Apache max_client, уменьшив значение с 256 до 50. Почему!?

из-за (все еще) неизвестной проблемы все предварительно созданные процессы Apache потребляют около 100% загрузки ЦП (100% использование того ядра, на котором запущен предварительно созданный процесс Apache в течение нескольких мгновений)

Итак, система выходит из строя, поскольку в системе 64 ядра ЦП, когда все 256 процессов Apache используют 100% ЦП, система и службы выходят из строя.

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

спасибо за все предложения.

решение2

Сейчас

Примерно через 5 лет

Проблема была обнаружена и решена в течение нескольких дней.

Это было так сложно для меня, младшего системного администратора ;)

Возникла проблема в кластерной файловой системе GFS2, которую мой коллега подготовил на iSCSI LUN, и эта проблема привела к различным проблемам в Dovecot и Roundcube (а затем и в Apache).

для вашего сведения, когда я обратил внимание на параметр %wa в команде top (он был около 90%), я подумал (возможно), что проблема на уровне файловой системы.

Затем я решил перенести все данные в новую кластерную файловую систему (ocfs2), поскольку GFS устарела!

Прежде всего, все данные перемещены в новую кластерную файловую систему (на ocf2), затем перепроектирована вся система на основе pacemake haproxy на Debian wheezy!

Связанный контент