iowaitがパンッパンでいろいろと遠回りしてしまった件

3ヶ月くらい前からサーバーが重いという報告が来ていて
その時はphp7にアプデしてだいぶ改善されて放置。
(確かLA10近くから3付近になったはず)

そのサーバーが最近またすんごく重くなっていて(LA20付近)
いろいろとハマったのでメモ

まずは
topコマンドで見てみるとiowaitが20%近くあって

ぱっと目についたのは
kblockd
jdb2/md2-8
flush-9:1,2

というプロセス(スクショはpidstat -d ですが)

PIDも低いし実行ユーザーrootだし
バックアップ系かな?(今思えばこれが壮大な罠)

iostat -xt 5

で%utilが常にhda,hdbともに100%近く。

ここでサーバー屋さんにお問い合わせ。
GMOさんの対応の速さ神やで。

しかし挙動としては正常らしい。

dd if=/dev/zero of=/tmp/hoge bs=1KB count=1024000 ; rm /tmp/hoge
dd if=/dev/zero of=/tmp/hoge bs=1MB count=1024 ; rm /tmp/hoge

で1G書き込むも全然問題なさそう。
さらに頭が_???_なわけです。

もういちど状況を整理しプロセスの
kblockdってもしやビットコイン系かな?などと迷走しましたw

lastやlastlogコマンドであやしい挙動がないか確認。

ここで固定IPからログインがあることが判明。
そのユーザーを渡してる方に質問するとISP固定回線とのこと。
ちょっと安心。

lastコマンドのrebootユーザーが300日(これが正常なのは知ってた)
その2行上にrootユーザーが still login
これをまたもやGMOさんにお問い合わせ

これはシリアルコンソール用のログインとのことでこれも正常。

ビットコイン系とか迷走してたクラッキングはなさそうだとして、
重い原因が結局わからん。

ここで怪しいと思っているプロセスのNICE値を上げる(優先順位は下がる)

しかし変化なし。ん?変化なし。。。
バックアップ系とかデフォルトプロセスの暴走だと
踏んでたのに前提が崩れたぞ。。。

とりあえずサーバーのバックアップを取って再起動。
しかし良くなるはずもなく。

状況を整理。

reniceしても状況が良くならなかったので
全体のNICE値を確認。

上記スクショの内容よりNICE値が低いものは
httpd,php,mysqlなどなど

ここで20ドメインほど入っているサーバーの各設定を見直す。

キャッシュ系プラグインの見直し。
Mysqlも一通り見てみる。
うーん問題なさそう。

ログの肥大化?
問題なさそう。

Apacheのアクセスログをオフに。
******************************
Pleskコアファイルをイジらないといけないよ
https://support.plesk.com/hc/en-us/articles/115000067345-How-to-disable-Apache-and-nginx-log-files-for-domain-domains
******************************

状況変わらず。

duコマンドやpleskの管理画面から肥大化しているフォルダがないかここで確認。
問題なし。

念の為wp-content/cache/のファイルの数を数えてみた。

するとサイトの一つのobjectフォルダ配下に240万のファイルが。。。
これっぽいということで
プラグインをオフにしたあとに、removeしました。
(通常の削除はタイムアウトしたし)
pleskのサイズ計算や、もっと上の階層からのduでは
ファイルの数が多すぎて計算結果が出ていなかった。

サーバーが重くなっていることもあってrmコマンドの完走に12時間ほどかかりましたw

結論:W3 Total Cache のObject cacheの設定には気をつけましょw

ということで開発案件をすすめますっ

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です