SlideShare a Scribd company logo
1 of 32
Download to read offline
MySQL 初めてのチューニング

 2010/12/11 MySQL Casual Talks #1
          id:Craftworks
自己紹介
•   id:Craftworks
•   Twitter: @Craftworks
•   github: https://github.com/Craftworks
•   Blog: http://d.hatena.ne.jp/Craftworks
•   最近は EC2 で Perl 書いてます
•   ずっと PostgreSQL を使っていた MySQL
    初心者です
今日は MySQL をセットアップしてから
最初にするチューニングの話をします
MySQL のメモリ設定

MySQL のバッファタイプは2種類
 グローバルバッファ
  • mysqld 全体で確保するメモリ
 スレッドバッファ
  • コネクション毎に確保するメモリ
グローバルバッファ
innodb_buffer_pool_size
 – InnoDB のインデックスやレコードをキャッ
   シュする領域
 – InnoDB メインで使うなら最重要パラメータ
innodb_additional_mem_pool_size
 – InnoDB テーブル定義情報
 – 足りなくなったらエラーログに警告が出る
 – 足りなくなった時に増やせばよい
innodb_log_buffer_size
  – InnoDB トランザクションログを管理する領
    域
  – トランザクション終了時もしくは一定時間毎
    にディスクにフラッシュされる
  – 他のパラメータにメモリを回した方が得策
key_buffer_size
  – MyISAM のインデックスをキャッシュする領
    域
  – MyISAM をあまり使わないなら他に回す
query_cache_size
 – SELECT の実行結果をキャッシュする
 – パフォーマンス的にはかなり重要
 – query_cache_type でキャッシュ動作を指定
   できる
スレッドバッファ
sort_buffer_size
  – ORDER BY, GROUP BY に使われる領域
  – 多用する場合は増やす
read_rnd_buffer_size
  – ソート後にレコードを読む際に使用
  – ORDER BY の性能向上
join_buffer_size
  – インデックスを使用しないテーブル結合の
    際に使われる領域
  – インデックスを用いないテーブル結合は避
    けるべきなので大きくする必要は無い
read_buffer_size
  – テーブルスキャンのときに使われる領域
  – インデックスを使わないクエリは発行する
    べきではないので大きくする必要は無い
myisam_sort_buffer_size
 – MyISAM で DDL 系のクエリの時にインデッ
   クスのソートに使われる領域
 – 通常のクエリでは使われないのでそれほど
   多く取る必要は無い
メモリ以外の設定
innodb_log_file_size
  – InnoDBの更新ログを記録するディスク上の
    ファイル
  – innodb_log_file がいっぱいになったら、
    innodb_buffer_poolの中の更新されたデー
    タをディスクに書き出し
  – innodb_buffer_pool_size を大きくしたら
    innodb_log_file_size も合わせて調整
  – 大きくするほどクラッシュリカバリに時間が
    かかる
table_open_cache
 – 開いたテーブルのファイルポインタを格納
   する
 – 同時接続数×テーブル数が最低限必要
 – 1024〜2048 が一般的
 – MyISAM では1テーブルにつき2つ消費
 – OS が処理できる記述子数以内にする
   • cat /proc/sys/fs/file-max
thread_cache_size
 – スレッドをキャッシュして再接続のオーバー
   ヘッドを軽減する
 – 稼働状況に応じて設定する
 – コネクションプーリングしてる場合はあまり
   影響が無い?
以上を考慮して実際の設定
設定の目安
グローバルバッファ
 + (スレッドバッファ × 最大接続数)
 = 搭載メモリの 8 ~ 9 割
警告: 32-bit GNU/Linux x86 上では、メモリ使用を高く設定しすぎないように注意して
ください。glibc はプロセス ヒープがスレッド スタックよりも大きくなる事を許容する可
能性があり、その為サーバがクラッシュしてしまうかもしれません。もし次の式の値が
2GB に近い、またはそれを上回っていたら危険です:

innodb_buffer_pool_size + key_buffer_size +
max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size) +
max_connections*2MB
設定メモリ量の計算
• 個々の設定を計算するのは面倒臭い
 – ツールがあります
 – mymemcheck
 – !includedir に対応したものを github に置きました
 – https://gist.github.com/733390
 – mysql -e 'SHOW VARIABLES' | mymemcheck
 – mymemcheck ~/my.cnf
