MySQL table_cache 및 Opened_tables

사람들이 Open_tables와 Opened_tables의 비교를 사용하여 MySQL에서 table_cache가 너무 작은 지 여부를 평가하는 것을 보았습니다. 그러나 Opened_tables는 가동 시간에 걸쳐 누적되는 것으로 생각되므로 올바른 비교는 아닙니다. 아마도 Opened_tables는 아마도 놓칠 때만 발생합니다. 초당 열리는 테이블이 여전히 작더라도 점진적으로 커지는 것은 문제가되지 않습니다.

Open_tables와 Opened_tables를 비교하는 것이 유효하지 않은 경우 이에 대한 측정 데이터를 얻는 다른 방법이 있습니까?

이것은 MySQL 5.0에 있지만 버전 간 차이도 환영합니다.

큰 table_cache를 갖는 가장 큰 이유는 LOCK_open 뮤텍스 가 뜨겁지 않기 때문입니다. 5.5 이전의 MySQL은 테이블을 열거 나 닫으려고 할 때 많은 경합을 가지고 있으므로 가능한 한 많은 작업을 제한해야합니다 (예 : 큰 테이블 캐시).

따라서 특정 비율의 히트 대 미스에 대해 신경 쓰지 않습니다 (실제로 비율을 무시해야합니다- 이 블로그 게시물은 이유를 설명합니다 ). 주의해야 할 것은 미스 레이트입니다 . 초당이 횟수가 많을수록 경합이 발생할 가능성이 높아집니다 (한 스레드가 다른 스레드가 잠금을 해제하기를 기다려야 함).

미스율을 어떻게 알 수 있습니까? 하루 중 가장 바쁜 기간 동안 몇 초 간격으로 Opened_Tables 샘플 몇 개를 가져 오며, 각 샘플이 증가하면 table_cache를 충돌시킬 수 있는지 확인하는 것이 좋습니다.

참고 : 특히 가동 시간과 비교하지 않는 것이 좋습니다.

먼저 이러한 상태 변수를 고려하십시오.

열린 테이블 : 열린 테이블 수입니다.

Opened_tables : 열린 테이블 수입니다. Opened_tables가 크면 table_open_cache 값이 너무 작을 수 있습니다.

놀랍게도 귀하의 질문에 대한 답변은 질문 자체에 있습니다.

: 당신이 믹스에 또 하나 개의 상태 변수를 던져 두 변수는 더 나을 가동 시간 (또는 Uptime_since_flush 상태를 후 신선한 평균을 위해 FLUSH 상태 ).

Open_tables agsinst (Opened_tables / Uptime) 비교해야합니다 . Open_tables가 (Opened_tables / Uptime) 이상으로 올라가면 이제 우려 할만한 원인이 있으며 다음과 같은 사항에주의를 기울여야합니다.

• netstat
• iostat
• 서버로드
• 연결 수 ( max_connections에 접근함에 따라 )
• 중단 된 고객
• 중단 된 연결
• 느린 쿼리

업데이트 2011-08-31 12:18 EDT

주어진 시간 동안 Opened_tables 성장 패턴을 수정하기 위해 Uptime 대신 Uptime_since_flush_status 를 사용하는 것이 좋습니다 .

예를 들어 FLUSH STATUS;매주 월요일 자정에 실행 하는 경우 OpenTableFactor를 생성 할 수 있습니다.

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

이 열린 테이블 요소는 주어진 기간 동안 열린 테이블의 평균 수에 대해 주어진 순간에 열린 테이블 수를 나타내는 수에 해당합니다. A를 FLUSH HOSTS;매주 / 일 / 호스트, 그 평균은 주 / 일 /시에 위배됩니다.

다음은 고용주의 고객 중 한 사람의 샘플입니다.

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

이 클라이언트는 일반적으로 약 7745 OpenTableFactor를 최대로 유지합니다. OpenTableFactor가 갑자기 떨어지면 (약간이라도) 낮은 트래픽 패턴, 중단 된 높은 연결 수 등을 나타낼 수 있습니다. OpenTableFactor가 조금이라도 변경되지 않으면 다음 설정을 변경할 수 있습니다.

• open_files_limit
• innodb_open_files
• table_open_cache

OpenTableFactor가 조정되면 지속적으로 변경되거나 다른 한도 또는 고원에 도달 할 수 있습니다. 따라서 상태 변수 내에서 다른 단위를 사용하면 이러한 종류의 튜닝에 필수적입니다.

업데이트 2011-08-31 12:42 EDT

OpenTableFactor에 대해 실행 한 SQL 쿼리는 MySQL 5.0 이상에서 작동하지 않습니다. MySQL 관리자를 사용하는 경우 또는 MONyog를 , 당신은 쿼리 및 모니터의 공식을 사용하여 그래프를 사용자 정의 할 수 있습니다. MONyog는 나중의 히스토리 그래프를 위해 SQLLite를 사용하여 히스토리를 수집합니다. 이것은 모든 버전의 MySQL에서 수행 할 수 있습니다.

에 대한 사용자 의견 중 하나에서 table_cache 문서 페이지 :

Opened_tables는 table_cache에서 사용 가능한 파일 디스크립터가 고갈되었을 때 테이블을 열기 위해 할당 된 추가 파일 디스크립터 수를 집계하는 상태 변수입니다. ...

의미를 넘어 설 때 증가한다는 의미입니다 table_cache. 따라서 일반적으로 이것을 확인하는 방법은과 비교 opened_tables하는 uptime것이지만 여기서 핵심은 설정된 간격 (예 : 분당 10 분 이상)을 취하는 것입니다. 증가하는 경우을 늘려야 할 수도 있습니다 table_cache.

언급해야 할 몇 가지주의 사항 :

• 위 문서의 다른 설명 : "임시 테이블을 만들 때마다 상태 변수 'Opened_tables'도 2 씩 증가합니다." 따라서 쿼리에 많은 임시 테이블이 필요한 경우이가 빠르게 증가하는 원인 일 수 있습니다 opened_tables. 다음 쿼리를 사용하여 임시 테이블 사용법을 볼 수 있습니다.

  SHOW GLOBAL STATUS LIKE '%tmp%';

• table_cache를 너무 높이 지 마십시오

  그러한 행동의 이유는 당신이 큰 것이 없다면. 여러 테이블을 결합하는 복잡한 쿼리가있는 테이블과 이러한 복잡한 쿼리를 실행하는 다중 연결의 경우 MySQL은 알고리즘을 사용하여 가장 최근에 사용한 디스크립터를 찾고 닫고 바꿉니다. 새로운 디스크립터와 함께.