RoundCube の MySQL でのスリープ接続が多すぎる

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 のスリープ接続が 10 分以内に 1、2、または 3 から 270 に増加し、そのピーク時に 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 を超えると、ほとんどのサービス (Web、メール、mysql) が停止します。

ご提案があればよろしくお願いします。

答え1

答えは:

Apache max_client オプションを編集して値を 256 --> 50 に下げました。なぜですか?

(まだ) 不明な問題として、すべての prefork された Apache プロセスが CPU 使用率を約 100% 占めます (prefork された Apache プロセスを実行しているコアの使用率が数分間 100% になります)

システムはダウンします。システムには 64 個の CPU コアがあり、Apache の 256 個のプロセスすべてが CPU 使用率を 100% 使用すると、システムとサービスがダウンします。

問題はまだ存在しますが、サービスに問題はありません。問題はネットワーク攻撃に関連していると思います(監視ツールは1日に多くの攻撃を報告しています)。これにより、リソースのロックなどの問題が発生することがあります。

全てのご提案に感謝します。

答え2

約5年後

問題は数日で検出され解決されました。

私のようなジュニアシステム管理者にとっては非常に複雑でした ;)

私のチームメイトが iSCSI LUN 上に準備した GFS2 クラスター ファイル システムに問題があり、この問題により Dovecot と roundcube (そして apache) でさまざまな問題が発生しました。

ご参考までに、top コマンドの %wa パラメータに注目すると (約 90%)、ファイルシステム レベルで問題があるのではないかと思いました。

その後、GFS は廃止されたため、すべてのデータを新しいクラスター ファイル システム (ocfs2) に転送することにしました。

まず、すべてのデータを新しいクラスター ファイル システム (ocf2 上) に移動し、次に debian wheezy 上の pacemake haproxy に基づいてシステム全体を再設計しました。

関連情報