내가 실행할 때 SHOW PROCESSLIST종종 "freeing items"상태에 많은 수의 INSERT / UPDATE 스레드가 있습니다.
MySQL 매뉴얼은 스레드가이 상태에있는 이유의 적어도 일부는 쿼리 캐시와 관련이 있다고 제안합니다. 아마도 변경된 데이터로 인해 캐시 된 쿼리가 무효화 될 수 있습니다.
그러나 my query_cache_size는 0으로 설정되어 쿼리 캐시를 완전히 비활성화해야합니다.
이 상태에서 스레드가 너무 많은 다른 이유는 무엇입니까?
관련 테이블은 InnoDB 스토리지 엔진을 사용합니다.
답변:
innodb_thread_concurrency의 값을 확인하십시오.
내 시스템의 경우 MySql documentation 의 지침에 따라 값을 8에서 32로 늘리면 동시에 "사용 가능한 항목"상태를보고하는 스레드 수가 눈에 띄게 감소했습니다. 또한 obesrved 평균 쿼리 시간이 몇 배나 줄었습니다.
이로 인해 전체 서버 성능이 크게 달라졌지만 "사용 가능한 항목"은 총알이 아니 었습니다. 내 하드웨어 에코 시스템은이 상태가 "느린"디스크 (2x10k 디스크 습격 1)가있는 시스템에서 주로 볼 수 있으며 더 빠른 스토리지 (12x15k 디스크 raid 10)의 시스템에서는 덜 널리 퍼져 있다고 가정합니다. 따라서 디스크 성능 검사도 필요합니다.
행운을 빕니다!
또한:
innodb_thread_concurrency의 기본값은 사용되는 5.0 포인트 릴리스에 따라 근본적으로 다릅니다.
기본값은 여러 번 변경되었습니다. MySQL 5.0.8 이전 8, 20 (무한) 5.0.8에서 5.0.18로, 0 (무한) 5.0.19에서 5.0.20으로, 8 (무한)에서 5.0.21로 의 위에. - 출처
이는 5.0.20에서 5.0.21 로의 무해한 업그레이드가 기본값을 무한에서 8로 변경하고 성능에 영향을 미쳤음을 의미합니다.
해제 항목은 임시 구조, 버퍼 등이 할당 해제되는 쿼리 실행 단계입니다. 일부 쿼리 캐시 작업은이 단계에서 수행되지만 이것이 유일한 일은 아닙니다. SHOW PROFILES를 사용하여이 단계가 다른 단계와 비교하여 시간이 얼마나 걸리는지, 그리고 소비 된 시간이 문제가되면 가난한 사람의 프로파일 러 및 oprofile과 같은 도구로 문제를 해결하는 것이 좋습니다.
"freeing items"및 query cache와 관련하여이 문제에 대한 버그 보고서가있었습니다 . 버그가 닫혔지만 innodb_thread_concurrency 에 대한 언급은 없습니다 .
5 월에 Percona Live NYC에서 Ronald Bradford와 이야기를 나 inc습니다. MySQL 5.5의 여러 InnoDB 버퍼 풀이 수많은 스레드 잠금을 생성하고 캐시 된 데이터가 여러 버퍼 풀에 분산되었을 가능성이 높기 때문에 innodb_thread_concurrency를 tweek 한 상황에 대해 이야기했습니다.
그는 분명히 innodb_thread_concurrency에 대해 값을 설정해서는 안된다고 말했습니다. 항상 기본값으로 설정하십시오 (현재는 0). 이렇게하면 InnoDB 스토리지 가 자체적으로 생성 할 innodb_concurrency_ticket 수 를 결정할 수 있습니다. 이것이 무한한 동시성입니다.
'freeing items'는 innodb_thread_concurrency에 제한을 가할 때 더 자주 발생합니다. 항상 0이어야합니다. 위험을 감수하고 innodb_concurrency_tickets을 제기하고 도움이되는지 확인하십시오.
우리는 정확히 같은 증상에 문제가있었습니다. InnoDB 로그 파일이있는 디스크가 가득 찼습니다. 확인 가치가 있습니다.