実行結果抜粋
global_buffers
 key_buffer_size                  16777216 16.000M
 innodb_buffer_pool_size         268435456 256.000M
 innodb_log_buffer_size           67108864 64.000M
 innodb_additional_mem_pool_size 20971520 20.000M
 net_buffer_length                   16384 16.000K
 ---------------------------------------------------
                                     total 356.016M
運用後のチューニング
key_buffer_size の調整
• SHOW STATUS LIKE 'Key_read%';
  – Key_read_requests / Key_reads = 150 以上になる
    ように key_buffer_size を調整
• SHOW STATUS LIKE 'Key_blocks%';
  – Key_blocks_unused が数百など少ない場合
    key_buffer_size を増やす必要がある。
最大接続数とスレッド数の確認
• SHOW STATUS LIKE '%connection%';
  – Max_used_connections
     • これまでに記録された同時接続数の最大値
• SHOW STATUS LIKE 'Threads%';
  – Threads_connected
     • 現在開いている接続の数
  – Threads_created
     • 接続を処理するために生成されたスレッド数
  – Threads_running
     • スリープ状態になっていないスレッド数
table_open_cache の調整
• SHOW STATUS LIKE 'Open_tables';
  – Open_tables
     • 現在開かれているテーブル数を確認
  – Opened_tables
     • たとえ多くの FLUSH TABLES を実行していない場合でも、
       この値が非常に大きい場合や急速に大きくなる場合
       は、テーブルキャッシュサイズを拡張する
query_cache_size の調整
• SHOW STATUS LIKE 'Qcache%';
  – Qcache_free_memory
     • query_cache_size で割り当てたメモリ残量
     • これが小さくなって、Qcache_lowmem_prunes が増加してい
       たら、query_cache_size の増量を検討
  – Qcache_inserts / Qcache_hits
     • Qcache_inserts に対して Qcache_hitsが少ないとキャッシュ
       のヒット率が悪い
  – Qcache_free_blocks
     • 増加している場合 → フラグメンテーション発生
        – FLUSH QUERY CACHE でデフラグする必要がある
クエリキャッシュの注意点


クエリキャッシュはケースセンシティブ
SELECT … と select … は別クエリ扱い
まとめ
• 最大限のパフォーマンスを発揮できるよ
  うに、なるべく多くのメモリを割り当てる
• かつ、コネクションが増えた時にメモリを
  食い過ぎてスワップが発生しないように、
  安全なラインに設定する
• 運用しながら SHOW STATUS で値を確認
  しながらチューニングする
参考
• 6.5.5. MySQL でのメモリの使用
   – http://dev.mysql.com/doc/refman/5.1/ja/memory-use.html
• 9.3. InnoDB スタートアップオプションとシステム変数
   – http://dev.mysql.com/doc/refman/5.1-olh/ja/innodb-parameters.html
• 4.13.3. クエリ キャッシュの設定
   – http://dev.mysql.com/doc/refman/5.1/ja/query-cache-configuration.html
• 6.4.8. MySQL でのテーブルのオープンとクローズの方法
   – http://dev.mysql.com/doc/refman/5.1/ja/table-cache.html
• 13.5.3. InnoDB 設定
   – http://dev.mysql.com/doc/refman/5.1/ja/innodb-configuration.html
• 5分でできる、MySQLのメモリ関係のチューニング!
   – http://dsas.blog.klab.org/archives/50860867.html
ご清聴ありがとうございました

More Related Content

What's hot

Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
Masahiko Sawada
 
10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ
Takashi Hoshino
 
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
Insight Technology, Inc.
 

What's hot (20)

Firebirdの障害対策
Firebirdの障害対策Firebirdの障害対策
Firebirdの障害対策
 
MySQL Buffer Management
MySQL Buffer ManagementMySQL Buffer Management
MySQL Buffer Management
 
ネットワークコンフィグ分析ツール Batfish との付き合い方
ネットワークコンフィグ分析ツール Batfish との付き合い方ネットワークコンフィグ分析ツール Batfish との付き合い方
ネットワークコンフィグ分析ツール Batfish との付き合い方
 
Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造
 
binary log と 2PC と Group Commit
binary log と 2PC と Group Commitbinary log と 2PC と Group Commit
binary log と 2PC と Group Commit
 
MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座
 
Innodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライドInnodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライド
 
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
 
InnoDB MVCC Architecture (by 권건우)
InnoDB MVCC Architecture (by 권건우)InnoDB MVCC Architecture (by 권건우)
InnoDB MVCC Architecture (by 권건우)
 
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
 
OSC北海道2014_JPUG資料
OSC北海道2014_JPUG資料OSC北海道2014_JPUG資料
OSC北海道2014_JPUG資料
 
Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
InnoDB Flushing and Checkpoints
InnoDB Flushing and CheckpointsInnoDB Flushing and Checkpoints
InnoDB Flushing and Checkpoints
 
10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ
 
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
 
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
 
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
 
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlCassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
 
PostgreSQL:行数推定を読み解く
PostgreSQL:行数推定を読み解くPostgreSQL:行数推定を読み解く
PostgreSQL:行数推定を読み解く
 
Redo log improvements MYSQL 8.0
Redo log improvements MYSQL 8.0Redo log improvements MYSQL 8.0
Redo log improvements MYSQL 8.0
 

Viewers also liked

Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
Yoshinori Matsunobu
 

Viewers also liked (10)

カジュアルに本番データを開発環境に入れる #mysqlcasual
カジュアルに本番データを開発環境に入れる #mysqlcasualカジュアルに本番データを開発環境に入れる #mysqlcasual
カジュアルに本番データを開発環境に入れる #mysqlcasual
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
 
メンテナブルでありつづけるためのCSS設計
メンテナブルでありつづけるためのCSS設計メンテナブルでありつづけるためのCSS設計
メンテナブルでありつづけるためのCSS設計
 
Zabbixのパフォーマンスチューニング & インストール時の注意点
Zabbixのパフォーマンスチューニング & インストール時の注意点Zabbixのパフォーマンスチューニング & インストール時の注意点
Zabbixのパフォーマンスチューニング & インストール時の注意点
 
本当のオブジェクト指向は可読性を上げる
本当のオブジェクト指向は可読性を上げる本当のオブジェクト指向は可読性を上げる
本当のオブジェクト指向は可読性を上げる
 
Advanced nginx in mercari - How to handle over 1,200,000 HTTPS Reqs/Min
Advanced nginx in mercari - How to handle over 1,200,000 HTTPS Reqs/MinAdvanced nginx in mercari - How to handle over 1,200,000 HTTPS Reqs/Min
Advanced nginx in mercari - How to handle over 1,200,000 HTTPS Reqs/Min
 
MySQL Performance Tuning. Part 1: MySQL Configuration (includes MySQL 5.7)
MySQL Performance Tuning. Part 1: MySQL Configuration (includes MySQL 5.7)MySQL Performance Tuning. Part 1: MySQL Configuration (includes MySQL 5.7)
MySQL Performance Tuning. Part 1: MySQL Configuration (includes MySQL 5.7)
 
MySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことMySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいこと
 
Memory management in Linux
Memory management in LinuxMemory management in Linux
Memory management in Linux
 
逆説のスタートアップ思考
逆説のスタートアップ思考逆説のスタートアップ思考
逆説のスタートアップ思考
 

Similar to MySQL 初めてのチューニング

Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズAmazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズ
SORACOM, INC
 
スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門
Hisashi HATAKEYAMA
 
081108huge_data.ppt
081108huge_data.ppt081108huge_data.ppt
081108huge_data.ppt
Naoya Ito
 
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
Insight Technology, Inc.
 
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14
Masahiro Nagano
 
Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache 
maruyama097
 
MTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティング
MTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティングMTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティング
MTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティング
純生 野田
 
SQL Server パフォーマンスカウンター
SQL Server パフォーマンスカウンターSQL Server パフォーマンスカウンター
SQL Server パフォーマンスカウンター
Masayuki Ozawa
 

Similar to MySQL 初めてのチューニング (20)

Webサーバのチューニング
WebサーバのチューニングWebサーバのチューニング
Webサーバのチューニング
 
Mysql casial01
Mysql casial01Mysql casial01
Mysql casial01
 
Azure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL PoolベストプラクティスAzure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL Poolベストプラクティス
 
Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズAmazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズ
 
20120117 13 meister-elasti_cache-public
20120117 13 meister-elasti_cache-public20120117 13 meister-elasti_cache-public
20120117 13 meister-elasti_cache-public
 
