메모리에 MySQL 데이터베이스 캐시


11

600MB의 MySQL 데이터베이스가있는 웹 사이트에 문제가 있습니다. 웹 사이트가 너무 느립니다. MySQL 데이터베이스가 커질수록 느려집니다. 5MB 였을 때 웹 사이트는 매우 빨랐습니다. 점점 커지기 시작하면서 점점 느려졌습니다. 이제 600MB에서는 페이지를로드하는 데 10 초 정도 걸립니다.

나는 최고 프로세스를 확인했으며 높은 부하 또는 아무것도 관련이 없습니다. HDD 7.2k rpm 드라이브에서 테스트 할 때 IOPS와 관련이 없으며 Intel 320 SSD 드라이브로 테스트 할 때도 동일한 문제가 발생했기 때문에 쿼리가 높지 않다고 생각하지 않습니다.

웹 사이트에서 Wordpress를 사용하고 있으며 9 개의 플러그인이 활성화되어 있습니다. 사람들은 플러그인 일 수도 있고 ... 아마도 ...하지만 지금은 전체 데이터베이스를 메모리에 캐시하고 시작 위치와 방법에 대한 도움과 지시를 원합니다.

16GB RAM과 3.1GHz에서 i5-2400 4 코어가 있습니다. OS는 centos 5.7입니다

top - 07:23:57 up 9 days, 12:15, 0 users, load average: 0.09, 0.04, 0.05
Tasks: 162 total, 1 running, 161 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.2%us, 1.0%sy, 0.0%ni, 90.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16367532k total, 3641628k used, 12725904k free, 612140k buffers
Swap: 1046520k total, 0k used, 1046520k free, 1538896k cached

답변:


10

내가 당신이라면 모든 데이터를 InnoDB로 전환 할 것입니다. 많은 사람들이 테이블 잠금 / 행 잠금에 대해 오랫동안 논의 해 왔습니다. 저는 항상 InnoDB 핸드 다운을 선택합니다. 그러나 InnoDB ... CACHING을 선택해야하는 또 다른 깊은 이유가 있습니다.

대부분의 사람들은 MyISAM이 읽기 속도가 더 빠르다는 것을 자랑하지만, 대부분의 사람들은 키 캐시 (key_buffer_size로 설정 됨)라고하는 MyISAM의 많은 캐시가 .MYI 파일의 색인 페이지 만 캐시한다는 사실을 잊어 버립니다. 데이터 페이지를 캐시하지 않습니다. 32 비트 시스템에서 공식 최대 4GB입니다. 64 비트의 경우 8GB가 가장 좋습니다.

InnoDB 버퍼 풀은 데이터 및 인덱스 페이지를 캐시합니다. 보유한 서버에 따라 RAM의 전체 데이터 세트를 캐시 할 수 있습니다. InnoDB를 최대 80 %의 RAM과 10 %의 DB Conenction에 맞게 조정하고 10 %는 OS에 남겨 둘 수 있습니다. 다른 운영 체제에서도 마찬가지입니다 .

Drupal 고객 에게 놀라운 성공을 거두었습니다. Wordpress에도 적용됩니다 . WordPress를 사용하여 클라이언트에 DB 지원을 제공했습니다. 같은 개선.

더 많은 MyISAM을 사용할 수 있도록 항상 InnoDB에 대한 메모리를 보다 효과적으로 구성 할 수 있습니다. 성능 요구에 맞게 InnoDB를 tweek 하는 방법은 항상 있습니다 . 데이터가 커짐에 따라 결국 요구 사항이 될 것 입니다.

업데이트 2011-11-21 11:44 EST

전체 데이터 세트가 충분히 작 으면 mysql이 시작된 직후에있는 모든 테이블에서 SELECT 쿼리를 실행할 수 있습니다.

InnoDB 및 / 또는 MyISAM 인 모든 테이블에 대해 다음 쿼리를 실행하십시오.

SELECT DISTINCT
    CONCAT('SELECT ',ndxcollist,' FROM ',
    db,'.',tb,' ORDER BY ',ndxcollist,';') SelectQueryToLoadCache
FROM (
    SELECT
        engine,table_schema db,table_name tb,index_name,
        GROUP_CONCAT(column_name ORDER BY seq_in_index) ndxcollist
    FROM (
        SELECT
            B.engine,A.table_schema,A.table_name,
            A.index_name,A.column_name,A.seq_in_index
        FROM
            information_schema.statistics A INNER JOIN
            (SELECT engine,table_schema,table_name
            FROM information_schema.tables
            WHERE engine IN ('InnoDB','MyISAM')) B
            USING (table_schema,table_name)
        WHERE
            B.table_schema NOT IN ('information_schema','mysql')
            AND A.index_type <> 'FULLTEXT'
        ORDER BY
            table_schema,table_name,index_name,seq_in_index
        ) A
    GROUP BY
        table_schema,table_name,index_name
) AA
ORDER BY
    engine DESC,db,tb
;

그러면 참조 할 모든 인덱스를 소환하는 실행에 필요한 모든 SELECT 쿼리가 출력됩니다. 이 쿼리를 /root/MakeSelectQueriesToLoad.sql이라는 파일에 배치하십시오. 스크립트를 실행하고 /root/SelectQueriesToLoad.sql 출력을 수집하십시오. 마지막으로 다음을 실행하십시오.

mysql -u... -p... -AN < /root/MakeSelectQueriesToLoad.sql > /root/SelectQueriesToLoad.sql
mysql -u... -p... < /root/SelectQueriesToLoad.sql

이렇게하면 모든 인덱스 페이지가 InnoDB 버퍼 풀 및 MyISAM 키 캐시에 미리로드됩니다. 모든 데이터가 InnoDB 인 경우 두 가지를 변경하십시오.

  • 교체 WHERE engine IN ('InnoDB','MyISAM')WHERE engine='InnoDB'
  • 교체 CONCAT('SELECT ',ndxcollist,' FROM ',CONCAT('SELECT * FROM ',

또한 InnoDB 버퍼 풀에 더 많은 데이터 페이지가 채워집니다.

최종 참고 사항 : InnoDB 버퍼 풀이 모든 InnoDB 데이터를 보유 할 수있을만큼 충분히 큰지 확인하십시오.


2

이미 전체 데이터베이스를 메모리에 캐시하고 있습니다. RAM 에서조차 데이터베이스를 검색하는 데 걸리는 시간은 거의 확실합니다.

디스크 I / O 통계를 확인하십시오. 가끔 임의의 디스크 I / O 비트가 있다는 것을 알게 될 것입니다. 데이터베이스 메모리에 있습니다. 그것은 문제가 아닙니다. iostat먼저 설치해야합니다 . 플랫폼이나 배포판에 대해서는 언급하지 않았지만 아마도라는 패키지에있을 것입니다 iostat. atop더 친근감을 느낄 수 있습니다 .

전체 데이터베이스가 아직 메모리에 없거나 디스크 I / O에 문제가 있다는 증거를 얻은 후에 그 사실을 알려 주었습니까? 그렇지 않으면, 그들의 충고는 당신을 보거나 검사 한 적이 없지만 팔에 상처를 입힌다는 의사의 말과 같습니다.


-1

Wordpress에 적합한 캐싱 플러그인을 설치하면 도움이 될 수 있습니다. 그러나 조만간 시스템 속도를 늦추는 병목 현상을 파악해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.