MySQLデータベースをメモリにキャッシュする


11

MySQLデータベースが600 MBのWebサイトに問題があります。ウェブサイトが遅すぎる。MySQLデータベースが大きくなるほど、速度が遅くなることに気づきました。5MBだったとき、ウェブサイトは非常に高速でした。大きくなると徐々に遅くなり始め、現在は600MBと非常に遅く、ページのロードに10秒ほどかかります。

上位のプロセスを確認しましたが、高負荷などとは関係ありません。HDD 7.2k rpmドライブでテストしたため、IOPSにも関係がなく、Intel 320 SSDドライブでのテストでも同じ問題が発生したため、クエリ数が多いとは思われません。

WebサイトはWordpressを使用しており、9つのプラグインがアクティブになっています。人々はそれがプラグインかもしれないと言いました...多分...しかし、今私はデータベース全体をメモリにキャッシュしたいだけで、どこから始めてどのようにそれを行うかについてのヘルプと方向性を知りたいです。

16GB RAMとi5-2400 4コア@ 3.1 GHzを持っています。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を選択するもう1つの大きな理由があります

ほとんどの人はMyISAMの方が読み取りが高速であることを自慢していますが、ほとんどの人はMyISAMの多数のキャッシュ(key_buffer_sizeによって設定される)と呼ばれる、.MYIファイルからのインデックスページのみをキャッシュすることを忘れています。データページをキャッシュすることはありません。32ビットシステムでは公式に最大4GBです。64ビットの場合、最大8GBが最適です。

InnoDBバッファープールは、データとインデックスページをキャッシュします。使用しているサーバーに応じて、データセット全体をRAMにキャッシュできます。InnoDBを最大80%のRAMと10%のDB Conenctionsに調整し、10%をOSに残すことができます。これは、異なるオペレーティングシステムでも同じです

素晴らしい成功を収めているDrupalのお客様にこれらをお勧めします。Wordpressにも同様に適用されます。WordPressを使用するクライアントにDBサポートを提供しました。同じ改善。

InnoDBのメモリは、MyISAMよりも効率的に構成できますパフォーマンスのニーズに合わせてInnoDBを調整する方法は常にあります。データが大きくなるにつれて、最終的には要件なります

UPDATE 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の場合、2つの変更を行います。

  • 置き換える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.