MySQL : "최대 메모리 사용량"을 어떻게 줄이나요?

최근 메모리 부족으로 인해 스 래싱에 문제가 있습니다. (내 VPS는 총 256M입니다)

mysqltuner.pl을 사용하여 MySQL을 조정하려고 시도하고 다음 결과를 얻습니다.

-------- 일반 통계 ---------------------------------------- ----------
[-] MySQLTuner 스크립트의 버전 확인을 건너 Skip
[확인] 현재 지원되는 MySQL 버전 5.0.51a-3ubuntu5.4-log를 실행 중
[확인] 64 비트 아키텍처에서 작동

-------- 스토리지 엔진 통계 --------------------------------------- ----
[-] 상태 : + 아카이브 -BDB-연합 -InnoDB -ISAM -NDBCluster 
[-] MyISAM 테이블의 데이터 : 114M (테이블 : 454)
[!!] 총 조각 테이블 : 34

-------- 성능 지표 ---------------------------------------- ---------
[-] 최대 : 40 초 (570q [14.250qps], 23 개 연결, TX : 154K, RX : 23K)
[-] 읽기 / 쓰기 : 100 % / 0 %
[-] 총 버퍼 : 338.0M 글로벌 + 스레드 당 2.7M (최대 스레드 20 개)
[!!] 가능한 최대 메모리 사용량 : 392.9M (설치된 RAM의 153 %)
[확인] 느린 쿼리 : 0 % (5/570)
[확인] 사용 가능한 최대 연결 사용량 : 15 % (3/20)
[!!] 키 버퍼 크기 / 총 MyISAM 인덱스 : 8.0M / 9.4M
[!!] 키 버퍼 적중률 : 57.1 % (7 캐시 / 3 읽기)
[확인] 쿼리 캐시 효율 : 21.9 % (7 캐시 / 32 선택)
[확인] 하루에 캐시 캐시 제거 : 0
[확인] 임시 테이블이 필요한 정렬 : 0 % (0 임시 정렬 / 1 정렬)
[확인] 디스크에서 생성 된 임시 테이블 : 0 % (디스크에서 0 / 총 32)
[OK] 스레드 캐시 적중률 : 86 % (3 개 생성 / 23 개 연결)
[OK] 테이블 캐시 적중률 : 26 % (128 개 열림 / 484 개 열림)
[확인] 열린 파일 사용 한도 : 25 % (259 / 1K)
[OK] 즉시 획득 한 테이블 잠금 : 100 % (492 즉시 / 492 잠금)

-------- 권장 사항 ----------------------------------------- ------------
일반적인 권장 사항 :
    성능 향상을 위해 OPTIMIZE TABLE을 실행하여 테이블 조각 모음
    MySQL은 지난 24 시간 이내에 시작되었습니다. 권장 사항이 정확하지 않을 수 있습니다
    시스템 안정성을 위해 전체 MySQL 메모리 공간을 줄입니다.
조정할 변수 :
  *** MySQL의 최대 메모리 사용량이 위험합니다 ***
  *** MySQL 버퍼 변수를 늘리기 전에 RAM 추가 ***
    key_buffer_size (> 9.4M)

그러나 최대 메모리 사용량을 줄이는 방법에 대해 약간 혼란 스럽습니까? key_buffer 및 max_connections를 기반으로하는 것 같지만 다른 것도 필요합니까?

my.cnf :

key_buffer = 8M
max_allowed_packet = 12M
thread_stack = 128K
thread_cache_size = 8
max_connections = 20
table_cache = 128
tmp_table_size = 256M
max_heap_table_size = 256M
join_buffer_size = 256K
query_cache_limit = 8M
query_cache_size = 64M

나는 MySQL 튜닝 기사를 읽으려고 노력했지만 이미 무엇을하고 있는지 이미 알고있는 사람들을위한 것으로 보인다! 도움을 주시면 감사하겠습니다. 감사!

256M의 서버가 있지만 모든 것을 사용할 수는 없습니다. OS 오버 헤드가 있다는 것을 기억하십시오. 다른 사람들이 언급했듯이 커밋을 끝내고 여기에 쏟을 것입니다. 256M은 작은 DB에만 충분하며 20 개의 연결은 구성한 내용과 많은 관계가 있습니다.

1) 최대 연결 수를 4로 줄이십시오 (20 개 중 3 개 사용 중)

2) 쿼리 캐시를 더 잘 최적화하십시오. 8M은 실제로 크며 총 64M은 조회수 / 자두를 기반으로합니다. 4/32 콤보를 시도하고 어떻게 진행되는지 확인하십시오. 정말 2/24 콤보가 효과가 있다고 생각합니다.

3) 임시 테이블을 요구하는 정렬이 없습니다. 왜 거기에 max_heap_table_size 동사가 있습니까? 주석 처리, 기본값 사용

4) 실제로 128 개의 테이블이 있습니까? table_cache를 64 또는 48로 반으로 자르십시오.

5) thread_cache_size를 4로 줄입니다.

6) 조각화를 줄이기 위해 해당 테이블을 최적화하십시오.

이것들은 시작해야 할 것들입니다. 실제 프로파일 링없이 구성에서 많은 수를 던져서 필요한 것을 알고 혼란을 일으킨 것처럼 보입니다. 다른 모든 방법이 실패하면 기본값으로 돌아가서 사용자 지정 설정을 제거하고 Google에서 찾을 수있는 성능 조정 가이드를 사용하여 다시 시작하십시오. SHOW VARIABLES 및 SHOW STATUS의 결과를 얻고, bajillion 튜닝 가이드 중 하나를 찾아 실제 실제 숫자를 방정식에 연결하면 구성 파일에 입력 해야하는 정확한 숫자를 알려줍니다.

나는 MySQL 전문가가 아니며이 정보의 문제를 진단 할 수는 없지만 소스 코드에서 수식을 검색하려고했습니다. 여기있어:

server_buffers + total_per_thread_buffers * max_connections

어디:

server_buffers = key_buffer_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size

과:

total_per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + max_allowed_packet + join_buffer_size

이제 각 값을 확인하고이 숫자를 담당하는 값을 찾아야합니다. 이 스크립트를 예약없이 신뢰하지 마십시오. DB 서버 중 하나에서 스크립트를 실행하려고 시도했으며 최대 메모리가 총 실제 메모리 양의 140 % 인 것으로 계산되었지만 시스템은 몇 년 동안 안정성 문제없이 실행되었습니다.

행운을 빕니다!

올바르게 기억한다면 MySQL Tuner는 다음 공식을 사용하여 최대 사용량을 추정합니다.

read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size

MySQL의 특정 설정에는 정의 된 제한이 없으므로 100 % 정확하지는 않으며 실제로는 추정에 불과합니다.

구성 파일의 일부 설정을 종료하고 튜너를 다시 실행하기 시작할 수 있지만 my.cnf 변경을 낭비하고 다시 시작하고 튜너를 실행하는 데 시간이 없다면 전문가의 도움을받는 것이 좋습니다.

mysqlcalculator.com 소프트웨어를 사용하면 많은 시간을 절약 할 수 있습니다.