なんかワケわかんないくらいWordPressが重くなって…ナンデー！Σ(ﾟロﾟ)oﾞ
まずは復旧…？
前回の記事どおり、ひとまず復旧しました。
WordPressのエクスポート／インポートを使ったものの、一部のメディアファイル（画像）が来ていないようです。
古い記事とかは画像が × になってたりする感じです(^-^;
とりあえず、復旧した手順とかをおさらい。
まずは、WordPressを別ディレクトリに準備
とにかく「ぽぽづれ。」は重いものの、同じサーバーにある「テスト系ぽぽづれ」は重くないのが不思議です。
「ぽぽづれ。」が固まった時に、たまに反応が遅くなったりはしましたが、そんな程度でした。
さて、今までのディレクトリとは別ディレクトリに WordPress 4.3.0 の ZIP ファイルをアップロードして展開して、インストールを行います。
当然ながら記事数は「0」。そして、WordPress はサクサク動きます。
必要そうなプラグインはアップロードしたりディレクトリからダウンロードして有効化。
非常に順調です。
エクスポート出来ても、インポート失敗
元の WordPress から「すべてのデータ」をエクスポートして、新しい方でインポートをしますが、始まってしばらくしたら…
…？Σ(ﾟロﾟ)oﾞ
止まってしまいました。
記事は3分の2くらいインポートされていたところで止まっていました。
タイムオーバーかも？Σ(ﾟロﾟ)oﾞ
とりあえず、この時点で公開している元の方は500エラーとか出てる状態なので、時間がかかったままタイムオーバーになったのかも知れません。
ちなみに、今月のCPU使用時間と503発生回数です。
…Σ(ﾟロﾟ)oﾞ
っていうか、CPU使用時間ナンダコレー！Σ(ﾟロﾟ)oﾞ
CPU使用時間使い過ぎ、503エラー出過ぎ！
503エラーが8月27日に554回、CPU使用時間は23日～29がちょいちょい12時間超えとかワケワカンナイことになってます。
| 8/17 | 8/19 | 8/21 | 8/23 | 8/25 | 8/27 | 8/29 | |
| 503エラー | 0回 | 22回 | 1回 | 1回 | 0回 | 554回 | 52回 |
| CPU使用時間 | 3:54 | 3:56 | 4:55 | 14:26 | 9:37 | 12:41 | 12:13 |
| 転送量 | 2.52GB | 1.59GB | 1.69GB | 1.69GB | 2.32GB | 2.05GB | 2.53GB |
転送量とかと必ずしも一致するわけでも無いのですが、転送量も多いですね(^-^;
実は閲覧数とかに比べると随分多い転送量だったりします。
アクセスログをexcelに読み込んで見てみます。
8月27日のログを見てみると、検索関連のbot（自動巡回プログラム）が連続でアクセスしているので、連続してエラーになっているようですが、直接の原因では無いみたい。
他にはー…、
| アクセスファイル | アクセス回数 |
| POST /wp-login.php HTTP/1.0 | 46,793 |
| POST /admin-ajax.php HTTP/1.1 | 2,428 |
おっそろしいほどの「wp-login.php」へのアクセス！Σ(ﾟロﾟ)oﾞ
も、もしかして、これが直接の原因かも知れない…！Σ(ﾟロﾟ)oﾞ
突然ですが、「wp-login.php」へのアクセスランキングですっ！Σ(ﾟロﾟ)oﾞ
| アクセス元 | （国） | アクセス回数 |
| ***-***-***-***-*********.********.net | ウクライナ | 6回 |
| **********.******.net | ヴァージニア州（アメリカ合衆国） | 2回 |
| n****.com | フランス | 46,790回 |
| pool.luga.net.ua | ウクライナ | 12回 |
って、ほとんど一か所からだったΣ(ﾟロﾟ)oﾞ
- 13時55分から21時56分までの間に、
- 46,790回の、
- 同じIPアドレスから、
- 「POST / wp-login.php HTTP/1.0」の要求。
- ちなみに、ユーザーエージェントは無し。
全部「403 Forbbiden」で返されているものの、凄いですね、このアクセス(^-^;
CPU利用時間もこの約8時間にも及ぶ4万6千回のアクセスのせいなんじゃないかな…(^-^;
なんか、人材派遣会社（？）っぽいので、「踏み台にされた」んじゃないかと、やや心配。
次に「admin-ajax.php」へのアクセスでしたが、こっちは普通のアクセス、かな。
そして微妙に気になる「google-proxy-**-***-**-***.google.com」からのアクセス。
長くなったので、別記事にしようと思います。
多量アクセスが原因？
まずはメンテナンスモードにして、全てのアクセスを一時的に遮断します。
「WP Maintenance Mode」をインストールして、有効化。
メンテナンス状態になったので、今なら好き放題！
プラグインを全部「停止」してみます。
ところが、「Jetpack by WordPress.com」を停止させようとするとメモリ不足が出て停止できません。
メモリ不足を解消するために停止したいのに、メモリ不足で停止できません。
リネームして強制停止です。
↓
アクセスが減って、メモリが空いたところでインポート。
今度はうまく行きました。
メディアのリンク切れ？
エクスポートしたファイルには記事データ、ページデータなどしか入っていません。
画像は入っていないので、エクスポートしたからといって、安心して元サイトを消すと大変なことになります。
そして、記事をインポートするときに「添付ファイルのインポート」にチェックを入れておくことで、元サイトから画像を引っ張ってインポートしてくれるようです。
サムネイルなども表示されて、記事内の画像も表示されているようです。
画像も表示れているようです。
ようで…？Σ(ﾟロﾟ)oﾞ
よくよく見ていくと、結構リンク切れしています(^-^;
しかも、クリックすると、フルサイズの画像はちゃんと表示されます。
記事内のsrc属性を見ると…
<img class="alignnone size-medium wp-image-2759" src="http://mailbox.conohawing.com/popozure/blog/wp-content/uploads/2012/06/fbb7ed77699a471849e4bd998f201b1411-300x228.jpg" alt="高速の有効（X25-M）" width="300" height="228">
記事内で指定されているファイル名は「…-300×228.jpg」となっていますが、「/wp-content/uploads/2012/06/」を見てみると、実際に格納されているファイル名は何故か「…-300x229jpg」となっています。
| 記事内のリンク | wp-content内にある画像ファイル |
| <img src=”…/○○○-278×300.png”> | ○○○-169x300.png |
| <img src=”…/○○○-300×219.jpg”> | ○○○-300×220.jpg |
| <img src=”…/○○○-300×259.png”> | ○○○-300×260.png |
| <img src=”…/○○○-175x300.png”> | ○○○-176x300.png |
元のWordPressを見直したところ「300×228.jpg」を呼び出していたので、きっと添付ファイルを呼び出すときに、メディアファイルへ登録するときのように「フルサイズを取得→小さいサイズを作成」という動きをしているのだと思います。
「メディア」の設定や、もしかしたらWordPressの仕様で切り捨てとかの計算が変わっていると、こうなってしまうのかも…(^-^;
これは一個ずつ直していくのはだるいですね。
実は「Search Regex」で「-168×300.」→「-169×300.」など、何種類か置き換えをしてしまったものの、逆に新たなリンク切れを作ってしまったかも知れません。
「添付ファイルをダウンロードしてインポートする」にチェックを入れた上でインポートして、その後にFTPソフトやファイルマネージャー等を使って、今まで使っていたディレクトリから「wp-content/uploads」配下をコピーするのが良さそうです。
それでもリンク切れの画像が出来てしまうようなので、「Broken Link Checker」でリンク切れURLを直していきました。
（上の表のように、だいたい小さい方の数字を1上げると当たりだったので、1あげて→再確認→OK という手順で行いました。）
WP-PostViewsのカウンターがリセットされる！
何度インポートしなおしても、「WP-PostViews」で取っていた記事ごとの閲覧カウンターが 0 になってしまいます。
せっかく閲覧数をカウントしてきたのに、全部「0」になってしまうのは惜しいです。
さて、カスタムフィールドを見ると「views」が2つあります。
1つ目は値が「0」のもの。2つ目は今までのカウンターが入ったものです。
どうやら、記事をインポートする時に、
- 記事IDの枠を用意。
- プラグインで追加されているカスタムフィールドの枠も用意。（「WP-PostViews」で追加されているカスタムフィールド「views」が追加される。値は「0」。）
- 記事タイトルや本文をセット。
- カスタムフィールドをセット。（この時に2つ目の「views」が値とともに作成される。）
という動きをしているような気がします。（「WordPress Importer」のソースは見ていないので未確認。）
実は「SNS Count Cache」も同じように、管理画面を見ると「キャッシュ済み」と表示されているのに、記事を見るとシェア数は「0」と表示されてしまう現象が起きていました。
何度もインポートし直したり、phpMyAdmin から値が重複するデータを削除したり、更新したりして、悪戦苦闘の末…。
「これらのプラグインは『停止』してから、『インポート』しましょう。Σ(ﾟロﾟ)oﾞ」
プラグインが有効だからカスタムフィールドが作成されるだけで、無効化しておけばカスタムフィールドはインポートされていて、その後にプラグインを有効にすれば、ちゃんと取得されるようです。
（かなりハマりました…(^-^;）
カスタム投稿タイプを使用するものは有効化しておかないと記事そのものがインポートされないので、そっちは有効化しておく必要があります。
（「DownLoad Manager」とか「TablePress」とか。）
元のWordPressはどうなった？
アタック等も無くなったはずなのですが、「重いまま」です。
動きが軽いWordPressの方の wp-config.php をいじってDBを差し替えると、今度はそっちが重くなってしまうので、記事DB（posts、postmeta）が重さの要因になっているか、設定（options）に変な値が入っているのかも知れません。
設定を変更しながら解決方法を探したい気もするのですが、ひとつひとつの動作がとにかく遅くて、この状態から何かするのは難しそうです。
しばらくは原本として残しておいて、削除する感じになりそうです。
[2015/09/06追記]
WordPress4.3にアップグレード後、CPU負荷とメモリ消費が増大するという記事が。もしかして、これが原因？(^-^;
まとめ
手順まとめ
- 新しいWordPressを用意
- 新しいWordPressで、カスタム投稿タイプを使用しているプラグインはインストール・有効化しておく
- 古いWordPressから、エクスポート→「すべてのコンテンツ」。
- 新しいWordPressで、インポート→WordPress→「添付ファイルをダウンロードしてインポートする」にチェック。
- 新しいWordPressで、カスタムフィールドを使用しているプラグインを有効化。（インストールもここでして良いし、あらかじめインストールしておいても良い）
- FTPソフトやファイルマネージャを使って、「wp-content/uploads」配下の画像ディレクトリを古い方から新しい方へコピーして、画像のリンク切れを少しでも減らす（効果の程は未確認のため、任意で。）
- リンク切れをチェックするプラグインなどでリンク切れになった画像などをチェック。地道に直す…。（置き換えは間違えると、二次被害が…）
- ざっと記事を確認。ちゃんと表示されていることを確認。
こんな感じでしょうか。
自分の場合、ドメインそのままでインストールしているディレクトリを差し替えたのでこれ以上の作業はありません。
ドメイン等を変更する場合、画像URLなどの置き換えが必要になると思います。
コメント