MySQL 프로덕션 데이터베이스의 비정상적인 메모리 증가 문제를 해결하는 방법

performance_schema 수정

회사의 생산 환경은 Alibaba Cloud RDS를 사용하기 때문에 매개변수를 수정하는 것이 비교적 편리합니다. 기본performance_schema는 0인데 이번에는 1로 수정합니다. 매개변수를 수정하고 제출한 후에는 업무량이 적을 때 데이터베이스를 다시 시작하는 것이 좋습니다.

메모리 모니터링 켜기

MySQL 데이터베이스에 로그인하고 다음 SQL을 실행한 후 메모리 모니터링을 켜세요.

update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';

개봉 후 확인하세요.

select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;

**참고: **이 명령은 온라인으로 메모리 통계를 열기 위한 것이므로 열기 전 새로 추가된 메모리 개체만 계산됩니다. 일정 시간 동안 기다리는 것이 좋습니다. 다음 단계를 수행하기 전에 메모리 사용량이 많은 스레드를 쉽게 찾을 수 있습니다.

메모리 소비 찾기

통계 이벤트는 메모리를 소비합니다

select event_name,
       SUM_NUMBER_OF_BYTES_ALLOC
from performance_schema.memory_summary_global_by_event_name
order by SUM_NUMBER_OF_BYTES_ALLOC desc
LIMIT 10;
+---------------------------------------+-------------------------------------+
| event_name                            | SUM_NUMBER_OF_BYTES_ALLOC           |
+---------------------------------------+-------------------------------------+
| memory/sql/Filesort_buffer::sort_keys | 763523904056                        |
| memory/memory/HP_PTRS                 | 118017336096                        |
| memory/sql/thd::main_mem_root         | 114026214600                        |
| memory/mysys/IO_CACHE                 | 59723548888                         |
| memory/sql/QUICK_RANGE_SELECT::alloc  | 14381459680                         |
| memory/sql/test_quick_select          | 12859304736                         |
| memory/innodb/mem0mem                 | 7607681148                          |
| memory/sql/String::value              | 1405409537                          |
| memory/sql/TABLE                      | 1117918354                          |
| memory/innodb/btr0sea                 | 984013872                           |
+---------------------------------------+-------------------------------------+

메모리 소비가 가장 많은 이벤트는 Filesort_buffer라는 것을 알 수 있습니다. 이는 정렬과 관련이 있을 것입니다.

스레드 메모리 소비 통계

select thread_id,
       event_name,
       SUM_NUMBER_OF_BYTES_ALLOC
from performance_schema.memory_summary_by_thread_by_event_name
order by SUM_NUMBER_OF_BYTES_ALLOC desc
limit 10;
+---------------------+---------------------------------------+-------------------------------------+
| thread_id           | event_name                            | SUM_NUMBER_OF_BYTES_ALLOC           |
+---------------------+---------------------------------------+-------------------------------------+
| 105                 | memory/memory/HP_PTRS                 | 69680198792                         |
| 183                 | memory/sql/Filesort_buffer::sort_keys | 49210098808                         |
| 154                 | memory/sql/Filesort_buffer::sort_keys | 43304339072                         |
| 217                 | memory/sql/Filesort_buffer::sort_keys | 37752275360                         |
| 2773                | memory/sql/Filesort_buffer::sort_keys | 31460644712                         |
| 218                 | memory/sql/Filesort_buffer::sort_keys | 31128994280                         |
| 2331                | memory/sql/Filesort_buffer::sort_keys | 28763981248                         |
| 106                 | memory/memory/HP_PTRS                 | 27938197584                         |
| 191                 | memory/sql/Filesort_buffer::sort_keys | 27701610224                         |
| 179                 | memory/sql/Filesort_buffer::sort_keys | 25624723968                         |
+---------------------+---------------------------------------+-------------------------------------+

메모리를 많이 소비하는 스레드가 Filesort_buffer와 관련이 있는 것을 볼 수 있습니다. Filesort_buffer相关。

定位具体SQL

根据前边我们查到的thread_id

특정 SQL 찾기

앞서 찾은 thread_id를 기반으로 해당 SQL을 찾으려면 로그로 이동하세요. Alibaba Cloud RDS 감사 로그는 비교적 강력합니다. thread_id를 기반으로 직접 검색합니다.

로그에서 그러한 SQL이 많이 발견되었으며, 스캔된 행의 수는 수천에서 수만 개에 이릅니다. 각 쿼리의 시간은 보통 수십~수백 밀리초로 길지 않지만 동시 요청 수는 많습니다. 🎜🎜🎜

위 내용은 MySQL 프로덕션 데이터베이스의 비정상적인 메모리 증가 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!