MySQL query_cache_limit query_cache_size 튜닝
query_cache_list, query_cache_size, sort_buffer_size, read_rnd_buffer_size 에 대해서 알아보겠습니다.
아래는 phpMyAdmin 에서 제공하는 시스템 분석 문구입니다.
▶ query_cache_limit, query_cache_size
이슈:
쿼리 캐시의 80% 미만이 활용되고 있습니다.
추천:
This might be caused by query_cache_limit being too low. Flushing the query cache might help as well.
인증:
전체 쿼리 캐시 크기(Size)에서 남은 쿼리 캐시 메모리의 현재 비율은 10% 입니다. 80%보다 높아야 됩니다
사용된 변수 / 수식:
100 - Qcache_free_memory / query_cache_size * 100
추천에는 query_cache_limit 값이 너무 낮아서 그럴 수 있다고 하는군요~
query_cache_limit 디폴트 값이 1MB 인데 사용되는 쿼리에 따라 달라지므로 무조건 높인다고 좋은 건 아닌 것 같습니다.
대부분의 환경에서는 query_cache_limit 값을 올려 주면 비율은 올라갈 겁니다.
하지만 용량이 큰 쿼리결과 값이 채워지면 캐시되는 수가 전체적으로 줄어들게 됩니다.
그리고 query_cache_min_res_unit 의 default 값이 4096 인데 이 값을 줄여도 캐시 비율을 올릴 수 있습니다.
하지만 값을 너무 낮추게 되면 단편화가 심해질 것 입니다.
하루가 지나도 쿼리 캐시 비율이 10% 근처에 머물고 있다면 query_cache_size 가 너무 커서 그럴 수 있습니다.
이런 경우에는 query_cache_size 를 줄여서 확인이 필요합니다.
▶ sort_buffer_size, read_rnd_buffer_size
이슈:
너무 많은 정렬로 인해 임시 테이블의 사용이 발생합니다.
추천:
시스템의 메모리 한계값에 따라 sort_buffer_size 나 read_rnd_buffer_size 값을 증가시키세요
인증:
임시 테이블 평균: 22.33 시간당, 이 값은 시간당 1보다 작아야합니다.
사용된 변수 / 수식:
Sort_merge_passes / Uptime
테스트:
value * 60 * 60 > 1
상태 값에서 Sort_merge_passes 값을 모니터링 해서 값이 증가하면 sort_buffer_size 와 read_rnd_buffer_size 값을 증가시켜서 다시 확인을 합니다.
Sort_merge_passes 값이 변화가 없거나 아주 조금씩 증가하면 튜닝이 됐다고 보면 됩니다.
