Ubuntu Natty/11.04에서 LAMP를 실행하는 Amazon EC2 인스턴스가 있습니다. 지난 몇 달 동안 세 차례에 걸쳐 서버가 중지되었습니다. 그 중 두 번은 지난 2주 동안에... 중지되었습니다. 응답하지 않고 연결 시도(SSH 또는 기타)에 대한 응답을 중지하지만 EC2 제어판에서는 여전히 실행 중인 것으로 보고합니다. 콘솔을 통해 인스턴스를 재부팅해야 할 때마다 데이터가 손실되었습니다.
이제 문제를 진단하려고 하는데 아무것도 나오지 않고 확인해야 할 사항에 대한 조언이 필요합니다. Syslog에는 의심스러운 것이 없습니다. 각 경우에 마지막으로 발생한 일은 munin이 정규 5분 크론 작업을 실행하는 것이었습니다. 하지만 기계가 언제 작동을 멈췄는지 정확히 모르기 때문에 크론 로그가 얼마나 가까운지는 알 수 없습니다. 얼어붙을 정도. 그 후에는 시스템이 다시 시작될 때까지 단순히 실행되지 않은 것처럼 보입니다. 그 이후에는 syslog에 일반적인 dmesg 출력처럼 보이는 내용이 포함됩니다.
교통량과 동결 시간 사이에는 상관관계가 없는 것 같습니다. 각 경우는 교통량이 가장 많은 시간에서 멀리 떨어져 있습니다.
이러한 문제의 원인을 파악하기 위해 또 무엇을 살펴볼 수 있습니까? 문제는 무엇입니까?
부록: 서버가 다운되었을 때 어떤 경우에도 서버에 과부하가 걸리지 않았습니다. CPU와 메모리 사용은 모두 제한 없이 안전하게 이루어졌습니다. 디스크 여유 공간(수십 기가바이트)이 충분했습니다. Apache나 MySQL 로그에도 이상한 점은 없으며, 그 시점에는 작동이 중지됩니다. 이는 중간/높은 CPU 인스턴스입니다.
답변1
가장 먼저 해야 할 일은 서버가 응답하지 않을 때 이를 알려주는 모니터링을 설정하는 것입니다. pingdom 및/또는 Cloudwatch를 사용하여 서비스 가동 시간과 CPU 및 RAM과 같은 시스템 통계를 확인하면 됩니다. 둘 다 소규모 계정을 위한 무료 요금제를 제공합니다. 이렇게 하면 다운되었을 때 아이디어를 얻을 수 있고 그 순간에 무슨 일이 일어나고 있는지에 대한 로그를 더 쉽게 찾을 수 있습니다. 일반적으로 이와 같은 문제는 시스템에 충분한 리소스가 없기 때문에 발생할 수 있습니다. 인스턴스의 크기는 언급하지 않았지만 마이크로와 같은 것은 간단한 크론 작업으로 CPU를 100% 고정하고 어느 시점에서 서버가 잠길 수 있습니다. .
또한 syslog 옆의 다른 로그도 확인하고, 모든 앱 로그를 확인하여 시스템이 다운되기 전에 오류가 발생하는지 확인하세요.
답변2
호스트 시스템의 NIC가 불량일 수 있습니다.