MySQL OOM 시리즈 3: MySQL이 죽는 불운을 없애다_MySQL

이전 두 장에서는 Linux 메모리 할당 전략을 분석했으며 Linux는 다른 애플리케이션과 마찬가지로 운영 체제에서 허용하는 범위 내에서 초과할 수 있는 OOM_Killer 메커니즘을 사용하여 "초과 예약"으로 인한 위험을 해결했습니다. 일반적으로 대부분의 사람들은 Innodb_buffer_pool이 실제 물리적 메모리보다 작아야 하며 그렇지 않으면 MySQL이 시작되지 않는다는 것을 이해합니다. 사실 이것은 오해입니다. 이것은 MySQL 계층에 의해 제어되지 않습니다. 이는 운영 체제(OS) 계층에 의해 제어됩니다. 앞서 언급한 /proc/sys/overcommit_memory는 OS가 "초과 예약"을 허용하는지 여부를 제어합니다. "초과 예약"이 허용되면 Innodb_buffer_pool은 실제 메모리 공간 크기를 훨씬 초과할 수 있지만 공간의 이 부분은 사용되지 않습니다. 작은 실험을 할 수 있습니다. 아래 그림을 참조하세요.

MySQL의 Innodb_buffer_pool은 5G로 설정되어 있지만 실제 메모리는 3G에 불과합니다.
많은 이야기를 했다면 이제 본격적으로 OS에 의해 RDS 인스턴스가 종료되는 것에 대해 처음 언급한 문제로 돌아가 보겠습니다. 앞서 언급했듯이 인스턴스의 사용 가능한 메모리가 부족하면 일반적으로 MySQL이 첫 번째가 됩니다. OOM_Killer를 선택하세요. 여기에는 두 가지 문제가 관련되어 있습니다.

1. 메모리가 부족한 이유는 무엇인가요?
2. MySQL이 죽임을 당하는 불운에서 벗어나는 방법은 무엇입니까?
먼저 첫 번째 질문부터 살펴보겠습니다. 메모리가 부족한 문제에는 여러 가지 이유가 있지만 크게 두 가지 측면으로 볼 수 있는데, 첫 번째는 MySQL 자체의 메모리 계획에 문제가 있다는 것입니다. 두 번째는 일반적으로 MySQL을 배포하는 서버는 많은 모니터링 또는 예약된 작업 스크립트를 배포하며 이러한 스크립트에는 필요한 메모리 제한이 부족한 경우가 많아 피크 기간 동안 많은 양의 메모리가 점유되어 Linux OOM_Killer 메커니즘이 트리거되고 MySQL 희생된 것입니다.
그렇다면 MySQL이 죽임을 당하는 불운에서 어떻게 벗어날 수 있습니까? MySQL이 종료되는 근본 원인은 Linux의 초과 예약된 메모리 할당 메커니즘에 있습니다. 앞서 언급한 것처럼 이러한 초과 예약 메커니즘이 존재하는 한 특정 애플리케이션이 종료되는 위험을 완전히 방지하는 것은 불가능합니다. MySQL이 종료되는 것을 방지하기 위해 운영 체제는 실제 메모리 공간을 넘어서는 메모리 할당만 금지할 수 있습니다. 그러나 앞서 언급했듯이 MySQL이 배포된 서버에서는 이를 권장하지 않습니다. 왜냐하면 많은 MySQL의 메모리가 방금 적용되었고 즉시 사용되지 않기 때문입니다. OS가 초과 예약을 금지하면 이는 MySQL 자체 메모리에만 영향을 미치지 않습니다. 계획에서는 더욱 엄격한 요구 사항을 제시하고 메모리 활용도가 부족하다는 문제도 있습니다. 동시에 각 MySQL 연결의 개인 메모리는 동적으로 할당됩니다. 할당되지 않으면 서버 충돌이 직접 발생하여 MySQL 충돌 위험도 높아집니다.
운영 체제에 의해 제한되고 완전히 종료되는 것을 피할 수 없기 때문에 MySQL이 종료될 확률을 줄이려고 노력할 뿐입니다. 저는 최소한 다음 3가지를 할 수 있다고 생각합니다.

1) MySQL의 메모리 사용량을 합리적으로 계획하십시오.
2) OOM_adj 매개변수를 조정하여 OOM_Killer에 의해 잠긴 MySQL의 우선순위를 낮춥니다.
3) 메모리 모니터링 및 경보를 강화합니다. 일단 경보가 발생하면 DBA는 신속하게 개입하여 더 많은 메모리를 차지하는 일부 연결을 종료해야 합니다.