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 머신을 사용하는 것이 더 나을 수 있으며, 작은 머신은 큰 머신의 가격의 절반에 해당하므로 비용은 동일합니다. 추가 할인을 위해이 변경을 수행 할 수 있습니다 .

답변