MySQL チューニング - メモリ使用量が多い

MySQL チューニング - メモリ使用量が多い

mysqltuner を使用して、mysql db をチューニングしようとしています。mysqltuner は、join_buffer_size と query_cache_size を増やすようにアドバイスしています。しかし、同時に、最大メモリ使用量が高いという警告も出ています。これは、インストールされている RAM (2GB) の 200% 以上です。私が陥っている問題は、mysqltuner の指示どおりにすると、メモリ使用量がさらに急上昇することです。では、どうすればよいでしょうか。問題はむしろ mysql ではなく、このサーバーで実行されているアプリケーションで、明らかに大量のキャッシュを mysql に要求しているのでしょうか。mysql 管理者のエキスパートの皆さんは、ここからどのように進めますか。以下の mysqltuner レポートと、現在の [mysqld] 設定を参照してください。

MySqlTuner レポート:

MySQLTuner 1.2.0 - 主要なヘイデンバグ報告、機能リクエスト、ダウンロードはこちらhttp://mysqltuner.com/ 追加のオプションと出力フィルタリングについては、「--help」で実行してください。

-------- 一般的な統計 --------------------------------------------------
[--] MySQLTuner スクリプトのバージョン チェックをスキップしました
[OK] 現在サポートされている MySQL バージョン 5.5.30-log を実行しています
[OK] 64 ビット アーキテクチャで動作しています

-------- ストレージ エンジン統計 -------------------------------------------
[--] ステータス: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] MyISAM テーブルのデータ: 310M (テーブル: 264)
[--] InnoDB テーブルのデータ: 8M (テーブル: 365)
[--] PERFORMANCE_SCHEMA テーブルのデータ: 0B (テーブル: 17) [!!] 断片化されたテーブルの合計: 376

-------- セキュリティ推奨事項 -------------------------------------------
[OK] すべてのデータベースユーザーにパスワードが割り当てられています

-------- パフォーマンス メトリック -------------------------------------------------
[--] 稼働時間: 20 時間 20 分 10 秒 (2M q [35.305 qps]、25K 接続、TX: 88B、RX: 2B)
[--] 読み取り / 書き込み: 22% / 78%
[--] 合計バッファー: 480.0M グローバル + 33.5M / スレッド (最大スレッド数 110)
[!!] 最大可能メモリ使用量: 4.1G (インストールされている RAM の 203%)
[OK] 低速クエリ: 0% (0/2M)
[OK] 使用可能な接続の最大使用率: 7% (8/110)
[OK] キー バッファー サイズ / MyISAM インデックスの合計: 150.0M/129.5M
[OK] キー バッファー ヒット率: 100.0% (15M キャッシュ / 7K 読み取り)
[OK] クエリ キャッシュ効率: 74.3% (762K キャッシュ / 100 万選択)
[!!] 1 日あたりのクエリ キャッシュ プルーニング: 4341
[OK] 一時テーブルを必要とするソート: 0% (3 一時ソート / 11K ソート)
[!!] インデックスなしで実行された結合: 3901
[OK] ディスク上に作成された一時テーブル: 0% (ディスク上に 2K / 合計 547K)
[OK] スレッド キャッシュ ヒット率: 99% (8 作成 / 25K 接続)
[OK] テーブル キャッシュ ヒット率: 46% (688 オープン / 1K オープン)
[OK] 使用されたオープン ファイル制限: 17% (593/3K)
[OK] 即時に取得されたテーブル ロック: 99% (1M 即時 / 1M ロック)
[OK] InnoDB データ サイズ / バッファー プール: 8.9M/256.0M

-------- 推奨事項 -----------------------------------------------------
一般的な推奨事項:
パフォーマンスを向上させるために、OPTIMIZE TABLE を実行してテーブルをデフラグします。
MySQL は過去 24 時間以内に起動されているため、推奨事項は不正確な可能性があります。
システムの安定性を確保するために、全体的な MySQL メモリ フットプリントを減らします。
結合クエリを調整して、常にインデックスを使用します
。 調整する変数:
* MySQLの最大メモリ使用量は危険なほど高い
MySQL バッファ変数を増やす前に RAM を追加する *
query_cache_size (> 32M)
join_buffer_size (> 32.0M、または常に結合でインデックスを使用する)

my.cnf 内の現在の mysqld 設定:

[mysqld]
local-infile=0
datadir=/var/lib/mysql
user=mysql
symbolic-links=0
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-external-locking
key_buffer_size = 150M
max_allowed_pa​​cket = 160M
max_connections = 110
wait_timeout = 60
query-cache-type = 1
query-cache-size = 32M
query_cache_limit = 2M
thread_cache_size = 16
tmp_table_size = 32M
max_heap_table_size = 32M
join_buffer_size = 32M
table_open_cache = 128
table_cache = 1600
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 2M
innodb_log_buffer_size = 8M

答え1

ここにはかなり奇妙なデータベースがあります。読み取りよりも書き込みの方がはるかに多く行われています。

Innodbでうまく動作するようにDBMSを調整することが非常に重要です。またはMyISAM でうまく動作するように調整しましたが、両方のテーブル タイプが混在しているようです。両方に最適な DBMS を持つことはできません。データを単一のエンジンに移行する必要があります。データベースの書き込みが重い性質を考えると、Innodb をお勧めします。

バッファ合計: グローバル 480.0M + スレッドあたり 33.5M (最大スレッド数 110)

現在、スワップに陥るリスクは、主に接続ごとのメモリ使用量によって決まります。ただし、これは危険たった今。また、110 の同時接続が必要かどうかも確認する必要があり、できればそれを少し減らす必要があります。通常、sort_buffer_size が接続ごとにメモリを使い果たす主な原因ですが、あなたの場合はデフォルトの 4 分の 1 です。

Innodb で統合する場合は、おそらく Innodb バッファ プールのサイズを増やす必要があります。

さまざまな値を試すことができますここ

関連情報