max_heap_table_size 값을 늘리면 MySQL이 충돌합니다.

Question 1

120GB의 메모리를 사용하면 컴퓨터에 여러 개의 물리적 CPU와 NUMA(Non-Uniform Memory Access) 아키텍처가 있을 수도 있습니다. 그렇다면 사용 가능한 메모리가 충분할 수 있지만 여전히 반직관적으로는 사용 가능한 메모리가 부족합니다.

지금까지 순조롭게 진행 중이라면 MySQL이 테이블에 할당된 메모리를 늘리려고 시도할 때 이 문제가 발생할 수 있으며 MEMORY, 이 아키텍처에서 실행될 때 Linux가 메모리 할당을 처리하는 방식과 관련된 오류가 발생했을 수 있습니다. 마더보드의 다른 곳에서 사용 가능한 다른 물리적 메모리가 있음에도 불구하고 메모리 요청이 처리되는 "하나"로 임의로 선택된 하나의 특정 CPU에 직접 연결된 메모리 스틱에 있는 사용 가능한 메모리를 고려합니다. .

NUMA는 이론적으로는 괜찮지만 MySQL의 경우처럼 대량의 메모리가 필요한 단일 프로세스에는 이상적으로 적합하지 않을 수 있습니다. 하지만 해결 방법이 있습니다.

mysqld_safe해결 방법은 다음 줄을 추가하여 스크립트를 수정하는 것입니다 .

cmd="/usr/bin/numactl --interleave all $cmd"

...즉시~ 후에이 줄...

cmd="$NOHUP_NICENESS"

그 이유는 이 아키텍처를 사용하는 MySQL 서버가 여유 메모리에도 불구하고 과도하게 스왑하는 이유를 설명하기 위해 원래 작성된 훌륭한 기사에서 설명됩니다. 그러나 그것은 저자가 지적한 더 큰 문제의 증상이었습니다.그후"완전히 스와핑 문제는 아니며, 스왑이 비활성화된 경우에도 "메모리 할당 실패"가 포함될 수 있다고 지적했습니다.

http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

물론 이것이 귀하의 시스템에 적용되는지 추측하고 있지만 그럴만한 가치가 있는 것 같습니다. 64GB InnoDB 버퍼 풀을 프로비저닝하려고 할 때 새 128GB 시스템에서 문제가 발생했을 때 이 수정 사항을 정확하게 사용했는데 MySQL이 다음이 포함된 시스템에서 여유 공간이 있는 64GB를 찾을 수 없었습니다.아무것도 아님다른 실행 중입니다. 내가 성공적으로 사용할 수 있는 가장 높은 값은 4개의 코어가 포함된 16코어 시스템의 전체 메모리의 1/4 미만이라는 것을 깨달았을 때물리적프로세서 ... 당신이 부딪히는 것 같은 일종의 ... 문제의 본질에 관해 조각을 모을 때였습니다.

Answer

120GB의 메모리를 사용하면 컴퓨터에 여러 개의 물리적 CPU와 NUMA(Non-Uniform Memory Access) 아키텍처가 있을 수도 있습니다. 그렇다면 사용 가능한 메모리가 충분할 수 있지만 여전히 반직관적으로는 사용 가능한 메모리가 부족합니다.

지금까지 순조롭게 진행 중이라면 MySQL이 테이블에 할당된 메모리를 늘리려고 시도할 때 이 문제가 발생할 수 있으며 MEMORY, 이 아키텍처에서 실행될 때 Linux가 메모리 할당을 처리하는 방식과 관련된 오류가 발생했을 수 있습니다. 마더보드의 다른 곳에서 사용 가능한 다른 물리적 메모리가 있음에도 불구하고 메모리 요청이 처리되는 "하나"로 임의로 선택된 하나의 특정 CPU에 직접 연결된 메모리 스틱에 있는 사용 가능한 메모리를 고려합니다. .

NUMA는 이론적으로는 괜찮지만 MySQL의 경우처럼 대량의 메모리가 필요한 단일 프로세스에는 이상적으로 적합하지 않을 수 있습니다. 하지만 해결 방법이 있습니다.

