관찰 :
당신이 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라고 생각 하나?
더 많은 정보가 유용 할 것입니다. SHOW ENGINE InnoDB STATUS의 버퍼 풀/메모리 섹션. 느린 쿼리 로그에 몇 가지 정보가 포함되어 있습니까? 정렬 버퍼를 사용하여 느린 쿼리? SHOW PROCESSLIST의 장기 실행 프로세스는 무엇입니까? –
InnoDB Satus - http://pastebin.com/Hxi6S5f8 Show ProcessList - http://pastebin.com/ftTiDSrC 출력이 너무 길어서 pastebin을 사용해야했습니다. –
그래프상의 Y 액시스의 의미와 단위는 무엇입니까? –