フォーラムへの返信
- 投稿
一応、今日のCPUのグラフをスクショして以下のページに貼り付けてしました。
っと、ここまで長々と書いてしまいましたが、すでにとても参考になる情報もいただけましたし、高度な知識の必要なことをただで相談させていただいている状態ですので、教えていただくのも可能な範囲で大丈夫です。
基本的にはどうかご自分の都合を優先してください。自身の整理にもなりましたので、すでに大変助かっております。＞・基本的に、高負荷になるのはピーク時間帯と合致する、ということでしょうか？常時高負荷ではない？
効率化する前は、ピークの時間には常にCPUが100%に近い状態でしたが、それいがいでもfaultsを連発していました。
なのでアクセスをされるたびに負荷の高い処理が実行されて、それがアクセスの増えるピークの時間に大きな負荷をかけていたと言った感じかもしれません。
現在でも、目測ですが、ピークではない時にも30分～1時間に１回くらいfaultsが発生してる感じで、ピーク時はCPU使用率の平均が60～90くらいを推移しているようです。＞・サーバの再起動は実施されましたでしょうか？
調べてみたのですが、残念ながら共用サーバーは再起動ができなさそう？です。教えていただいたサイトのtopコマンドを使ってみたところ、２０日前に再起動しているようですね。おそらく当サイトが移動された日なのではないかと思います。教えていただいた記事が大変参考になりました。技術的な部分で相談できる方がおらず、とても助かりました。
上記の記事にありました、消去済みプラグインのDB整理もしてみましたので、またある程度効率化できたのではないかと思います。
ちなみにそれ以前にやった私の作業は、最初に効率化や掃除・管理をしてくれるプラグインを複数利用して、それでいじれなかった中で大きなテーブルをphpmyadminから手動で掃除した感じです。
特にオプションテーブルのテーマオプションに使っていない巨大なデータがあって、それを削除したところずいぶん増しになったといったところでした。ちなみにcpu使用率ですが、だいたい以下の感じでした。
lsphp:oader/emotioncreator/wp-admin/admin-ajax.php
15%lsphp:portal.com/uploader/emotioncreator/index.php
15%lsphp:l/yuki-portal.com/uploader/koikatu/index.php
15%lsphp:i-portal.com/uploader/honeyselect2/index.php
15%lsphp:i-portal.com/uploader/honeyselect2/index.php
14%lsphp:ploader/honeyselect2/wp-admin/admin-ajax.php
13%lsphp:ortal.com/uploader/koikatusunshine/index.php
16%lsphp:yuki-portal.com/uploader/aisyoujyo/index.php
13%lsphp:i-portal.com/uploader/honeyselect2/index.php
10%lsphp:oader/emotioncreator/wp-admin/admin-ajax.php
4%lsphp:ortal.com/uploader/koikatusunshine/index.php
16%lsphp:m/uploader/aisyoujyo/wp-admin/admin-ajax.php
17%lsphp
11%lsphp:ploader/honeyselect2/wp-admin/admin-ajax.php
1%lsphp:i-portal.com/uploader/honeyselect2/index.php
15%lsphp:ortal.com/uploader/koikatusunshine/index.php
14%lsphp:ploader/honeyselect2/wp-admin/admin-ajax.php
1%/usr/sbin/mysqld
2%/usr/sbin/mysqld
1%/usr/sbin/mysqld
2%/usr/sbin/mysqld
10%非常にわかりにくくてすみません。やはりDBはそれほど問題ないと思って良いのかな？それにしても、どうも明らかにこのサイトと比べればアクセス数の少ない他サイトでも同じくらいの負荷がかかっているのが気になるところですね。
以前このサイトをメンテナンスモードに切り替えた時CPU使用率が20％を切るくらいに下がっていたのでこのサイトだけの問題だと思っていたのですが、それだけではないのかもしれません。
このサイトは自作でPVカウントをしていますが、初期の頃のサイトはa-jaxでカウントするプラグインを使っていますので、それが原因なのでしょうか。やはりカウント系のプラグインは負担が大きいのかもしれません……
ただ、このサイトでもボタンのカウントにa-jaxを使用してるはずなのに、負荷率が同じくらいなのが気になるところです。ただ、lsphp:i-portal.com/uploader/honeyselect2/index.php
42%
lsphp:l/yuki-portal.com/uploader/koikatu/index.php
40%
lsphp:i-portal.com/uploader/honeyselect2/index.php
39%他のタイミングでこのような負荷がかかっているところもありましたので、単純にこのサイトにかかった負荷が他に影響しただけのような気がしますし、やはりサーバー系の知識がないと判断のつけようがなさそうです。
やはりあとはもうログを漁るくらいしかないかもしれませんが、以上大きな時間をかけるのもちょっと厳しいところです……。ちなみに補足として、知識がないため確信があるわけではありませんが、正常だった頃のリソースログなどは、残念ながらおそらくですが確認できなくなっていると思います。少なくともcpanelから見ることのできるリソース使用量からは遡ることができませんでした。
理由としては、今回のサイトの負荷が異常になった初期の頃、レンタルサーバー運営の方で当サイトを移動して負荷の分散を図ったという旨を頂いたからです。
mixhostは共用サーバーだったと思いますので、利用者の少ないサーバーの方へ移動したのではないかと思いますが、そのため12月以前のログを遡るというのはおそらくほぼ無理なのかと思います。bnrtさん、コメントありがとうございます。
サーバー関係は詳しくないため、CPUリソースの内訳の見方がわからないのが一番のネックでして、ウィンドウズで言うところのタスクマネージャーのようなものがあれば良いのですが……。下の方にも書いた通り、調べつつmysqlをいじったり、プラグインも使ったりしてDBをどうにかこうにかそれなりに効率化したところ、緊急性はない程度に改善はできたのですが、未だにCPUの使用率が瞬間的に100を超えるfaultsが発生していたり、アクセスが集中してるピークの時間帯（PM11～AM1時くらいまで）だと結構な負荷がかかっていたりと、修正できるのであれば修正したい状況でしたので、アドバイスいただいて大変ありがたいです。
ツイッターに関しては特に盲点でした。旧アカウントのツイッターへのアクセスは切っているはずですが、このサイト以外にもありますので、念のため確認しておこうと思います。
ちなみにxmlrpcに関しては、htaccesからアクセスを禁止しているのですが、その場合でもおっしゃるようなパターンはあり得るでしょうか？
その後、調べつつどうにかデータベースの方を効率化してみたところ、どうやらある程度負荷を改善できたかなというところまでこれました。
このままある程度安定してくれれば緊急性はないかなと思いますので、一旦移転・ドメイン変更などは見送ることにしました。
ただ、そもそもサイト自体が負荷の軽いものではないため将来的には視野に入れておこうかと思います。色々アドバイス頂き、ありがとうございました。サーバー運用の経験は自サイト以外では全くありませんので、ログの分析と言われてもちょっとという感じですね……。
移転実行は置いておいても、無料期間などを利用して別サーバーで仮稼働してみて状態を調べるというのは手段として良いかもしれませんね。近々試してみようかと思います。
ドメインに関しては変更することは可能だと思いますが、知識不足で申し訳ないのですが、ドメインが現状の負荷にどう関係しているのかがわかりません。ドメインを変更すると負荷が軽くなる可能性があるのでしょうか？
私の方でも調べてみましたが、さくらもかごやも、わいせつな写真や動画は禁止とのことで、当サイトコンテンツだと規約上だめなようですね。
それと当サイトの容量だと、あのプラグインはおそらくですが難しいかと思います。一度落とすためのコピー・バックアップを作成するという仕様だったはずですが、その場合サイト全体の倍以上の容量が必要になるはずです。現在サーバー容量の使用率が80%ほどですので、おそらく使用するとパンクするか、途中で停止するかと思います。
また、お金の話で恐縮ですが、当サイトの容量を受け入れられるプランですと、どのレンタルサーバーも年間6万円ほどかかってしまいます。当サイトのサーバー料金もすでに支払い済みですので、確実に移転で状況が改善すると確認できたわけではないなら、恥ずかしながら金額的にちょっと移転するのは躊躇してしまうというのもあります。ご返答ありがとうございます。これほど早く反応してくださる方がいらっしゃるとは思っていませんでした。
ただ、せっかくアドバイスを頂いたのに申し訳ないですが、サイト移転はちょっと現実的ではないかと思います。サイト容量が全体で400GBちょっとほどあることもあり、こちらのプラグインは存じていましたが、プラグインでの移行で不具合が出ないか若干心配なのも多少ありますが、それ以上に、
コノハはサイトを作る際に検討したこともあるのですが、あそこは当時、規約的にアダルトサイトが作成不可（確かエックスサーバーもそうだったかもしれません）で、高速かつアダルトサイト可のレンタルサーバーがmixhostくらいだったのが、決めた理由だったからです。サイト管理者としてお恥ずかしいことなのですが、私の実力ではこれ以上如何ともし難く、サーバー関係の知識のある方でどなたかサイト正常化に向けてアドバイスしてくださる方はいないでしょうか。
現状ですが、メモリなどは正常？な使用量ながら、サーバーのCPU使用率が異常に高く（アクセスの多い時間帯だと平均が80~100%になることも珍しくない）、Number Of Processesも頻繁に100%になりfaultしているという状態です。
おそらくですが容量は関係ないだろうということで、サーバーサポート担当者の方の助言も受けながらすでに一般的な高速化対策は試してみた状態です。具体的には、
・バックアップ用プラグインの無効化
・キャッシュプラグイン・css等のminifyプラグインの導入
・PVやボタン等のカウント機能の一時停止
・画像の圧縮プラグインを実行し、トップページの表示をwebpになるよう変更などに加えて、最低限PHPをいじれますし、このサイトのワードプレステーマや一分機能は自作のため、
・エラーログを確認して、PHPで警告が表示されている箇所の修正
・wpqueryを使用している箇所は、transiendAPIを使用して一定時間キャッシュするように変更など全体的な効率化を行いました。また、
・プラグインで一時的に日本以外の国からのアクセスを停止
など、現在いくつかセキュリティ系のプラグインをテストしてみましたが、大きな変化はありません。
他にも、xmlrpc.phpへのアクセスブロック、bingbotのアクセス回数が異常に多かったことから、robots.txtを調整してグーグルなどの問題のないサーチエンジン系bot以外のクロール間隔変更、禁止なども試しました。もう思いつく限りのことはやり尽くして、相談していたサーバーサポート担当者の方からはアクセスログを確認してはどうかと言われたのですが、私にはサーバー関係の知識はなく、具体的な方法やツールなどの提示してもらえずでした。
はっきり言ってアクセスログを確認して対処できる知識があるならすでに実行できているだろうというのが正直なところです。知識のない人間が生ログを見てどうにかしろと言われてもと途方に暮れている次第です。自らの力不足を晒してしまって情けない限りですが、原因が内部にあるのか外部にあるのかもわからず。どなたかお時間をいただける方がいましたら、掲示板を介してなにか教えていただけますと幸いです。
先日サイト高速化の一環で画像を圧縮、トップページ用のwebp画像の生成プラグインを実装したのですが、webp画像がある場合に右クリックから保存をすると、webp画像として保存するのはクロームなどのウェブブラウザの仕様のようです。
これに関しては申し訳ないのですが、私では解決が難しいです。クロームの拡張機能などで拡張子を変えて保存するものなどがあるようですので、そういったものを検討していただけたら良いかもしれません。