dimSTATから見るベンチマーク
dimSTATから見るベンチマークdimSTATから見るベンチマーク
dimSTATから見るベンチマーク
 
スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門
 
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)
 
今日から使い始めるChef
今日から使い始めるChef今日から使い始めるChef
今日から使い始めるChef
 
Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)
 
VarnishCache入門Rev2.1
VarnishCache入門Rev2.1VarnishCache入門Rev2.1
VarnishCache入門Rev2.1
 
States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -
 
081108huge_data.ppt
081108huge_data.ppt081108huge_data.ppt
081108huge_data.ppt
 
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
 
LINEのMySQL運用について
LINEのMySQL運用についてLINEのMySQL運用について
LINEのMySQL運用について
 
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14
 
Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache Java EE7 䛸㻌JCache 
Java EE7 䛸㻌JCache 
 
MTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティング
MTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティングMTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティング
MTのダイナミック処理(PHP)を高速化する@サーバーサイドスクリプティング
 
CPUの同時実行機能
CPUの同時実行機能CPUの同時実行機能
CPUの同時実行機能
 
SQL Server パフォーマンスカウンター
SQL Server パフォーマンスカウンターSQL Server パフォーマンスカウンター
SQL Server パフォーマンスカウンター
 

Recently uploaded

Recently uploaded (10)

論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
 
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
 
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 

