InnoDB 스토리지 엔진으로 MySQL을 실행하는 애플리케이션을 최적화하려고합니다.다음 innotop 출력을 어떻게 해석 하시겠습니까?
나는 다음과 같은 출력을 얻을 라이브 환경에서 innotop을 실행 :
When Load QPS Slow QCacheHit KCacheHit BpsIn BpsOut
Now 0.00 87.80 0 41.21% 100.00% 11.51k 836.42k
Total 0.00 105.50 190 15.04% 99.34% 13.23k 692.85k
When, Load, QPS 및 Slow은 자명하다.
하지만 무엇에 대해서 QCacheHit, KCacheHit, BpsIn 및 BpsOut? 일반적으로, 그 사람들을 위해 "괜찮은"가치로 간주되는 것은 무엇이며 언제부터 걱정해야합니까?
QCacheHit은 query cache에 기록 된 시간의 백분율입니다. KCacheHit은 innodb buffer pool에 도달 한 시간의 백분율입니다 (key buffer과 유사). BpsIn은 서버에 들어오는 바이트 수이고, BpsOut은 바이트입니다.
QCacheHit은 쿼리 캐시를 사용하는 경우 상대적으로 높아야합니다. 요금이 낮아 보입니다. KCacheHit도 상대적으로 높아야하며 올바른 모양입니다.
BpsIn/Out 서버에서 보내고받는 데이터의 양을 최적화하려고 시도하지 않는 한 실제로는 중요하지 않습니다.
비율은 쓸모가 없습니다. 진지하게. 그냥 무시하십시오. http://www.mysqlperformanceblog.com/2010/02/28/why-you-should-ignore-mysqls-key-cache-hit-ratio/
네, 저는 innotop의 저자입니다. 사람들이 저에게 묻는 것을 멈추게 할 수 있도록 그 기능들을 넣었습니다. 문서에서
:
요약이 문서
주요 포인트 : 그들은 B의) 비율 때문에
- 카운터 비율은 성능 분석 메트릭 과 같은 의미가 있습니다) 카운터.
, 당신은 캐시의 제작자를 신뢰하고 캐시 미스가 아닌 캐시 적중에 대해 다음, 미스 히트보다 더 비싸다는 당신 치료를 가정합니다.
- 비율이 아닌 절대 크기를 관찰해야합니다.
- 성능 분석을 위해 횟수만큼 경과 시간을 측정하려면 이 필요합니다. 타이밍 정보가없는 경우
- Key_read가 임의의 물리적 I/O 일 수는 없지만 일 수 있습니다. Key_reads/Uptime을 10 초 또는 60 초에 걸쳐 간격으로 수집하고 그 결과를 IO 시스템의 기능과 비교하십시오.
- MySQL은 key_buffer_size 설정을 과학적으로 선택하기위한 좋은 계측 도구가 없지만 비율 기반 튜닝보다 나은 비 과학적 접근 방식이 많습니다.
- MyISAM 튜닝뿐만 아니라 카운터 비율이 모든 것을 빨아들입니다.
나는이 점들에 대해 뜨거운 논쟁을 벌여 왔기 때문에 논란도없이 을 넘기를 기대하지 않는다. 그러나 실제로는 카운터 비율에 대한 나쁜 조언으로 을 멈출 때입니다. 더 빨리 일을 수행하면 더 일을 더 빨리 수행 할 수 있습니다.