MySQL 쿼리 캐싱: 최대 캐시 크기 128MB로 제한?

MySQL 쿼리 캐싱: 최대 캐시 크기 128MB로 제한?

제 애플리케이션은 데이터베이스 집약적이기 때문에 애플리케이션과 MySQL 데이터베이스가 함께 최대한 효율적으로 작동하는지 확인하기 위해 정말 열심히 노력했습니다.

현재 MySQL 쿼리 캐시를 서버에서 실행 중인 쿼리의 특성에 맞게 조정하고 있습니다.

query_cache_size캐시에 저장될 수 있는 최대 데이터 양입니다.query_cache_limit캐시에 있는 단일 결과 집합의 최대 크기입니다.

현재 MySQL 쿼리 캐시는 다음과 같이 구성됩니다.

query_cache_size=128M
query_cache_limit=1M

tuning-primer.sh실행 중인 시스템에 대해 다음과 같은 튜닝 힌트를 제공합니다.

QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 127 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 99.95 %
Current query_cache_min_res_unit = 4 K
However, 21278 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size

그리고.mysqltuner.pl는 다음과 같은 튜닝 힌트를 제공합니다.

[OK] Query cache efficiency: 31.3% (39K cached / 125K selects)
[!!] Query cache prunes per day: 2300654

Variables to adjust:
    query_cache_size (> 128M)

두 튜닝 스크립트 모두 제가 키워야 한다고 제안합니다.query_cache_size. 그러나, 증가하는 것은.query_cache size128M 이상은 성능을 감소시킬 수 있습니다.mysqltuner.pl(http://mysqltuner.pl/) 참조.

이 문제를 어떻게 해결하시겠습니까?쿼리_cache_size를 늘리시겠습니까?mysqltuner.pl경고를 하거나 어떤 식으로든 쿼리 논리를 조정하려고 합니까?대부분의 데이터 액세스는 Hibernate에 의해 처리되지만, 애플리케이션에서도 손으로 코딩된 SQL이 상당히 많이 사용됩니다.

mysqltuner.py 에서 제공하는 경고는 캐시가 스왑될 위험이 없더라도 실제로 관련이 있습니다.이것은 다음과 같이 explained. http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing

기본적으로 MySQL은 캐시 크기가 클수록 캐시를 손질하는 데 더 많은 시간을 소비하며, 중간 정도의 쓰기 부하에서도 캐시가 매우 변동성이 크기 때문에(쿼리가 자주 삭제됨), 너무 크게 설정하면 애플리케이션 성능에 악영향을 미칩니다.조정해요.query_cache_size그리고.query_cache_limit당신의 응용을 위해, 당신이 삽입당 가장 많은 히트를 가지고, 낮은 숫자의lowmem_prunes데이터베이스 서버 로드를 주의 깊게 관찰하는 동시에 그렇게 합니다.

일반적으로 "너무 큰 캐시 크기" 경고는 물리적 메모리가 거의 없기 때문에 캐시 자체를 스왑해야 하거나 필요한 리소스를 사용해야 한다는 가정 하에 표시됩니다.OS(파일 캐시와 같은).

메모리가 충분하다면 증가해도 무방합니다.query_cache size(저는 다음과 같은 설치를 본 적이 있습니다.1GB쿼리 캐시).

하지만 쿼리 캐시를 제대로 사용하고 있는 것이 확실합니까?말 그대로 반복되는 질문이 많습니까?전형적인 문의의 예를 올려주시겠습니까?

캐시를 늘리는 것은 쉬운 일이어야 합니다. 그것은 "그렇게 많이 사용할 수 없는 메모리"가 아닙니다!

예를 들어 매뉴얼을 읽다 보면 다음과 같은 인용문이 나옵니다.

쿼리 캐시의 크기가 지나치게 커 캐시를 유지하는 데 필요한 오버헤드를 증가시켜 캐시를 활성화하는 데 따른 이점을 넘어서지 않도록 주의해야 합니다.일반적으로 수십 메가바이트 단위의 크기가 유용합니다.수백 메가바이트 단위의 크기는 아닐 수 있습니다.

여러분이 확인할 수 있는 다른 다양한 자료들이 있습니다!

0이 아닌 자르기 비율은 쿼리 캐시의 크기를 늘려야 한다는 뜻일 수 있습니다.그러나 캐시를 유지하는 데 드는 오버헤드는 크기에 따라 증가할 가능성이 있으므로 이 작업을 조금씩 수행하고 결과를 모니터링해야 합니다.자투리를 제거하기 위해 캐시 크기를 크게 늘려야 하는 경우, 작업량이 쿼리 캐시에 적합하지 않을 가능성이 높습니다.

따라서 쿼리 캐시에 가능한 한 많은 양을 넣지 마십시오.

가장 좋은 것은 쿼리 캐시를 점진적으로 늘리고 사이트의 성능을 측정하는 것입니다.수행 질문에서는 일종의 디폴트이지만, 이와 같은 경우에는 '테스트'를 하는 것이 최선의 방법 중 하나입니다.

query_cache_size 및 limit 설정에 주의하십시오.MySQL은 쿼리 캐시에서 읽기 위해 단일 스레드만 사용합니다.

query_cache_size를 4G로 설정하고 query_cache_limit 12M을 사용하면 쿼리 캐시 비율이 85%에 달했지만 연결이 반복적으로 급증하는 것을 알 수 있었습니다.

64K query_cache_limit을 사용하여 query_cache_size를 256M으로 변경한 후 쿼리 캐시 비율은 50%로 떨어졌지만 전체 성능은 증가했습니다.

쿼리 캐시에 대한 오버헤드가 약 10%이므로 쿼리 캐싱을 비활성화합니다.일반적으로 적중률이 40% 또는 50%를 초과할 수 없는 경우 쿼리 캐시가 데이터베이스에 적합하지 않을 수도 있습니다.

이 주제에 대해 블로그에 올린 적이 있습니다.여기에 Mysql query_cache_size 성능이 있습니다.

InnoDB/cache를 사용하고 쿼리 캐시를 피하거나 매우 작은 값으로 설정하는 삽입이 있을 때마다 쿼리 캐시가 무효화/플래시됩니다.

언급URL : https://stackoverflow.com/questions/2095614/mysql-query-caching-limited-to-a-maximum-cache-size-of-128-mb