MySQL 슬레이브가 oom-killer 솔루션을 트리거합니다_MySQL

최근 MySQL 인스턴스에서 메모리 부족과 유사한 알람 메시지를 자주 받습니다. 서버에 로그인하면 MySQL이 메모리를 99% 소모하고 있는 것을 발견했습니다.

가끔 시간 내에 처리되지 않으면 커널이 MySQL을 다시 시작하고 dmesg 정보에 다음과 같은 기록이 있는 것을 확인할 수 있습니다.

3월 9일 11:29:16 xxxxxx 커널: mysqld가 oom-killer를 호출함: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
3월 9일 11:29:16 xxxxxx 커널: mysqld cpuset=/ mems_allowed=0
3월 9일 11:29:16 xxxxxx 커널: Pid: 99275, comm: mysqld 오염되지 않음 2.6.32-431.el6.x86_64 #1
3월 9일 11:29:16 xxxxxx 커널: 호출 추적:

이제 구체적인 장면을 설명하세요.

주요 전제: 운영 체제 및 MySQL 버전:

OS: CentOS 릴리스 6.5(최종) 커널: 2.6.32-431.el6.x86_64(물리적 머신)
MySQL: Percona 5.6.23-72.1-log(단일 인스턴스)

트리거 시나리오: 슬레이브는 다른 링크가 들어오는지 여부에 관계없이 주기적인 메모리 급증을 경험하여 커널 oom-killer를 트리거합니다.

이 문제가 1년 넘게 계속 발생하고 있다고 하는데, 여기 막 왔더니 사장님께서 단서를 찾을 수 있는지 다시 확인해 보라고 하셔서 이 문제부터 확인해 보겠습니다.

1. MySQL에 할당된 메모리가 무리한 것이 아닌가 의심되어 innodb_buffer_pool의 크기와 물리 메모리의 크기를 확인해 본 결과 BP에 할당된 크기가 물리 메모리의 약 60%를 차지하고 있는 것으로 나타났습니다. 원인은 아니고 삭제되었습니다. 이게 문제라면 진작에 발견했어야죠~
2. 운영 체제의 매개변수 구성을 확인하십시오. [vm.swappiness = 1 ; /proc/sys/vm/overcommit_memory ; oom_adj ] 문제를 해결하기 전에 임시로 adj 매개변수를 -15 또는 직접 -17로 설정하면 커널이 mysql을 종료하지 않습니다. 문제를 근본적으로 해결할 수 없으며 특정 위험이 있습니다. 메모리가 필요하지만 할당할 수 없는 경우 MySQL이 중단될 수 있습니까? 이 방법을 생각해 보세요.
3. 글쎄요, mysql 초기화 매개변수와 운영체제 매개변수는 부적절한 구성이 없는 것 같습니다. 그렇다면 MySQL 자체를 찾아보자!

MySQL 메모리가 급등했는데, 메모리 할당 때문에 발생하는 걸까요? 온라인에서 보고된 MySQL 메모리 할당으로 인한 버그에 따르면, 제 환경에서도 작동해 보겠습니다. 1. 현재 MySQL 프로세스가 차지하는 메모리 크기를 기록합니다. 3. 플러시 테이블을 실행합니다. 4. MySQL 프로세스가 차지하는 크기를 기록합니다. , 주로 Flush Table을 실행하기 전과 Flush Table을 실행한 후에 MySQL이 할당한 메모리에 명백한 변화가 있는지 확인하기 위한 것입니다. 글쎄, 이 버그는 더 이상 나에게 없는 것 같습니다.

이 버전을 살펴보면 innodb_buffer_pool_instances 매개변수가 있는데 공식 웹사이트에는 innodb_buffer_pool_instances 및 innodb_buffer_pool_size의 부적절한 설정으로 인해 발생하는 버그가 있습니다. 예를 들어 실제 메모리는 64GB이고 innodb_buffer_pool_size = 300GB로 설정하고 innodb_buffer_pool_instances > 5로 설정해도 여전히 MySQL을 가져올 수 있습니다. 그러나 MySQL은 OOM에 취약합니다. 자세한 정보: http://bugs.mysql.com/bug.php?id=79850 여기를 살펴보세요.

또 다른 상황이 있습니다. 버그가 보고되었습니다. 즉, 슬레이브가 필터링을 설정하면 OOM도 트리거되지만 이러한 인스턴스는 설정되지 않았으므로 무시하겠습니다.

MySQL 메모리 초과 구독으로 인한 것이 아니기 때문에 오픈 테이블의 핸들로 인한 것이 아닙니다. 그럼 또 어떤 이유가 있나요?

이 현상은 슬레이브에서 발생합니다. 마스터와 슬레이브 구성은 동일합니다. 다만 마스터가 프로덕션 비즈니스를 실행하고 슬레이브의 일부 인스턴스는 쿼리 비즈니스를 실행합니다. 어떤 작업도 전혀 실행하지 않지만 여전히 OOM이 시작되는 경우 이 상황은 아마도 슬레이브에 의해 발생했을 것입니다.

그러다가 예시를 찾아서 시도해 봤는데 안 해보면 어떨지 모르겠네요. 올라가서 실행해 보았는데, stopslave;startslave 이 명령이 3분정도 멈췄더니 20GB 이상이 한꺼번에 풀렸습니다. 이 시점에서 우리는 기본적으로 문제를 찾았지만 슬레이브에 두 개의 스레드가 있다는 것을 모두 알고 있습니다. 이 문제의 원인은 SQL 스레드입니까 아니면 IO 스레드입니까? 다음번에 이런 일이 발생하면 추가 조사를 기다려야 합니다.

메모리 모니터링 정보 게시:

오후 12:00:01 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
오후 02:40:01 566744 131479292 99.57 88744 618612 132384348 89.19
02:50:01 오후 553252 131492784 99.58 83216 615068 132406792 89.20
오후 03:00:01 39302700 92743336 70.24 95908 925860 132413308 89.21
오후 03:10:01 38906360 93139676 70.54 109264 1292908 132407836 89.21
오후 03:20:01 38639536 93406500 70.74 120676 1528272 132413136 89.21

여기에 좀 더 구체적인 내용을 기록해 두었습니다: https://bugs.launchpad.net/percona-server/+bug/1560304 접속이 불가능하시면 접속하실 수 있습니다(http://www.bitsCN. com/article /88729.htm)

마지막으로 요약:

현상: 슬레이브 OOM
임시 해결책: 슬레이브 재시작
장기적인 솔루션: MySQL Server 마이너 버전 업그레이드

더 체계적으로 살펴보려면 Guo 씨가 쓴 글을 읽어보세요.
http://www.bitsCN.com/article/88726.htm
http://www.bitsCN.com/article/88727.htm