基本的に、私は Google Compute で Debian 8 Jesse を実行するマイクロ サーバーを起動し、そこに MySQL と Apache2 をインストールして、小さなテスト サイトを実行しました。テーマは自分で開発しているわけではないので、コードはありません。ページの作成に WPBakery を使用する themeforest で入手したテーマをアップロードしただけです。
最初から遅いことに気付きました。これはクライアントが見ることができる小さなテスト サーバーなので問題ありません。完了したら、現在のホスティングに移行するつもりでした。しかし、編集をたくさん行っていると、時々フリーズし、ssh ターミナルで「メモリ不足」エラーが発生することに気付きました。これも問題ありませんでした。テーマをカスタマイズするために数日間必要だったテスト サイトです。通常は自然に解決します。
しかし、サーバーが停止してしまい、再起動しなければならなくなりました。これが、少なくともディスクのスナップショットを取るべき最初の兆候だったはずです。しかし、サーバーが復旧すると、すべてが正常になり、速度も著しく向上しました。WP バックエンドで何かが手に負えなくなったため、サーバーを再起動すると問題が解決したと考えました。
さらに 1 日か 2 日使用したところ、突然再び動作しなくなりました。しかし、今度は ssh で接続できなくなりました。Google Compute GUI を使用して再起動しましたが、まったく動作しませんでした。使用状況グラフはピークに達しており、シリアル出力をログに記録すると次のようになります。
Feb 25 12:47:05 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
そして、これは約 1 秒ごとまたは 1 秒おきに出力されます。起動中に出力を見ると、Apache が起動した直後に開始されるように見えます。ただし、上記の失敗に関する他のメッセージもいくつかありますが、原因が何なのかはよくわかりません。
Feb 25 12:44:48 test-wrs systemd[1]: Started ACPI event daemon.
Feb 25 12:44:48 test-wrs systemd[1]: Started System Logging Service.
Feb 25 12:44:48 test-wrs systemd[1]: Started Expand the root partition and filesystem on boot.
Feb 25 12:44:48 test-wrs systemd[1]: Started /etc/rc.local Compatibility.
Feb 25 12:44:48 test-wrs systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
Feb 25 12:44:48 test-wrs systemd[1]: Failed to start Login Service.
Feb 25 12:44:48 test-wrs systemd[1]: Unit systemd-logind.service entered failed state.
Feb 25 12:44:48 test-wrs systemd[1]: Started LSB: Start and stop the mysql database server daemon.
[ OK ] Started Permit User Sessions.
Feb 25 12:44:48 test-wrs systemd[1]: Started LSB: Start NTP daemon.
Feb 25 12:44:48 test-wrs systemd[1]: Started LSB: Apache2 web server.
Feb 25 12:44:48 test-wrs systemd[1]: dbus.service: main process exited, code=exited, status=1/FAILURE
Feb 25 12:44:48 test-wrs systemd[1]: Unit dbus.service entered failed state.
Feb 25 12:44:49 test-wrs systemd[1]: Started Permit User Sessions.
Feb 25 12:44:49 test-wrs systemd[1]: Time has been changed
Feb 25 12:44:49 test-wrs systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.
Feb 25 12:44:50 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Feb 25 12:44:51 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Feb 25 12:44:52 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Feb 25 12:44:54 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
ここで何をすべきかわかりません。これはメモリの過剰使用が原因である場合があると読みましたが、これは以前発生した問題と相関している可能性があります。そのため、ディスクのスナップショットを作成し、より高い RAM を持つサーバーで起動してみましたが、RAM をどれだけ高く設定しても同じ結果になります。さらに調査するために ssh で接続することもできません。
問題が何なのか、または解決方法を知っている人はいますか? 行き詰まっており、最初からやり直して、以前にやったことをすべてやり直さなくても済むようにしたいと思っています。少なくとも MySQL データベースのダンプを取得できればうれしいのですが、データベースはリモート接続を受け入れるように構成されていません。そうする理由がなかったからです。そのため、何らかの方法でそれに取り組む必要があります。
答え1
セットアップでメモリ不足が発生する理由については、推測することしかできません。VMを大きくしても問題が解決しないという事実は、何らかの構成またはセットアップの問題が原因であることを示唆しています。Google によって事前設定された Wordpress セットアップは、「Deployment Manager」「Cloud Launcher」の下にあります。これらは任意のサイズの VM で実行でき、経験上、基本的なインストールではメモリ不足にならないことを保証できます。データベースを回復するには、次の操作を実行できます。1. 開発者コンソールから VM をシャットダウンします。2. ディスクのスナップショットを作成します。3. スナップショットを動作中の VM に追加のディスクとして接続します (オプション: スナップショットから新しいディスクを作成する)。開発者コンソールで上記の手順を実行し、最後に「保存」ボタンをクリックすることを忘れないでください。次に、新しい VM の「ssh」ボタンをクリックし、
4. コマンド ラインでこの追加ディスクをマウントします。
sudo mount /dev/sdb1 /mnt
注: Cloud Launcher 経由で起動した VM からこれらの手順を実行し、ファイルをこの VM に直接コピーすることもできます。