Apache 2.2サーバーが応答するまでの待機時間が長い（Gentoo LAMP）

最近、クライアントのウェブサイトを（concrete5 CMSを使用して）Gentoo、Apache 2.2、PHP5、MySQL 5を実行するVPSに移動しました。Apacheの応答時間がかなり悪いことに気付きました（古いサーバーでも同じでした） 、場合によっては最大8〜9秒、多くの場合300ミリ秒から3秒（300ミリ秒までは気にしない）。サーバーは約30ミリ秒の（私の場所からの）pingを送信するため、これはネットワーク遅延ではないことがわかります。

時間の例を次に示します（最初の待機の後で急になっていることがわかります）。

私はAPC（それが正しく機能しているかどうかはわかりませんが ...）とSuExecを実行しています。Apacheモジュールは次のとおりです。

 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 expires_module (static)
 headers_module (static)
 setenvif_module (static)
 version_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 info_module (static)
 suexec_module (static)
 cgi_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 suphp_module (shared)

およびPHPモジュールは次のとおりです。

bcmath
calendar
ctype
curl
db
dbase
domxml
exif
ftp
gd
gettext
iconv
imap
mbstring
mcrypt
mime_magic
mysql
openssl
overload
pcre
posix
session
standard
sysvsem
sysvshm
tokenizer
xml
xslt
zlib

すべての関連ファイルでgzipを有効にしました。

Apacheはpreforkを使用して実行されており、httpd.confの設定は次のとおりです。

<IfModule prefork.c>
StartServers         10
MinSpareServers      10
MaxSpareServers      20
MaxClients           250
MaxRequestsPerChild  4000
</IfModule>

HostnameLookups Off

CMSのダッシュボードのように、データベースが重い（と思う）ページは通常遅いことに気づきました。これは、MySQLを最適化できることを意味しているのではないかと思いました。Apacheモジュールについても疑問に思いました-mod_php5、mod_cgi、mod_fastcgiなどの間で混乱します-使用するのに最適なものについて、ネット全体で矛盾するアドバイスがあります。

MySQLTunerの出力は次のとおりです。

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.44-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 35M (Tables: 161)
[!!] Total fragmented tables: 15

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 21h 44m 16s (293K q [0.868 qps], 1K conn, TX: 135M, RX: 90M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 58.0M global + 1.6M per thread (100 max threads)
[!!] Maximum possible memory usage: 219.7M (93% of installed RAM)
[OK] Slow queries: 0% (0/293K)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/20.9M
[OK] Key buffer hit rate: 99.6% (5M cached / 21K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 3K sorts)
[!!] Temporary tables created on disk: 47% (2K on disk / 5K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 6% (64 open / 1K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (356K immediate / 356K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (>= 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)

DBが重いページが読み込まれると、CPU使用率が57％（topを使用）に急上昇していることに気付きました。この設定を高速化するには、MySQLが不適切に最適化されているか、キャッシングが絶対に必要であることを示唆しています。

どんな助けでも大歓迎です！

Apacheワーカープロセスがハングしているものを正確に知っていますか？これを試してみてください：

mkdir /strace; ps auxw | grep httpd | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r

ブラウザーにいくつかの新しい（つまり、ローカルにキャッシュされていない）ページをロードし、CTRL + Cでstraceを停止してから、各呼び出しに費やした時間でstrace.logsをソートします。

for i in `ls /strace/*`; do echo $i; cat $i | cut -c11-17 | sort -rn | head; done

1.0秒を超える呼び出しでstrace.logsを表示し、前のコマンドの出力から時間で検索します。これは、彼らがハングしている正確なステップを示します。

変更によって、CSFのようなファイアウォールがインストールされていますか？VPSでも同じ問題が発生しました。straceを使用してhttpdプロセスをデバッグする場合、gettimeofday呼び出しで最大5秒以上かかりました。奇妙なことに、これをCSFに絞り込みました。CSFは、OpenVZまたはVirtuozzoコンテナのループバックインターフェイスであるvenet0インターフェイスをフィルタリングしようとしていました。/etc/csf/csf.confでこのパラメーターを設定すると、ほとんどの場合それが修正されました。

"ETH_DEVICE_SKIP = "venet0,lo"

主に言っているのは、接続が確立するまで500〜1000ミリ秒待機する場合があるが、5000以上からは大幅に改善されるためです。

以下は、 straceを使用してこれらの種類の問題をトラブルシューティングするための優れた入門書です。

Maximum possible memory usage: 219.7M (93% of installed RAM)

これはローエンドのVPSボックスである必要がありますか？

• MySQLの設定をダイヤルダウンすることをお勧めします
• Apacheを調整してhttpdフォークの数を減らす
• スワッピングを有効にできるかどうかを確認します
• APCはオペコードを自動的にキャッシュするように設定されていますか？apcで配布されている 'apc.php'スクリプトを使用して確認します。

レイテンシの原因として、ネットワーク、Apache、mysql、phpを切り離す必要があります。

Apacheから画像をすばやく（最初のバイトまでの時間が非常に短い）プルできる場合、ネットワークとApacheは通常問題ありません。

phpinfo（）ステートメントだけでページをプルできる場合、通常はPHPで問題ありません（いくつかの調整が必要になる場合があります）。

単純なDB接続テストを作成し、それが高速であれば、その層も通常は問題ありません。

最後に、アプリケーションページをプルします。遅い場合、問題はアプリケーション処理の内部にあります。チューニングは役立つかもしれませんが、これは解決するのがはるかに困難です。

アプリケーションをプロファイリングしないと、問題を見つけるのが難しい場合があります。NewRelicのようなツールはこの問題を解決できますが、解決策ではありません。

アプリには、時間が費やされている場所を示す内部デバッグのタイプがありますか？

レンダリング時間の測定を追加し、サーバーが純粋なHTMLページをレンダリングするのにかかる時間を確認することをお勧めします。次に、それがCMSまたは他の場所にあるかどうかを確認します。私の2セントはサーバーの設定ではないと思います。/ maddin