2016-10-27 3 views
0

DB가 16GB이고 운영 체제가 4TB 인 쿼드 코어 프로세서가 있습니다. 할당 된 버퍼 풀은 6GB입니다. 70 %의 메모리로 시도했지만 결과는 동일합니다. 메모리가 빠르게 가득 찼습니다. 서비스를 다시 시작하면 해제되지만 20-15 분이 채 안되어 10-15 %가 채워집니다.MariaDB 과도한 메모리 사용량

내 my.conf의 설정 :

[client] 
socket=/db/mysql/mysql.sock 

[mysqld] 
datadir=/db/mysql 
socket=/db/mysql/mysql.sock 

innodb_max_dirty_pages_pct = 0 
innodb_file_per_table = 1 
innodb_buffer_pool_size = 6G 
innodb_buffer_pool_instances = 6 
thread_cache_size = 4 
innodb_flush_log_at_trx_commit = 2 
innodb_flush_method = O_DIRECT 
innodb_flush_log_at_trx_commit = 2 
innodb_flush_method = O_DIRECT 
query_cache_type = 0 
innodb_fast_shutdown=0 

[mysqld_safe] 
log-error=/var/log/mariadb/mariadb.log 
pid-file=/var/run/mariadb/mariadb.pid 

너무 내 메모리 사용량 그래프를 부착. enter image description here

enter image description here

enter image description here

중요 참고 :

표시 변수 - pastebin.com/wzAhva55 보기 글로벌 상태 - pastebin.com/8G1N3g78

+0

더 많은 정보가 유용 할 것입니다. SHOW ENGINE InnoDB STATUS의 버퍼 풀/메모리 섹션. 느린 쿼리 로그에 몇 가지 정보가 포함되어 있습니까? 정렬 버퍼를 사용하여 느린 쿼리? SHOW PROCESSLIST의 장기 실행 프로세스는 무엇입니까? –

+0

InnoDB Satus - http://pastebin.com/Hxi6S5f8 Show ProcessList - http://pastebin.com/ftTiDSrC 출력이 너무 길어서 pastebin을 사용해야했습니다. –

+0

그래프상의 Y 액시스의 의미와 단위는 무엇입니까? –

답변

2

관찰 :

당신이 BUFFER_POOL에 대해 "좀 작은"6G이 때문에 RAM이 가득 이유, 그것은 기괴
Version: **5.5.50-MariaDB** 
**16 GB** of RAM 
Uptime = **3d 05:16:26** 
You are **not** running on Windows. 
Running **64-bit** version 
You appear to be running entirely (or mostly) **InnoDB**. 
20 issues flagged, out of 145 computed Variables/Status/Expressions checked 

더 중요한 문제

  • .
  • 복제가 필요하지 않습니다. 맞습니까?
  • innodb_max_dirty_pages_pct이 0으로 설정 되었습니까? 일반적으로 75 (%)입니다. 나는 당신이 많은 I/O를 겪을 것을 기대합니다.
  • iblog가 매우 빠르게 회전하고 있습니다. 이것은 매우 활동적이며, 매우 작은 log_file_size = 5M과 함께 있습니다. 1G로 변경하십시오. 그러나주의 : 변경은 복잡하고 재시작이 필요합니다.
  • 초당 6,000 개의 tmp 테이블이 생성되었습니다. 3K 테이블 스캔/초. 이는 일부 인덱스 또는 쿼리 조정이 유용 할 수 있음을 의미합니다.
  • 연결이 너무 낮아서 스레드 및 연결에 대한 아래의 주석은 중요하지 않을 수 있습니다.
  • Aborted_connects/Connections = 98.8 %. (최대 20 %는 '확인'입니다.)

RAM 디스크가 있습니까? 얼마나 큰? 나는 그런 주장에 반대한다. 그러나 RAM 디스크를 사용하면 높은 메모리 사용량, 높은 쿼리 속도 및 낮은 I/O 문제가있는 것으로 나타납니다.

세부 사항 및 기타 관찰

(innodb_buffer_pool_size/_ram) = 6,442,450,944/16384M = 37.5% - RAM의 %는 이노 BUFFER_POOL에 사용

(open_files_limit) = 1,024 - ulimit를 -n - 더 많은 파일이 ulimit를 변경 허용하려면 또는/etc/보안/limits.conf 또는 sysctl.conf (kern.maxfiles & kern.maxfilesperproc) 또는 다른 것 (OS에 따라 다름) 반면에 Open_table* 값은 매우 낮으므로 매우 적은 테이블을 사용하고있는 것으로 보입니다.