MySQL 初めてのチューニング

  • 1. MySQL 初めてのチューニング 2010/12/11 MySQL Casual Talks #1 id:Craftworks
  • 2. 自己紹介 • id:Craftworks • Twitter: @Craftworks • github: https://github.com/Craftworks • Blog: http://d.hatena.ne.jp/Craftworks • 最近は EC2 で Perl 書いてます • ずっと PostgreSQL を使っていた MySQL 初心者です
  • 4. MySQL のメモリ設定 MySQL のバッファタイプは2種類 グローバルバッファ • mysqld 全体で確保するメモリ スレッドバッファ • コネクション毎に確保するメモリ
  • 6. innodb_buffer_pool_size – InnoDB のインデックスやレコードをキャッ シュする領域 – InnoDB メインで使うなら最重要パラメータ
  • 7. innodb_additional_mem_pool_size – InnoDB テーブル定義情報 – 足りなくなったらエラーログに警告が出る – 足りなくなった時に増やせばよい
  • 8. innodb_log_buffer_size – InnoDB トランザクションログを管理する領 域 – トランザクション終了時もしくは一定時間毎 にディスクにフラッシュされる – 他のパラメータにメモリを回した方が得策
  • 9. key_buffer_size – MyISAM のインデックスをキャッシュする領 域 – MyISAM をあまり使わないなら他に回す
  • 10. query_cache_size – SELECT の実行結果をキャッシュする – パフォーマンス的にはかなり重要 – query_cache_type でキャッシュ動作を指定 できる
  • 12. sort_buffer_size – ORDER BY, GROUP BY に使われる領域 – 多用する場合は増やす read_rnd_buffer_size – ソート後にレコードを読む際に使用 – ORDER BY の性能向上
  • 13. join_buffer_size – インデックスを使用しないテーブル結合の 際に使われる領域 – インデックスを用いないテーブル結合は避 けるべきなので大きくする必要は無い
  • 14. read_buffer_size – テーブルスキャンのときに使われる領域 – インデックスを使わないクエリは発行する べきではないので大きくする必要は無い
  • 15. myisam_sort_buffer_size – MyISAM で DDL 系のクエリの時にインデッ クスのソートに使われる領域 – 通常のクエリでは使われないのでそれほど 多く取る必要は無い
  • 17. innodb_log_file_size – InnoDBの更新ログを記録するディスク上の ファイル – innodb_log_file がいっぱいになったら、 innodb_buffer_poolの中の更新されたデー タをディスクに書き出し – innodb_buffer_pool_size を大きくしたら innodb_log_file_size も合わせて調整 – 大きくするほどクラッシュリカバリに時間が かかる
  • 18. table_open_cache – 開いたテーブルのファイルポインタを格納 する – 同時接続数×テーブル数が最低限必要 – 1024〜2048 が一般的 – MyISAM では1テーブルにつき2つ消費 – OS が処理できる記述子数以内にする • cat /proc/sys/fs/file-max
  • 19. thread_cache_size – スレッドをキャッシュして再接続のオーバー ヘッドを軽減する – 稼働状況に応じて設定する – コネクションプーリングしてる場合はあまり 影響が無い?
  • 21. 設定の目安 グローバルバッファ + (スレッドバッファ × 最大接続数) = 搭載メモリの 8 ~ 9 割 警告: 32-bit GNU/Linux x86 上では、メモリ使用を高く設定しすぎないように注意して ください。glibc はプロセス ヒープがスレッド スタックよりも大きくなる事を許容する可 能性があり、その為サーバがクラッシュしてしまうかもしれません。もし次の式の値が 2GB に近い、またはそれを上回っていたら危険です: innodb_buffer_pool_size + key_buffer_size + max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size) + max_connections*2MB
  • 22. 設定メモリ量の計算 • 個々の設定を計算するのは面倒臭い – ツールがあります – mymemcheck – !includedir に対応したものを github に置きました – https://gist.github.com/733390 – mysql -e 'SHOW VARIABLES' | mymemcheck – mymemcheck ~/my.cnf
  • 23. 実行結果抜粋 global_buffers key_buffer_size 16777216 16.000M innodb_buffer_pool_size 268435456 256.000M innodb_log_buffer_size 67108864 64.000M innodb_additional_mem_pool_size 20971520 20.000M net_buffer_length 16384 16.000K --------------------------------------------------- total 356.016M
  • 25. key_buffer_size の調整 • SHOW STATUS LIKE 'Key_read%'; – Key_read_requests / Key_reads = 150 以上になる ように key_buffer_size を調整 • SHOW STATUS LIKE 'Key_blocks%'; – Key_blocks_unused が数百など少ない場合 key_buffer_size を増やす必要がある。
  • 26. 最大接続数とスレッド数の確認 • SHOW STATUS LIKE '%connection%'; – Max_used_connections • これまでに記録された同時接続数の最大値 • SHOW STATUS LIKE 'Threads%'; – Threads_connected • 現在開いている接続の数 – Threads_created • 接続を処理するために生成されたスレッド数 – Threads_running • スリープ状態になっていないスレッド数
  • 27. table_open_cache の調整 • SHOW STATUS LIKE 'Open_tables'; – Open_tables • 現在開かれているテーブル数を確認 – Opened_tables • たとえ多くの FLUSH TABLES を実行していない場合でも、 この値が非常に大きい場合や急速に大きくなる場合 は、テーブルキャッシュサイズを拡張する
  • 28. query_cache_size の調整 • SHOW STATUS LIKE 'Qcache%'; – Qcache_free_memory • query_cache_size で割り当てたメモリ残量 • これが小さくなって、Qcache_lowmem_prunes が増加してい たら、query_cache_size の増量を検討 – Qcache_inserts / Qcache_hits • Qcache_inserts に対して Qcache_hitsが少ないとキャッシュ のヒット率が悪い – Qcache_free_blocks • 増加している場合 → フラグメンテーション発生 – FLUSH QUERY CACHE でデフラグする必要がある
  • 30. まとめ • 最大限のパフォーマンスを発揮できるよ うに、なるべく多くのメモリを割り当てる • かつ、コネクションが増えた時にメモリを 食い過ぎてスワップが発生しないように、 安全なラインに設定する • 運用しながら SHOW STATUS で値を確認 しながらチューニングする
  • 31. 参考 • 6.5.5. MySQL でのメモリの使用 – http://dev.mysql.com/doc/refman/5.1/ja/memory-use.html • 9.3. InnoDB スタートアップオプションとシステム変数 – http://dev.mysql.com/doc/refman/5.1-olh/ja/innodb-parameters.html • 4.13.3. クエリ キャッシュの設定 – http://dev.mysql.com/doc/refman/5.1/ja/query-cache-configuration.html • 6.4.8. MySQL でのテーブルのオープンとクローズの方法 – http://dev.mysql.com/doc/refman/5.1/ja/table-cache.html • 13.5.3. InnoDB 設定 – http://dev.mysql.com/doc/refman/5.1/ja/innodb-configuration.html • 5分でできる、MySQLのメモリ関係のチューニング! – http://dsas.blog.klab.org/archives/50860867.html