아파치가 왜 야생을 실행하고 MySQL을 죽이는가?

아파치는 지난 며칠 동안 통제 할 수 없었고 MySQL이 두 번 충돌했다. phpBB 포럼을 포함하는 WordPress 웹 사이트를 마이그레이션했을 때 시작되었습니다.

서버 관리자에 대한 경험이 많지 않아 문제의 원인을 정확히 찾아내는 것이 매우 어렵습니다. MySQL이 다운되었음을 알았을 때 TOP을 실행하여 시스템로드가 98.00으로 급증했습니다. 서버는 10 개의 V-HOST를 실행하여 모두 많은 양의 트래픽을 수신하므로 많은 apache-2 프로세스가 실행되고 있음을 분명히 알았습니다.

높은 서버로드는 10 분 동안 지속 된 후 정상 상태로 돌아 왔습니다. 이 시점에서 네트워크 트래픽이 급증하지 않았습니다.

불행히도, MySQL 오류 로깅이 비활성화되었습니다 (이제 다시 활성화 됨). 단서가 없습니다. 그러나 Apache가 모든 리소스를 소비했기 때문에 MySQL 프로세스 ID가 종료 되었기 때문에 확실합니다.

내 질문은 :

다음에이 문제가 발생하면 시스템로드 스파이크를 일으키는 원인을 어떻게 식별 할 수 있습니까? 미친 PHP 스크립트일까요? DDOS 공격 일 수 있습니까?

충돌시 MySQL을 자동으로 다시 시작하는 방법이 있습니까?

나는 지금 설치했다 htop. 이보다 더 유용 할 수 top있습니까?

여기 내 서버 통계 :

m1.xlarge (8 ECUs, 4 vCPUs, 15 GiB memory, 4 x 420 GiB Storage Capacity)
Ubuntu Server 12.04.3 LTS 

MySQL은 여전히 ​​아무것도 기록하지 않을 수 있습니다. 왜냐하면 아마도 아파치 자식의 시스템 메모리 압력으로 인해 시스템에 의해 시스템이 실수로 종료되고 있기 때문입니다. / var / log / syslog에 이것의 흔적이 있어야합니다.

MySQL은 충돌 또는 강제 종료로 자체 재시작을 시도해야하지만, 충분한 메모리가 사용 가능하지 않으면이를 수행 할 수 없습니다.이 두 번째 실패는 mysqld_safe에서 "크래시"가 아니라 "거부" 시작해 "계속 시도하지 않습니다. 실패한 재시작 시도는 종종 관리자가 "충돌"로 잘못 해석합니다. 원래 오류의 특성은 MySQL 오류 로그에서 쉽게 간과 할 수있는 메시지 뒤에 숨겨져 있기 때문입니다.

mysqld_safe Number of processes running now: 0

내가 당신과 비슷한 상황에 대해서는 InnoDB Crash Post Mortem 을 참조 하십시오.

"why"에 대한 겉보기 간단한 대답은 Apache와 MySQL 사이의 부하와 현재 구성 사이에 시스템에 충분한 메모리가 없으며이 조건을 가져 오는 트래픽로드와 관련된 팁 포인트가 있다는 것입니다 .

Apache는 하위 프로세스에서 각 동시 브라우저 요청을 처리하므로 동시 연결 수가 증가하면 하위 수가 증가합니다. 먼저 아파치 설정에서이 값을 제한하여 실제로 동시 연결의 증가를 일으키는 원인을 이해할 수 있도록해야합니다. 이는 단순히 무겁지만 합법적 인 트래픽 스파이크입니까? 일종의 서비스 거부? 너무 오래 실행되어 요청을 지연시키는 DB 쿼리? 최적화가 필요한 것?

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients

동시 Apache 프로세스를 제한하면이를 방지하는 데 도움이되지만, 이것이 완전한 솔루션이라고 생각하는 것은 당연한 일이므로이를 암시하고 싶지 않습니다. 프로세스가 합리적이거나 최소한 더 안전한 수준으로 제한되면 실제로 진행중인 작업을 식별 할 수 있습니다. (Apache에는 다른 제한 제어 기능이 있지만 이것이 내 전문 분야는 아닙니다.)

"모범 사례"는 물론 다른 하드웨어에서 데이터베이스를 실행하여 응용 프로그램이 데이터베이스를 종료 할 수 없도록하는 것입니다. 하나의 머신을 공유함으로써 "이용률을 최대화"하는 것이 표면 상으로는 더 효율적인 것처럼 보이지만 이것은 잘못된 경제입니다. 일반적인 워크로드에서 MySQL이 사용하는 대부분의 메모리는 시작시 할당되며 MySQL 서버가 실행되는 한 유지됩니다. CPU에 대한 요구는 궁극적으로 동일한로드를 제공하기 때문에 MySQL과 Apache의 피크 시간을 공유 할 가능성이 높습니다. 실제로 단일 m1.xlarge 대신 두 개의 m1.large 머신을 사용하는 것이 더 나을 수 있으며, 작은 머신은 큰 머신의 가격의 절반에 해당하므로 비용은 동일합니다. 추가 할인을 위해이 변경을 수행 할 수 있습니다 .

확인해야 할 사항이 있습니다.

-/ var / log / messages 확인 : 사용할 메모리가 더 없으면 oomkiller가 mysql 프로세스를 종료 할 수 있습니다. 캐시없이 free -lm으로 램 확인

-prefork mpm과 함께 아파치를 사용하는 경우 : 프로세스 수를 확인하십시오. 아파치가 mysql에 대한 링크로 많은 수의 프로세스 (과중한 워크로드 동안)를 쌓으면 지연 시간과 사용 된 메모리가 빠르게 증가 할 수 있습니다.

show global status : mysql이 시작한 스레드 수를 확인하십시오 : threads_cached, threads_created 및 threads_running은 확인하는 것이 중요합니다 (threads_created는 0에 가까워 야합니다).

-Mysql에서 사용하는 램을 확인하십시오.

mysql을 위해 cpusets 을 구현 하고 리소스를 예약 할 수도 있습니다 . 이는 다른 하드웨어에서 이러한 서비스를 실행하는 데 가장 가깝지만 여전히 단일 서버를 유지 관리하는 이점을 제공합니다.