기본적으로 저는 Debian 8 Jesse를 실행하는 Google Compute에서 마이크로 서버를 부팅하고 그 위에 MySQL과 Apache2를 설치하여 작은 테스트 사이트를 실행했습니다. 저는 테마를 직접 개발하는 것이 아니기 때문에 코드가 없습니다. WPBakery를 사용하여 페이지를 작성하는 themeforest에서 얻은 테마를 방금 업로드했습니다.
처음부터 속도가 느리다는 것을 알았습니다. 이것은 제 클라이언트가 볼 수 있는 작은 테스트 서버였기 때문에 괜찮았습니다. 완료되면 현재 호스팅으로 이동할 계획이었습니다. 그러나 많은 편집 작업을 수행할 때 가끔씩 작동이 멈추고 SSH 터미널에 "메모리 부족" 오류가 발생한다는 사실을 깨닫기 시작했습니다. 다시 말하지만 괜찮았습니다. 테마를 사용자 정의하기 위해 며칠 동안 필요한 테스트 사이트일 뿐입니다. 그들은 대개 스스로 해결합니다.
그러나 일단 서버가 멈춰서 재부팅해야 했습니다. 이것이 최소한 디스크 스냅샷을 찍으라는 첫 번째 신호였어야 했습니다. 그러나 일단 다시 돌아오면 모든 것이 괜찮았고 훨씬 더 빨라졌습니다. WP 백엔드에서 문제가 발생했다고 생각하고 서버를 다시 시작하면 문제가 해결되었습니다.
하루나 이틀 더 사용했는데 갑자기 다시 작동이 멈췄습니다. 하지만 이번에는 더 이상 SSH에 연결할 수 없었습니다. Google Compute GUI를 사용하여 재부팅했지만 아무것도 작동하지 않았습니다. 사용량 그래프가 정점에 도달했습니다. 직렬 출력을 기록하면 다음과 같은 결과가 나타납니다.
Feb 25 12:47:05 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
그리고 매초 또는 매초마다 이것을 출력합니다. 부팅하는 동안 출력을 보면 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. Developers Console에서 VM을 종료합니다. 2. 디스크의 스냅샷을 만듭니다. 3. 스냅샷을 추가 디스크로 작동 중인 VM에 연결합니다(옵션 선택: 새 디스크 만들기 -에서) 스냅샷) 개발자 콘솔에서 위 단계를 수행하고 마지막에 "저장" 버튼을 클릭하는 것을 잊지 마세요. 이제 새 VM의 "ssh" 버튼을 클릭하고
4. 명령줄에서 이 추가 디스크를 마운트합니다.
sudo mount /dev/sdb1 /mnt
참고: Cloud Launcher를 통해 가동한 VM에서 이러한 단계를 수행하고 파일을 이 VM에 직접 복사할 수 있습니다.