私はWordPressベースのWebサイトを共有ホスティングで実行しています。その応答時間は非常にまともです(HTMLページを取得するために約2秒、すべてのリソースをロードするために5秒))。
私はそれを専用の仮想サーバー(Ubuntu 12.04 LTS)に移動することを計画していました。これにより、理論的には改善され、共有されていないため、一貫性が向上します。ただし、ページが生成されるまでに10秒かかるため、パフォーマンスが大幅に低下しました。
サーバーで_/etc/hosts
_を編集し、ドメインを_127.0.0.1
_にマッピングして、ネットワークの問題を除外しました。 Apacheロードテスターab
を使用してHTMLを取得したので、JS、CSS、画像はすべて除外されています。それでも10秒かかりました。
MySQLも使用するサーバーにZpanelをインストールしましたが、そのページは非常に高速(1.5秒)で表示され、phpMyAdminも表示されます。 wordpressデータベースでphpMyAdminを介して直接クエリを実行すると、クエリ時間が10〜30ミリ秒の領域で非常に高速に返されます。
メモリも十分で、使用可能な1Gbの物理メモリのうち800Mbしか使用されていないため、スワップの問題でもないようです。 PHPのパフォーマンスを向上させるために、APCもインストールしましたが、効果はありませんでした。
他に何を探すべきですか?このパフォーマンス低下の原因は何ですか?クラウドベースの仮想サーバーで実行しているので、何らかのI/Oの問題でしょうか?
私はプロバイダーに問題を提起できるようにしたいと思っていますが、何らかの診断からの実際のデータを表示せずに、彼が私のアプリケーションを非難するのではないかと心配しています。
[〜#〜] update [〜#〜] HTTPリクエストを実行したときにsar
出力(毎秒)を使用:
_02:31:29 CPU %user %Nice %system %iowait %steal %idle
02:31:30 all 0.00 0.00 0.00 0.00 0.00 100.00
02:31:31 all 2.22 0.00 2.22 0.00 0.00 95.56
02:31:32 all 41.67 0.00 6.25 0.00 2.08 50.00
02:31:33 all 86.36 0.00 13.64 0.00 0.00 0.00
02:31:34 all 75.00 0.00 25.00 0.00 0.00 0.00
02:31:35 all 93.18 0.00 6.82 0.00 0.00 0.00
02:31:36 all 90.70 0.00 9.30 0.00 0.00 0.00
02:31:37 all 71.05 0.00 0.00 0.00 0.00 28.95
02:31:38 all 14.89 0.00 10.64 0.00 2.13 72.34
02:31:39 all 2.56 0.00 0.00 0.00 0.00 97.44
02:31:40 all 0.00 0.00 0.00 0.00 0.00 100.00
02:31:41 all 0.00 0.00 0.00 0.00 0.00 100.00
_
PDATE 2 jostenの提案の後。
I/O:
iotop
はOSError: Netlink error: No such file or directory (2)
で失敗し、_sar -d
_も_Requested activities not available in file /var/log/sysstat/sa14
_で失敗します。これは、iostat
も失敗するのと同じように、これが仮想マシンであるためだと思います。 _%iowait
_によって報告された_sar 1 10
_が常に0%であるのは、そのためでしょうか?
CPU負荷:
htop
のCPU%を超えているプロセスは、実際には_Apache2
_です。私はこれがおそらくデータベースであると期待していましたが、そうではありませんでした。新しいHTTPリクエストを実行すると、数秒間で最大94%になります。これが原因のようです。
_strace -f -t
_と1つの要約_strace -c -f
_を実行しました。 lstat
呼び出し(57786)が非常に多く、2455でエラーが発生しているようです。これが正常かどうかはわかりません。それ以外の最上位の呼び出しは_wait4
_で、これは正常であると私は推測します(待機しているだけです)、およびmunmap
。以下のトップ5。
_% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
51.06 0.124742 897 139 6 wait4
14.90 0.036388 1 57786 2455 lstat
9.67 0.023622 13 1857 munmap
7.69 0.018790 37 514 brk
6.70 0.016361 481 34 clone
2.87 0.006999 74 94 12 select
_
strace
自体がApacheの速度を2倍遅くしました。長いトレースを理解して、CPUが数秒間スパイクする原因を示すものがあるかどうかを確認しようとしています。
パフォーマンスの良いサーバーのlstat
の一般的な時間はどれくらいですか?ストレージアクセスの障害である場合にプロバイダーに建設的な方法で文句を言うことができるように、いくつかの情報を収集したいと思います。
[〜#〜] update [〜#〜]fio
ランダム読み取りテストの出力:
_random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
fio 1.59
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 128MB)
Jobs: 1 (f=1): [r] [100.0% done] [12185K/0K /s] [2975 /0 iops] [eta 00m:00s]
random-read: (groupid=0, jobs=1): err= 0: pid=24264
read : io=131072KB, bw=10298KB/s, iops=2574 , runt= 12728msec
clat (usec): min=119 , max=162219 , avg=380.34, stdev=957.37
lat (usec): min=119 , max=162219 , avg=380.89, stdev=957.40
bw (KB/s) : min= 7200, max=13424, per=99.89%, avg=10285.72, stdev=1608.68
cpu : usr=2.80%, sys=18.65%, ctx=33511, majf=0, minf=23
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w/d: total=32768/0/0, short=0/0/0
lat (usec): 250=45.57%, 500=37.17%, 750=3.41%, 1000=7.83%
lat (msec): 2=5.67%, 4=0.27%, 10=0.08%, 20=0.01%, 250=0.01%
Run status group 0 (all jobs):
READ: io=131072KB, aggrb=10297KB/s, minb=10545KB/s, maxb=10545KB/s, mint=12728msec, maxt=12728msec
_
私が今持っている唯一のヒントは、fio
出力のCPUラインは、他のシステムと比較した場合、かなりのアクティビティを示しているように見えるということです。ローカルのUbuntuマシンで実行したところ、出力は次のとおりでした。
_cpu : usr=0.19%, sys=0.59%, ctx=32923, majf=0, minf=23
_
usr
パーセンテージは、私のサーバーで報告されているもののごく一部のようです。
[〜#〜] update [〜#〜] Re PHP APC。はい、インストールされています。phpinfoからの出力:
_APC Support enabled
Version 3.1.7
APC Debugging Disabled
MMAP Support Enabled
MMAP File Mask no value
Locking type pthread mutex Locks
Serialization Support php
Revision $Revision: 307215 $
Build Date May 2 2011 19:00:42
_
確認すべき特定の設定はありますか?これらは私が持っている設定です(ローカル値、マスター値):
_apc.cache_by_default On On
apc.canonicalize On On
apc.coredump_unmap Off Off
apc.enable_cli Off Off
apc.enabled On On
apc.file_md5 Off Off
apc.file_update_protection 2 2
apc.filters no value no value
apc.gc_ttl 3600 3600
apc.include_once_override Off Off
apc.lazy_classes Off Off
apc.lazy_functions Off Off
apc.max_file_size 1M 1M
apc.mmap_file_mask no value no value
apc.num_files_hint 1000 1000
apc.preload_path no value no value
apc.report_autofilter Off Off
apc.rfc1867 Off Off
apc.rfc1867_freq 0 0
apc.rfc1867_name APC_UPLOAD_PROGRESS APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_ upload_
apc.rfc1867_ttl 3600 3600
apc.serializer default default
apc.shm_segments 1 1
apc.shm_size 32M 32M
apc.slam_defense On On
apc.stat On On
apc.stat_ctime Off Off
apc.ttl 0 0
apc.use_request_time On On
apc.user_entries_hint 4096 4096
apc.user_ttl 0 0
apc.write_lock On On
_
[〜#〜] update [〜#〜] _apc.shm_size
_を96Mに増やしました。キャッシュのフルカウントは0になり、Webサイトを何度か更新した後、キャッシュへのヒット数は96.5%になりました。 APCのメモリ使用量は25.4MBです。
ロード時間を3秒ほど短縮したようですが、画像などを取得せずにサーバー自体から純粋なwget
を実行すると、約4〜5秒になりました。他のホスティングよりも2倍以上遅いですが、間違いなく改善。
サーバーが完全にアイドル状態のときにこれらのページをレンダリングするのに時間がかかるのはなぜか不思議です(開発PCにAPCがインストールされておらず、そのような動作はありません)。そして、残りの秒数が無駄になっているのはまだ奇妙です。
これは、ApacheがPHPのコンパイルに多くの時間を費やしている他のケースのように見えます。オペコードキャッシュ(APCなど)がインストールされていることを確認しましたか?役立つ場合は、phpinfo()
の出力にロードされたモジュールとして表示されます。それ以外の場合、mod_php内でのApacheの動作を追跡するには、最善の策はXHProfです。
Google経由でここに到着したjbx以外の方へ:ところで、他の答えは素晴らしいです。それらを読んでください。しかし、それらの答えと、それらに対するjbxの応答は、私がこの結論に到達するのに役立ちました。
最初に問題が何であるかを判断する必要があります。 PHP、MySQL、I/O、負荷、メモリ、CPU、カーネルなどの場合。sar
はシステムのメトリックを記録します。あなたはその行為でそれを捕まえる必要があるでしょう。 atop
を構成して、プロセスアカウンティングを実行できます。これは間違いなく役立ちます。
I/Oかどうかを判断するため
iotop
やatop
などのツールを使用して、ディスクの使用状況を確認します。これらのツールは、IOの原因も教えてくれます。一般に、iowaitがsustainedで10%を超える場合、これが問題になる可能性があります。
sar
はディスクIOをログに記録します。 sar -d
を実行して確認できます(%util
列を参照)。
ロードされているかどうかを判断するため
htop
、top
、uptime
などのツールを使用します。再度、これを実行中のプロセスに関連付けて、プロセスが実行していることの詳細を確認します。これは、スケジューラーの負荷を報告することに注意してください。 CPU使用率は反映されていません。
それがCPUかどうかを判別するため
sar
は、その日を救うためにもう一度やって来ます。この情報はsar -P ALL
で確認できます。リアルタイムデータにはmpstat -P ALL
を使用することもできます。一般に、CPUは、すべてのCPUが100%の場合にのみ問題になります。 80%以上は、それらが使用されていることを意味します(ただし、必ずしも飽和しているわけではありません)。
それがメモリ(VM)であるかどうかを判断するため
vmstat
を使用する必要があります。 vmstat -S M 1
そして、swap
、io
、およびsystem
列を観察します。明らかに、大量のスワッピングはパフォーマンスに影響を与える可能性があります。 system
セクションもあります。大量の割り込みでも同じことができます。
割り込みかどうかを判断するため
vmstat -S M 1
を使用できます。残念ながら、システムに正常な状態のベースラインがない場合、割り込みが問題であるかどうかを判断するのは困難です。大量の割り込み(カーネルからのアクションを必要とするハードウェアによって引き起こされる)は、システムをクロールさせます。 NICの障害は、これを行うことで悪名高いです。
カーネルであるかどうかを判別するため
これはトリッキーですが、通常はstrace
、perf
、またはsysdig
ツールが必要です。そのようなツールの1つがperf top
です。要約付きのstrace
(-c
)は素晴らしいですが、システムリソースに関連して分類されません(したがって、提供されるデータは推測にすぎません)。 perf top
を使用して、それがカーネルであるという結論に達するのが理想的です。マシンがサポートしている場合は、stap
(SystemTap)を使用することもできます。また、strace
はパフォーマンスに影響を与えることにも注意してください。システムが非常に重要な場合は、sysdig
を使用する必要があります。
MySQL/PHPかどうかを判断するには
基本的に、私が上に投稿したものに従う必要があります(たとえば、perf
は、カーネル時間の長い原因となっているコマンドに関する情報を提供できます。iotop
、atop
、htop
それらを使用しているシステムリソースに関する情報を提供できます);基本的に、上記のツールを使用して、何が負荷の原因であるかを特定します。
MySQLであると判断したら
実行しているクエリである可能性があります(したがって、MySQLのそのクエリでEXPLAIN
を使用する必要があります)。また、データベースが最適化されていること、および実行しているクエリが最適化されていることを確認する必要があります。また、使用しているテーブルエンジンが、実行していることに理想的であることを確認する必要もあります(MyISAMがInnoDBであるはずの大きなテーブルがたくさんあります)。上記のいずれも問題ではないと判断しても、MySQLが疑われる場合は、影響を受けるテーブルのデータをアーカイブして、そのテーブルへのアクセス(テーブルスキャン)を減らすことができます。また、制約の整合性を検証し、キャッシュバッファリングを有効にして、インデックスが最適であることを確認することもできます。
このプロセスに役立つツールはmytop
です。しかし、mytop
が提供するすべての情報は、mysql
クライアントで簡単にアクセスできます。実行するいくつかの有用なステートメント:
SHOW FULL PROCESSLIST\G
は、現在実行中のSQLステートメントの完全なリストと、サーバーに対するそれらのステータスを取得します。SHOW ENGINE INNODB STATUS\G
(InnoDBのみ)EXPLAIN EXTENDED <QUERY>
MySQLの実行を確認するクエリを説明します。SHOW GLOBAL STATUS\G
サーバー全体のステータスPHPであると判断したら
ツールを使用してPHPコード(xdebug
など)をプロファイリングし、生成されたプロファイルをKCacheGrind
で開いて、プロファイリングされた=のパフォーマンス分析を確認できます。 PHPコード。
これらのいずれでもない場合は、サーバーをアップグレードする必要があります。
見渡してください 私が別の質問に与えた答え 手がかりとしてこれに似ています。
問題は、WordPress領域外の他のページが正常に読み込まれているが、WordPress自体が詰まっている場合、私が推奨する一般的なもの以外に3つのことが思い浮かびます。
wp-config.php
に正しく設定したことを確認しましたか?その理由は、MySQL DB for WordPressオプションでパスが設定されている場合、パスが正しくなくてもWordPressが機能することがあるためです。それらがwp-config.php
にあることを確認すると、正しいディレクトリを使用するようにWordPressを強制し、一時フォルダとキャッシュフォルダが期待どおりに機能するようにします。my.cnf
がサイトのDBニーズに対して正常に機能していることを確認しますか?一般的に、私はクラウドサーバー上に問題なく大量のCMSサイト(最近ではWordPress)をセットアップしました。 10秒のページ読み込みは、クラウドホストが不十分であることの症状ではありません。私はここで私が推薦するものと私の他の答えを検討することをお勧めします。また、問題であるセットアップでクリーンWordPressインストールを実行してデバッグすることをお勧めします。それがサイト全体と比較してうまく機能する場合、サイト固有のコードに構成の問題があることは明らかです。
編集:別のアイデアがあります。あなたの設定のどこかにApache認証(htaccess)がありますか? localhost
から許可するように設定されていますか?下記参照。この設定が機能することもありますが、Allow from localhost
がAllow
のリストの最初、またはAllow
のリストの唯一の項目である場合、逆引きDNSの奇妙さから窒息する可能性があります。可能であればそれを無効にすることをお勧めします。有効になっている場合と比較して、サイトの読み込み速度を確認してください。
Order Deny,Allow
Deny from all
Allow from 127.0.0.1 ::1
Allow from localhost
トラフィックの多いサイトの最大のI/Oソースの1つは、_/tmp
_ I/Oです。
_/tmp
_は、多くのCMSシステムのphpセッションデータ用に読み取られます。たとえば、すべてのページ遷移でWordPressは、訪問者が新しいページにアクセスする権限を持っているかどうかを判断します。
_/tmp
_は、返されたデータまたは作成された一時的な選択セットが/ tmpにあるSQLSELECTに対して何度も書き込まれる/読み取られます。
遅いマシンのクライアントを新しい(できれば速い)マシンに移行するときに最初に行うことは、メモリのサイズです。私の速い30秒のアルゴリズムは次のとおりです。
(使用済みトップメモリ+使用済みスワップ)* 2
次に、新しいマシンで_/tmp
_をtmpfs(メモリ)+mysqltuner(数日ごと)+ mysql(really mariadb)をmysqltunerが主に静かになるまで調整します。
パフォーマンスの遅いサーバーに新しい命を吹き込むために必要なのは、この単純なトリックだけである場合もあります。
これが行われた後、マシンがまだ遅い場合は、各サブシステムの調整を検討し始めます。
チューニングするときは、常に現在の状態を知らせるツールから始めます。
したがって、メモリのサイズ変更には、top(メモリ+スワップ+ロード)を使用します。
Apacheの場合、ログをチェックして、MaxRequestWorkersのようなメッセージが超過していないことを確認します。
古い場合[〜#〜] php [〜#〜]バージョンはAPCモニターを使用して、APCが実際に機能していることを確認します+十分なメモリがあります+ヒット率が高い-90%以上が適切です目標。
最新のPHPバージョンでは、数年前にAPCに取って代わったOpcacheでも同じことが行われます。
MySQLの場合、最初にMariaDBに切り替えます(私の経験ではより高速です)。
CMSesの場合、WordPressのように、キャッシュプラグインが機能することを誰かのWordに絶対に伝えないでください。 abを使用してサイトの速度をテストします。最初に、キャッシュなしで+キャッシュプラグインを追加して、再テストします。
ヒント:ZenCacheから始めてください。驚かれることでしょう。
最後に、slowloris [〜#〜] ddos [〜#〜]セットアップしたすべての新しいサーバーに対する攻撃をシミュレートします。これは、DDOSの動作が、ネットワークレイアウト+アダプター速度+マシンリソースによって異なるためです。 Apache 4xxステータスコード(通常は400 + 408)がApacheログに表示されるのに十分な時間DDOS攻撃に耐えられるようにシステムを調整し、fail2banを使用してこれらのIPをブロックします。
I/Oチューニングの大部分は、マシンにサイトをデプロイする前に、slowlorisDDOSなどの異常な負荷状況を生成することです。このようにして、広告費やスラッシュドット効果のような実際の負荷の下で、またはDDOSや高価値攻撃のような攻撃負荷の下で、または_robots.txt
_ +マシンからすべてのリソースを吸い出します。