(innodb_max_dirty_pages_pct) = 0 - buffer_pool이 디스크로 플러시를 시작하는 경우 - 실험 중이십니까?

(Innodb_log_writes) = 26,966,874/278186 = 97 /sec

(Innodb_os_log_written/(Uptime/3600)/innodb_log_files_in_group/innodb_log_file_size) = 253,091,451,392/(278186/3600)/2/5M = 312 - 비율

(Uptime/60 * innodb_log_file_size/Innodb_os_log_written) = 278,186/60 * 5M/253091451392 = 0.096 - 5.6.8부터 이노 로그 회전 분 사이, 이것은 동적으로 변경 될 수있다; my.cnf도 변경해야합니다. - 회전 사이의 권장 간격은 다소 임의적입니다. innodb_log_file_size를 조정하십시오.

(Questions) = 889,470,233/278186 = 3197 /sec - (SP 외부) 쿼리 - "QPS" -> 2,000 서버에게

(Queries) = 85,684,886,985/278186 = 308012 /sec 강조 될 수있다 -> 3000 수있다 - 하면 (SP에 포함하는) 검색어 스트레스 서버

((Queries-Questions)/Queries) = (85684886985-889470233)/85684886985 = 99.0% - 저장된 루틴 내에있는 쿼리의 일부. - 높은 경우 나쁘지 않지만 다른 결론의 유효성에 영향을 미칩니다.

(Created_tmp_tables) = 1,674,262,702/278186 = 6018 /sec - 복잡한 SELECT의 일부로 "temp"테이블을 생성하는 빈도.

(Select_scan) = 837,131,930/278186 = 3009 /sec - 풀 테이블 스캔 - (그들은 작은 테이블하지 않는 한) 쿼리를 최적화/인덱스를 추가

(Select_scan/Com_select) = 837,131,930/2511393099 = 33.3% - 전체 테이블 스캔을하고 선택의 %. (스토어드 루틴에 속지 수 있습니다.) - 일반 드라이브

을의 것 밖으로 아마 최대 I/O 쓰기 능력을 50 쓰기/초 + 플러시 로그 - 기록/초 을 -

(Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi) = (837130735 + 0 + 0 + 0 + 0 + 0)/278186 = 3009 /sec 쿼리를 최적화/인덱스를 추가

(expire_logs_days) = 0 - 얼마나 자주 binlog를 자동으로 제거할지 (이 이후 여러 날) - 너무 큼 (또는 0) = 디스크 공간을 소비합니다. 너무 작습니다. 네트워크/시스템 충돌에 신속하게 대응해야합니다. (log_bin = OFF 인 경우 관련 없음)

(long_query_time) = 10.000000 = 10 - "느린"쿼리를 정의하기위한 단락 (초). - 제안 2

(Aborted_connects/Connections) = 11,455/11594 = 98.8% - 아마도 해커가 침입하려고합니까?

(thread_cache_size) = 4 - (스레드 풀링을 사용하는 경우 관련 없음)의 주위에 유지하는 방법 많은 여분의 프로세스 (5.6.8의로 Autosized을, max_connections의 기준)

Select_scan/Com_select가 너무 가까이 수행 한 쿼리에 강한 패턴이 있다는 것은 의심스러운 1/3입니다. 아마도 피할 수있는 반복이 있을까요? 마찬가지로 Com_set_option/Queries은 1/6에 매우 가깝습니다.

Handler_read* 값은 쿼리 수에 비해 극히 적습니다.

hmmm ... Select_scan/초, Com_call_procedure/초 및 Com_insert/초 모두 모두 매우 유사합니다 (3009/초). 단 하나의 절차, 그리고 그것은 많이 불린다?

Innodb_rows_inserted = 622/초.

죄송합니다.이 분석의 대부분은 메모리가 아니라 성능을 목표로합니다. 나는 하나의 기억을 생각해 냈다. 램 디스크가 4-5G라고 생각 하나?

+0

6G 메모리 사용량에서 버퍼 풀을 10G로 늘리 자마자 98 %로 증가했습니다. 그래서 다시 6G로 되돌아갔습니다. innodb_max_dirty_pages_pct를 기본으로 설정했습니다. my.cnf에서 innodb_log_file_size = 1G를 변경할 수 없습니다. 오류가 발생합니다. –

+0

램 디스크가 있습니까? –

+0

df -h에는 7.7GB의 tmpfs가 있습니다. 주요 질문과 함께 첨부 된 스크린 샷. 그러나 나는 이것들을 만들지 않았다. 그것은 기본적으로 모든 것이 었습니다. (sdc가 DB 드라이브 임) –