web-dev-qa-db-ja.com

mysqlのRoundCubeのスリープ接続が多すぎます

これらの詳細が記載されたメールサービスがあります。

    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に増加します。

これはApacheconfです:(Apacheはプリフォークモードで動作します)

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

そしてここにmysqlconfigがあります:

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、mail、mysql)がダウンします。

提案をありがとう。

1

約5年後

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

私のようなJr.システム管理者にとってはとても複雑でした;)

チームメイトがiSCSILUNで準備したGFS2クラスターファイルシステムに問題があり、この問題により、Dovecotとroundcube(およびApache)でさまざまな問題が発生しました。

ちなみに、topコマンドの%waパラメータ(約90%)に注目すると、(おそらく)ファイルシステムレベルに問題があると思いました。

次に、GFSが非推奨になったため、すべてのデータを新しいクラスターファイルシステム(ocfs2)に転送することにしました。

まず、すべてのデータが(ocf2上の)新しいクラスターファイルシステムに移動され、次にdebianwheezyのpacemakehaproxyに基づいてシステム全体が再設計されます。

0

答えは:

Apachemax_clientオプションを編集して値を低くしました256-> 50なぜ!?

(まだ)不明な問題の場合、事前にフォークされたすべてのApacheプロセスのCPU使用率は約100%です(事前にフォークされたApacheプロセスを実行しているコアの100%の使用率が少しの間)

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

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

すべての提案をありがとう。

0