Q&A
今提示していただいている画像のデータは平時のものでしょうか？エラーや遅延が出ていた時間帯のものも提示していただくことは可能でしょうか？（問題の切り分けと原因の特定に必要と思われます）
自社ECで販売している、女性向けの下着や水着、
セクシーコスチューム等の画像サイトを
WordPressで運営しています。
１つの投稿に、テーマごとに２０～３０枚程度の画像と
私たち女性スタッフの着用レビューなどが掲載されています。
最初はとても快適に閲覧できていたのですが、
１日1万PVを過ぎたあたりから、表示に１０秒くらいかかるようになり、
2万PVを超えた現在は、完全表示まで２０秒以上かかります。
また、休日夜間のピーク時には、
InternalServerError500が出たままになり
VPSを再起動するまで動かなくなる事もしばしばです。
この時はPleskの管理画面にも入れず、
VPSの管理画面からサーバー再起動しています。
そこで、サーバーの負荷対策をしなきゃ！ という話になったのですが、
無料サーバー監視ツールのグラフを見ると、私のような素人目には、
そんなに高負荷ではないのに遅くなるようにも見えるので、
正直、原因が全くわからない状況です。
また、「CDN」や「VPSのメモリ増強」など、
キーワードとその概要は調べられても、
社内にインフラ技術者が全くいないため、
実際に効果が期待できるのか、判断しかねています。
目標としては、「サクサク」まではいかなくていいので、
１０秒以内程度でページが表示されれば十分です。
何より夜間に500エラーで表示されなくなる症状を防ぎたいです。
インフラに詳しい方に、低予算から試せそうな
オススメ負荷対策をアドバイスを頂けないでしょうか？
また、参考になるブログや、調査・対策を安価にやってくださる
業者さんの紹介など、何でも構いません。
どうかよろしくお願いします。
■現在の運用状況
・GMOクラウドの、VPS４GB(メモリ4G、仮想CPU４コア)＋Plesk12です。
・上記VPSに、WordPress用と、画像用のドメインを分けてアップロードしています
→→ http://sample.com （ＷＰ用ドメイン）
→→ http://img-sample.com （画像用ドメイン）
・PleskでnginxをONにしています
・画像はJPEGmini等で極力小さくしています。90～200kB程度
・ＷＰ側にはキャッシュプラグインとして、「WP Fastest Cache」の
有料版を入れ、PC用・スマホ用のキャッシュを生成しています。
・アクセスの６割がスマホです
■負荷状況
・CPU使用率
普段は５％～２０％を行き来しています。
過去２か月で２０回以上、使用率１００％で警告が出ています。
・ディスク使用量
１０％くらい
・空きメモリ容量
７０％くらい
・ロードアベレージ
普段は1.4～1.7くらいですが
過去３カ月で７を超える警告が１０回程度発生しています。
■その他の制限
無料で使えるCDNとしてCloudFrareを試そうとしたのですが、
扱っている商品画像には、かなりきわどいコスチュームや
モデルさんによる着用プレイイメージ画像などもあるため、
問い合わせてみたところNGと言われました。
そのため、CDNを使うなら他社になるのかと思います。
VPSも同じ理由でGMOクラウドになりました。
■HTTPアクセス不能になったときの状況
・1/12日
・1/16日
■メモリの設定
・WordPress側のwp-configに下記の指定はありませんでした。
define('WP_MEMORY_LIMIT', '★★M');
・php.ini側の設定は下記です
■PHPバージョン（phpinfoで取得）
PHP Version 5.3.3
■>>mysql --versionコマンドで取得
mysql Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (x86_64) using readline 5.1
■その他MySQLの情報（mysqladminコマンドで確認）
mysqladmin Ver 8.42 Distrib 5.1.73,
for redhat-linux-gnu on x86_64
Server version 5.1.73
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/lib/mysql/mysql.sock
Uptime: 1 day 3 hours 32 min 58 sec
Threads: 2
Questions: 5190098
Slow queries: 324
Opens: 39682
Flush tables: 1
Open tables: 64
Queries per second avg: 52.331
■php -mの結果
[PHP Modules]
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
ionCube Loader
json
libxml
mbstring
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
shmop
SimpleXML
sockets
SPL
sqlite3
standard
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
zip
zlib
[Zend Modules]
the ionCube PHP Loader
■遅延の直前直後詳細
コメントありがとうございます。 遅延発生時の数値を追記いたしました
参考までに、wordpressとphpの使用メモリはどのくらいでしょうか？ define('WP_MEMORY_LIMIT', '64M'); https://wpdocs.osdn.jp/wp-config.php_%E3%81%AE%E7%B7%A8%E9%9B%86 post_max_size http://php.net/manual/ja/function.ini-get.php
コメントありがとうございます。wordpressとphpの使用メモリを追記しました。
phpおよびMySQLのバージョンは幾つですか？
回答3件
0
ベストアンサー
ぱっと見メモリはあんまり変化していないのでCPU（処理系）が怪しいんじゃないかなと思います。（※非効率な処理などが多いなど）
Queries per second avgがちょっと大きすぎるので
あんまり良くないクエリになっているか無駄に大量に発行しているんじゃないかなーとも。（使っているプラグインによってもこのあたりは大きく変わります）
SSHで接続し、topやsarコマンドでプロセスをモニタリングしてみてください。
CPU使用率が高いプロセスが見つかるのではないでしょうか。
あと、前触れなく落ちている感もあるので、落ちる直前のアクセスログも調べてみてください（これは提示していただかなくても大丈夫です。）
妙に多いアクセスがあったりすればそれもチェックしてみてもいいかなと。
不正アクセスのさばき方に問題があってアクセス過多でタイムアウト、みたいなこともWordPressを使用している方には少なくないので。
とはいえ、内部処理を見直すのは順当とはいえ
時間もコストもかかるので、場合によっては
・サーバースペックを上げる
・Kosuke_Shibuyaさんのおっしゃっているように処理効率の高いverを使用する
などのほうが安価で早い場合が多いというのも実情ではありますが。
投稿2017/01/21 07:37
総合スコア700
ご回答ありがとうございます。
遅延発生時の前後のエラーログを見てみたところ、
XMLRPCに２０分で５０回くらいのアクセスがありました。
おっしゃる通り、攻撃によるCPU不可が要因の可能性が高いです。
現在、下記対策を実施して様子を見ています。
・.htaccessで、xmlrpc.phpをアクセス禁止にしました
・wp-login.phpにベーシック認証をかけました
数日様子を見て、PHPバージョンアップなどの対策も
実施してみようと思います。
xmlrpc.phpを経由した不正アクセスによる負荷増加も一つの要因ではありますが、
数的にもたいしたことはないので
内部処理が根本的要因と考えるのが妥当です。
そちらもよくチェックするほうが良いでしょう。
またxmlrpc.phpのアクセス禁止は
Order allow,deny
Deny from all
みたいな方法でしょうか？もしそうであれば、実は負荷はほとんど軽減できないので
例えば、
RewriteEngine On
RewriteBase /
RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L] #この一行を追記
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
（※WordPressデフォルトのhtaccessの"RewriteBase /"の後に一つRuleを加える）
のように「http://0.0.0.0/へ飛ばす」（＝無効なURLへリダレクト）などしてやるほうが良いです。
アドバイスありがとうございます。
おはずかしながら、まさにdeny from all しちゃってました。
さっそくhtaccessを修正しました。
ご指摘の通り、XMLRPCは大した要因ではなかったらしく、
大きく改善はされないようでした。
これまでで、CPU１００％が続き、ロードアベレージが７や８に
なったままだと、遅延やダウンになり、なおかつ、
送受信が多くてもCPU使用率が上がらないタイミングも多いこと、
そして送受信が平均値くらいでもCPU使用率が跳ね上がることが
あることから、おっしゃる通りなんらかの内部処理が怪しいのかもしれません。
夜間のピーク時にtopやsarコマンドなどで、状態を見ていきます。
0
PHP5.3 -> 7.0または7.1 にアップデートすることで、かなりパフォーマンスは上がります。
MySQL5.1 -> 5.5 以上にアップデートすることで、かなりパフォーマンスは上がります。
一応、現在の状態で、php -m の結果を補足してください。
注意）Wordpress は最新のバージョンにアップデートできる状態になっているか？下手に改造（魔改造）していたりすると動かなくなる可能性がある。バックアップを取った上で行ってください。最悪、バージョンをダウンゲレードして戻す必要があるかもしれません。
投稿2017/01/21 02:39
退会済みユーザー
総合スコア0
ご回答ありがとうございます。 PHPモジュール情報を追記しました。
PHPのバージョンを上げるという手があるのですね。
バージョンアップは上司が怖がっているので、
専門業者さんにお願いできそうか調べてみます
怖いという気持ちもわからないではないですが、いくらなんでも5.3は古すぎますね。セキュリティ的にも問題があるので、プログラマーとしては、5.3を使っていることの方が何倍も怖いです。
5.3のままでということであれば、以下の方法もありますが、オススメはしません。急場凌ぎで試すくらいの価値はありますが。
http://dev.classmethod.jp/server-side/eaccelerator-performance-up-php-wordpress/
ありがとうございます。PLESKのGUIから、割とお手軽に
5系、7系ともにバージョンアップできるらしいので、
それでやってみようと思います。
wordpressのバックアップは完全に取った上で、行いましょう。下手をコクと再生不可能になります。
0
nginx（と PHP）・MySQL は、同じサーバ上にインストールされているのでしょうか？
であれば、まずはどのプロセスが CPU を占有しているのかを確認するのが先決かと思います。
（おそらく nginx と MySQL のどちらかでしょうが）
それが特定できないと、以降の調査や対策の方針が立てられませんので。
以下のページの、特に"CPU使用率とIO待ち状態を調べる"という項 以降が参考になるかと思います。
http://qiita.com/yuku_t/items/2f5341e4aa635800a0a1
"遅延の直前直後"のデータが取得できればベストですが、アクセスがピークになる時間帯のデータが取れればベターかと思います。
また、マニュアルを読む限り、nginx はデフォルトの設定では 1CPUコアしか使用しないようです。
http://nginx.org/en/docs/ngx_core_module.html#worker_processes
Syntax: worker_processes number | auto;
Default:
worker_processes 1;
Context: main
Defines the number of worker processes.
念のため、この設定も確認してみてください。
nginx は不勉強なので私から確かなことは言えないのですが、設定変更の際は以下のページなどが参考になるかと思います。
http://www.crystalsnowman.com/?p=344
あと、
・ディスク使用量
１０％くらい
とのことですが、グラフ画像を見る限り、90% 使用しているように見受けます。
これが本件の原因か否かは何とも言えませんが、「使用率 90%」は、間違いなく危険水域です。
サーバにログインしてdf -hコマンドを実行するなどして、実際の使用量を確認してみてください。
投稿2017/01/23 17:16
総合スコア4791
ご回答ありがとうございます。
おはずかしながらnginxについては実は全然わかってなくて、
GUIコンソールでONにしてるだけでした。これから勉強しなきゃですね。
とりあえずはご紹介いただいたページを見ながら、
負荷が高そうな処理がどれか、調べていきたいと思います。
わかりやすいテキストを教えていただきありがとうございます。
なお、ディスクについてはこんな感じでした。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 197G 14G 173G 8% /
tmpfs 1.9G 20K 1.9G 1% /dev/shm
maifukuhara様
レスありがとうございます。
> 負荷が高そうな処理がどれか、調べていきたいと思います。
問題箇所が特定できれば、その分 解決に近づけると思います。
頑張ってください。
> なお、ディスクについてはこんな感じでした。
'df -h'コマンドの実行結果を見ると、確かに 10%弱しかディスクを使用していませんね。
安心しました(^^;
あなたの回答
tips
プレビュー