mysqld_safe해결 방법은 다음 줄을 추가하여 스크립트를 수정하는 것입니다 .

cmd="/usr/bin/numactl --interleave all $cmd"

...즉시~ 후에이 줄...

cmd="$NOHUP_NICENESS"

그 이유는 이 아키텍처를 사용하는 MySQL 서버가 여유 메모리에도 불구하고 과도하게 스왑하는 이유를 설명하기 위해 원래 작성된 훌륭한 기사에서 설명됩니다. 그러나 그것은 저자가 지적한 더 큰 문제의 증상이었습니다.그후"완전히 스와핑 문제는 아니며, 스왑이 비활성화된 경우에도 "메모리 할당 실패"가 포함될 수 있다고 지적했습니다.

http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

물론 이것이 귀하의 시스템에 적용되는지 추측하고 있지만 그럴만한 가치가 있는 것 같습니다. 64GB InnoDB 버퍼 풀을 프로비저닝하려고 할 때 새 128GB 시스템에서 문제가 발생했을 때 이 수정 사항을 정확하게 사용했는데 MySQL이 다음이 포함된 시스템에서 여유 공간이 있는 64GB를 찾을 수 없었습니다.아무것도 아님다른 실행 중입니다. 내가 성공적으로 사용할 수 있는 가장 높은 값은 4개의 코어가 포함된 16코어 시스템의 전체 메모리의 1/4 미만이라는 것을 깨달았을 때물리적프로세서 ... 당신이 부딪히는 것 같은 일종의 ... 문제의 본질에 관해 조각을 모을 때였습니다.

Question 2

에 대한 문서tmp_table_size이 설정은 임시 테이블의 최대 크기라고 말합니다.메모리 내. 해당 크기를 초과해도 테이블이 가득 차면 오류가 발생하지 않습니다. 이는 메모리의 테이블 사용에서 디스크의 MyISAM 테이블 사용으로의 변경을 트리거합니다.

임시 테이블이 필요한 것보다 더 많은 메모리를 사용하도록 허용했기 때문에 시스템이 충돌하고 있습니다. 메모리 테이블도 마찬가지입니다.

tmp_table_size를 삭제해야 합니다.방법아래에. 이 설정은 전체 최대값이 아니라는 점을 기억하세요. 임시 테이블당 최대값입니다. 엄청나게 큰 임시 테이블(예: 각각 20GB 미만)을 만드는 5개의 쿼리가 있는 경우 이제 최대 100GB의 RAM을 사용하는 임시 테이블이 있습니다. 6번째를 추가하면 서버 전체보다 더 많은 RAM을 사용하게 됩니다.

스크립트가 실제로 MEMORY 스토리지 엔진을 사용하는 경우 변경 사항을 검토한 후 MyISAM 파일에 데이터를 기록하십시오. 대규모 임시 테이블에서 그렇게 빠른 성능이 정말로 필요하다면 더 빠른 스토리지를 확보해야 합니다(예:퓨전아이오,비리덴트외). 그것이 과도하거나 너무 비싸다면 최소한 소비자급 SSD를 고려해 보겠습니다.

MyISAM은 데이터가 시스템 메모리(사용되지 않은 RAM)에 캐시될 때 가장 잘 수행됩니다. 스크립트가 대용량 쿼리(MEMORY 엔진 사용)를 할 때마다 캐시를 날려버리면 MyISAM 성능이 저하될 것입니다.

나는 스크립트가 실제로 성능을 저하시킬 때 성능을 '향상'시키기 위해 MEMORY 스토리지 엔진을 사용하고 있다고 의심합니다. 임시 테이블인 경우 임시 테이블을 사용해야 하며 tmp_table_size는 훨씬 작아야 하며 tmp_table_size가 중단된 후 디스크에 강제로 저장되어야 합니다.

max_heap_table_size 및 tmp_table_size의 기본값은 모두 16MB입니다. 가능하다면 설정을 다시 기본값으로 변경하는 것이 좋습니다. 데이터 세트에 적합한 설정을 찾을 때까지 리소스 사용량(디스크 I/O, 총 메모리 사용량, CPU 사용량 등)을 모니터링하면서 조금씩 위쪽으로 조정하세요.

Answer