最近、クライアントのウェブサイトを(concrete5 CMSを使用して)Gentoo、Apache 2.2、PHP5、MySQL 5を実行するVPSに移動しました。Apacheの応答時間がかなり悪いことに気付きました(古いサーバーでも同じでした) 、場合によっては最大8〜9秒、多くの場合300ミリ秒から3秒(300ミリ秒までは気にしない)。サーバーのpingが(私の場所から)約30msであるため、これはネットワーク遅延ではないことがわかります。
時間の例を次に示します(最初の待機の後で急になっていることがわかります)。
私は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を使用してこれらの種類の問題をトラブルシューティングするためのexcellentプライマー/ウォークスルー を以下に示します。
Maximum possible memory usage: 219.7M (93% of installed RAM)
これはローエンドVPSボックスである必要がありますか?
レイテンシの原因として、ネットワーク、Apache、mysql、phpを分離する必要があります。
Apacheからイメージをすばやく(最初のバイトまでの時間が非常に短い)プルできる場合、ネットワークとApacheは通常問題ありません。
Phpinfo()ステートメントだけでページをプルできる場合、通常はPHPで問題ありません(いくつかの調整が必要になる場合があります)。
単純なDB接続テストを作成し、それが高速である場合、その層も通常は問題ありません。
最後に、アプリケーションページをプルします。遅い場合、問題はアプリケーション処理の内部にあります。チューニングは役立つかもしれませんが、これは解決するのがはるかに困難です。
アプリケーションをプロファイリングしないと、問題を見つけるのが難しい場合があります。 NewRelicのようなツールはこの問題を解決できますが、解決策ではありません。
アプリには、時間が費やされている場所を示す内部デバッグのタイプがありますか?
レンダリング時間の測定を追加し、サーバーが純粋なHTMLページをレンダリングするのにかかる時間を確認することをお勧めします。次に、それがCMSまたは他の場所にあるかどうかを確認します。私の2セントはサーバーの設定ではないと思います。/maddin