こんな人にオススメ
ある日、ブログを開くと「Service Unavailable」って出てきてサイトが見られないんだけどどうしたらいんだ。
しかもブログの管理画面も同じで終わった。
ということで、今回は先日このブログで発生したService Unavailableについてとその解決方法を解説する。
初めてのことだったので焦ってブログ終わったって思ったけど、多少の落ち着きと楽観主義と仮説・検証でなんとか解決した。
結論から言うと原因はディスク容量がパンパンだったこと、解決方法は一番大きかったのはバックアップ用のプラグイン「BackWPup」の過去ファイルを削除したことだった。
目次(クリック・タップでジャンプ)
突然サイトが真っ白に
本当はスクショを撮っておけば良かったんだけど、そんな余裕はなかった。ある日、新たな記事をWordPressに投稿しようとして管理画面を開くと「Service Unavailable」の文字が。
で、そこに追加で多分以下の文章があった。似たような現象は結構あるっぽくて、完全にこの文章かどうかはわからんけどブラウザの検索履歴的にはこれ。どうやら503エラーに該当するらしい。
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
執筆者はいつもNotionで記事の下書きをして、それをWordPressに貼り付けてブログを書いている。で、投稿しようとして管理画面を開いたら真っ白。
これは終わったって思った。これまでも読み込みに時間がかかることはあってもサイトが見られないことはなかった。
とりあえず色々試す
悶々と悩んでいても進むことはできないのでとりあえず色々と試してみた。試した内容を以下で述べていく。
なお、このエラーは色んな原因が絡み合って起きているようで、原因を1つに絞るのが難しいようだ。
リロード(解決せず)
まずはブラウザのリロード。たまたま読み込みがうまくいかなかった説があるので実行。解決せず。
シークレットモード(解決せず)
キャッシュとかそこら辺が問題かということで、シークレットモードで開くも同じ結果。
スマホで見てみる(解決せず)
MacBookのせいかと思ってスマホで閲覧してみるものの解決せず。
Wi-Fiを切ってpovo, Rakutenにしてもダメ
Wi-Fiが原因かと思って4G回線で読み込みしても解決せず。執筆者はpovoとRakuten UN-LIMIT VIのDSDVだけどどちらも解決せず。
ここまででPCの再起動は無駄だと思って再起動はしていない。スマホでダメならPC関連じゃないし。
ブラウザを変えてみる(解決せず)
ならブラウザが問題なのかということで、手持ちのブラウザSafari, Google Chrome, Vivaldi, Sidekickで試したが、全て同じ結果。
一晩放置(解決せず)
一時的なサーバーダウンの可能性があるとのことなので、一晩放置してみたが解決せず。
また、一時的に多くの人が訪れてパンクした可能性もあるとのことだったけど、そうでもなかった。
共有サーバだからかと思いきや
執筆者の使っているConoHa WINGは共有サーバなので一時的に他の人に訪問者が多くきたのかと思ったけど、一晩経っても解決しないとなるとそうでもなさそう。
ディスク容量を増やす(解決&プラン変更)
で、ConoHa WINGの管理画面からサーバ情報を見たところ、ディスク容量なる項目が容量オーバーになっていた。
あくまでも仮説でしかないけど、このディスク容量が溢れるとエラーが発生すると思い、とりあえず調べてみる。
ディスク容量が増えるとエラーが起きる
どうやらサーバのディスク容量が足りなくなると新規記事が作成できなくなったりサイトが表示されなくなるらしい。今の問題にマッチしている。
だったらディスク容量を減らせばいいんだけど、どのファイルやフォルダを消せばいいのかって問題に直面する。変に消してしまうのをビビったので、逆転の発想。
そう、ディスク容量を増やした。一番シンプルでありつつもお金のかかる方法。
プラン変更でディスク容量を増やす
これまではConoHa WINGのベーシックプランで運営してきた。初めのうちというかかなりの人がこれで十分とのことだったので、執筆者自身もこれで対応していた。
しかし、ディスク容量が足りないということだったのでプラン変更。ConoHa WINGの場合だとプランが以下の3つある(他にもあるけど特殊なので省いた)。
項目 | ベーシック | スタンダード | プレミアム |
料金(12ヶ月) | 891円/月 | 2,145円/月 | 4,290円/月 |
料金(6ヶ月) | 1,100円/月 | 2,365円/月 | 4,730円/月 |
初期費用 | 無料 | 無料 | 無料 |
SSD(ディスク容量) | 300 GB | 400 GB | 500 GB |
転送量目安 | 27.0 TB/月 | 36.0 TB/月 | 45.0 TB/月 |
ドメイン | 無制限 | 無制限 | 無制限 |
データベース | 無制限 | 無制限 | 無制限 |
メモリ | 8 GB | 12 GB | 16 GB |
vCPU | 6コア | 8コア | 10コア |
ベーシックからスタンダードに変更するといきなり倍以上の価格になるのが惜しいけど、経験と仮説検証のためにプランをアップグレード。
アップグレードすると解決
ディスク容量が増えて結果、サイトが表示されるようになった。晴れて問題解決。なんだけど、対策しないとまた同じことの繰り返し。二の舞を演じることになるので対策する。
ディスク容量が増える原因
ではそもそもディスク容量が増える原因とは何なのか。そこからアプローチする。
そもそもディスク容量とは
そもそもディスク容量ってのは一般的に以下の2つを合わせたものらしい。
- Web領域: 画像、動画
- メール領域: 本文、添付のデータ
一方で、記事の文章やコメントなどを保存するのデータベース容量と呼ぶらしくディスク容量とは別とのこと。
なので主に画像や動画をメインに削除・軽量化したらいいっぽい。後述するが、すでに画像は最適化してるからこの線はなさそうだけど。
メールで問い合わせてみた
で、プラン変更の前にメールで問い合わせをした。その回答として、可能性としてはプラグインなどで作成されたデータの肥大化があるとのこと。
調べてみると以下の項目がディスク容量を圧迫する要因となりうるとのこと。
- 下書き保存・更新のたびに生成されるリビジョン
- 自動保存される下書き
- ゴミ箱にある投稿やコメント
- 画像
- バックアップファイル
- キャッシュファイル
- プラグイン自体
ゴミ箱系は削除している(つもり)しそもそも数が多くないので優先度は低め。画像に関してもプラグイン「EWWW Image Optimizer」で最適化しているから優先度は低め。プラグインも都度減らしたりしているから今回は放置。
となるとリビジョンとバックアップファイル、キャッシュ。調べてみるとバックアップ系が一番引っ掛かっているっぽい。とりあえずバックアップ系から進めた。
ベーシックプラン300 GBから
問題発生時はベーシックプランだったから300 GB中マックスの300 GB使用中だった。で、スタンダードにアップグレードしたらなぜか285 GBくらいになったんだけどそれでも多い。ここから軽量化スタート。
ディスク容量を減らす(BackWPup、これが一番?)
まずは王道のBackWPup関連でディスク容量を減らす。執筆者はプラグイン「BackWPup」でバックアップを取っているんだけど、過去のバックアップファイルがかなり重いらしい。
BackWPupの設定を変更
BackWPupのスケジュールは毎日に設定している。一応、2, 3日に一回は記事の更新などをしているし、これくらいのペースでブログの見た目とかを変えているから頻繁にバックアップを取っている。
週一更新のブログなどでは週一でバックアップを取っているらしいけど、本ブログではここは致し方ない。
んだけど、バックアップを保存する期間がハンパなかった。90回分、すなわち90日分を保存している事になる。多くねえか。
ということで、バックアップを保存する期間を90日から7日に変更。これで無駄にファイルを保存しなくなる。
BackWPupのログを削除
ただ、さっきの設定だとこれからのファイルの保存をどうするかかもしれないということで、過去のバックアップの分は手動で削除。
執筆者はConoHa WINGを使用しているので、ConoHa WINGから直接BackWPupのログや一時ファイルを削除して過去の分だけ軽くした。その結果が上。あれ、そんなに変わらん。
人に寄ったら40 GBとか減るはずなのに4 GBくらいしか変わらなかった。削除してすぐだったからかもしれないけどそこまで効果がなかった。削除したファイルは以下。
- backwpup-〇〇-logs
- backwpup-〇〇-temp
○○の部分に固有な数字と文字の組み合わせが入る。いろんなサイトを見ると最後にbackupsがつくファイルややfile-backupってファイルがああるらしいけど、執筆者環境ではなかったのでスルー。
wp-contentハンパないって
バックアップでどうにかならんかなって思ったけどなんともならんかったので、アップロードしたファイルで大きいところからちゃんと調べる。
サーバーwp-content/uploadsには以下の3種類のファイルがアップロードされている。
- wp-admin: 8.21 MB
- wp-content: 291.17 GB
- wp-includes: 35.35 MB
確実に2つ目のcontentが悪さをしている。このフォルダの中にはキャッシュとかプラグインとかのファイルやフォルダが入っているっぽいけど、contentの中でも明らかに「https:」ってフォルダが重かった。
しかもこのフォルダが脅威の288.98 GBを占めていた。99%以上がこのフォルダ。これはボトルネック。
しばらくしたら一気にディスク容量が減った
は?って思った。「https:」ってフォルダが何なのかネットで調べてたんだけど、中々いいサイトが見つからない。で、とりあえずConoHa WINGでフォルダの中を見ていった。
んだけど、「https:」フォルダの中のそのまた中のフォルダの容量が60 GBとか。計算が合わない。あれって思ってwp-contentの容量を再度確認。
すると容量が70.37 GBまで落ちている。謎。バックアップのログを削除したのが時間差で効いてきたのか。
同時に画像の最適化もしていた
本当はバックアップファイル関連の処理だけしてその効果を知るべきだったんだけど、時間がもったいないと感じたので同時並行で画像の最適化もしていた。
こちらはサイトの高速化のためにちょっと前からやっていたんだけど、新規アップロード画像の最適化ができるとのことだったので手動実行していた。
プラグインは「EWWW Image Optimizer」で一括最適化をしていた。実際のところは最適化できるほどの重さではなかったので、これはあまりディスク容量には関係なさそう。
これが一番デカかった
このBackWPupだけでもかなりの容量を減らせたので、とりあえずこれで終わっても良かったけど、気になることがあったのでもう少し続く。
wp-content/https:とは(GoogleDrive関連?)
軽くなったのは良いんだけど、結局のところwp-content/https:とは何なのか。フォルダの中に入るとGoogleDrive関連のフォルダが出てくる。
執筆者はMacBookのローカル環境に記事で使ったコードとか画像とかを置いているんだけど、そのデータをGoogleDriveにも置いている。その関連かと思われる。
ただ、そのままフォルダの中に入っていってもzipファイルが大量に入っていて何が何やら。
zipファイルをダウンロードして中身を見てみる
ということで、これらのzipファイルをダウンロードしてみて中身を見てみる。一番重いファイルで3.4 GB、同じくらいの1 GB台が複数個あって、これらの合計で70 GBくらいになっていた。
中身を見てみると、どうやらwp-contentなどもここに入っているのでまんまバックアップファイルっぽい。
wp-contentの中のGoogleDrive関連のフォルダーを開けてみると、月ごとの画像がに入ったフォルダがあった。ただ、フォルダ名が自分のローカルのものとは異なる名称だったので、自動生成かと思われる。
画像ファイルだけではなくプラグインのファイルもあったので、やっぱりバックアップなのか。よくわからん。
GoogleDriveとの連携を解除してファイルを削除
GoogleDriveのファイルを消せば連動してWordPress内のファイルが減るという仮説の元、GoogleDriveの連携を解除してDrive内のファイルを全削除。もちろんPCのバックアップは取った。
しかし、容量は変わらず。WordPress上から削除するのがいいのかもしれないけど、如何せん情報が少ないのでビビる。とりあえず放置。
保存容量ってとこも削除
ファイルを削除してゴミ箱も空にしたんだけど、保存要領ってところも全削除にゴミ箱を空にした。ローカルファイルには影響がない(接続を解除しているから当たり前か)ので安心。
したんだけど、それでもディスク容量は回復せず。GoogleDrive系はバックアップとして使用しているものになるので、とりあえずこれはこれでいいか。
接続を解除していたので、再度GoogleDriveと接続してミラーリングして元に戻しておいた。
現状はDrive関連は放置
ディスク容量がかなり減ったとしても未だ70 GBくらいが占められている。これでは困るんだけど、下手にデータを削除するのが怖いので放置。
何かしらの情報を手に入れるまではここまでの作業の70 GBでステイ。
WP-Optimizeでリビジョンを削除
リビジョンってのは記事の更新記録のことで、いわばちょっとしたバックアップのようなもの。少し過去のバージョンの記事内容を呼び出したい時に使えるもの。
しかし、これが溜まりに溜まるとちりつもでディスク容量が圧迫されるようだ。ということで、リビジョンを削除する。
プラグインWP-Optimize
使うのはデータベースの最適化に使われうプラグインの「WP-Optimize」。WP-Optimizeを使ってリビジョンを削除するんだけど、どうせならってことで同時にデータベースなども最適化した。
最適化する項目は上の画像で、これらを最適化した後の表示は以下。2,500を超えるリビジョンが消えたらしい。実際、リビジョンの表記は消えていた。
ディスク容量はほぼ変わらず
リビジョンを削除したんだけど、ディスク容量としてはほぼ変わっていない。多分リビジョンは差分を保存しておくだけど、基本的にNotionで作成したものをWordPressで貼り付けているだけだからリビジョンの容量は多くないのだろう。
ということで、執筆者環境としてはあまり変わらず。
未添付ファイルの軽量化はスルー
WordPressの記事で扱っていない未添付の画像を検索することができるんだけど、ここでの未添付は記事中では使っていないって意味らしい。なのでサイドバーとかで使っている画像もここに入ってきてしまう。
しかも記事で使っていても未添付に入ることもあるので、下手にファイルを消すとまたアップロードし直さないといけない。これは面倒ということで、とりあえずこれはスルーした。
バックアップファイルには注意
ということで、今回はWordPressで書いているこのブログが真っ白になってその原因がサーバのディスク容量であったこと、そして解決法の1つとして「BackWPup」の過去バックアップを削除することについて紹介した。
こんなことがあるのかと思ったけど、実際に起きてしまったから仕方がない。まあこれでまた知識がついたしまだまだ知らないことが多いと気付かされた。
今回の記事で他の方が同じ目に合わないように、同じ目にあった時に迅速に対処することができることを切に願う。
関連記事
-
【月次報告2022年6月】どうしようもない自分を鼓舞する背水の陣
2022/7/2
-
【月次報告2022年5月】伸びてきたけど6月はちょっと休みます
2022/7/2
-
【月次報告2022年4月】ガジェットブログと訴求と収益
2022/6/4
-
【月次報告2022年3月】ブログと真剣に向き合い伸ばしていく
2022/5/4