SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Downloaden Sie, um offline zu lesen
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
ご清聴ありがとうございました

Weitere ähnliche Inhalte

Was ist angesagt?

MySQLの運用でありがちなこと
MySQLの運用でありがちなことMySQLの運用でありがちなこと
MySQLの運用でありがちなことHiroaki Sano
 
PHP 5.5ネーティブキャッシュの話
PHP 5.5ネーティブキャッシュの話PHP 5.5ネーティブキャッシュの話
PHP 5.5ネーティブキャッシュの話Rui Hirokawa
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニングyoku0825
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法Tetsutaro Watanabe
 
高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方GMO-Z.com Vietnam Lab Center
 
PostgreSQL WAL for DBAs
PostgreSQL WAL for DBAs PostgreSQL WAL for DBAs
PostgreSQL WAL for DBAs PGConf APAC
 
5.6 以前の InnoDB Flushing
5.6 以前の InnoDB Flushing5.6 以前の InnoDB Flushing
5.6 以前の InnoDB FlushingTakanori Sejima
 
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48Preferred Networks
 
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみようSolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみようShinsuke Sugaya
 
Memcachedの仕組みと設定
Memcachedの仕組みと設定Memcachedの仕組みと設定
Memcachedの仕組みと設定Tatsuya Akashi
 
プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料
プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料
プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料Ken SASAKI
 
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 Hiroshi Ito
 
20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_APIKohei KaiGai
 
InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)Takanori Sejima
 
MySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slaveMySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slaveTakanori Sejima
 

Was ist angesagt? (20)

MySQLの運用でありがちなこと
MySQLの運用でありがちなことMySQLの運用でありがちなこと
MySQLの運用でありがちなこと
 
PHP 5.5ネーティブキャッシュの話
PHP 5.5ネーティブキャッシュの話PHP 5.5ネーティブキャッシュの話
PHP 5.5ネーティブキャッシュの話
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
 
高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方
 
PostgreSQL WAL for DBAs
PostgreSQL WAL for DBAs PostgreSQL WAL for DBAs
PostgreSQL WAL for DBAs
 
5.6 以前の InnoDB Flushing
5.6 以前の InnoDB Flushing5.6 以前の InnoDB Flushing
5.6 以前の InnoDB Flushing
 
Ext4 filesystem(1)
Ext4 filesystem(1)Ext4 filesystem(1)
Ext4 filesystem(1)
 
DataGuard体験記
DataGuard体験記DataGuard体験記
DataGuard体験記
 
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
 
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみようSolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみよう
 
Memcachedの仕組みと設定
Memcachedの仕組みと設定Memcachedの仕組みと設定
Memcachedの仕組みと設定
 
プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料
プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料
プロトコル/NAT/HTTP通信の中身 〜 ネットワーク勉強会資料
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
 
20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API
 
WSL2使ってみた / Preview for WSL2
WSL2使ってみた / Preview for WSL2WSL2使ってみた / Preview for WSL2
WSL2使ってみた / Preview for WSL2
 
InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)
 
MySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slaveMySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slave
 

Andere mochten auch

カジュアルに本番データを開発環境に入れる #mysqlcasual
カジュアルに本番データを開発環境に入れる #mysqlcasualカジュアルに本番データを開発環境に入れる #mysqlcasual
カジュアルに本番データを開発環境に入れる #mysqlcasualKazuhiro Oinuma
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Yoshinori Matsunobu
 
メンテナブルでありつづけるためのCSS設計
メンテナブルでありつづけるためのCSS設計メンテナブルでありつづけるためのCSS設計
メンテナブルでありつづけるためのCSS設計拓樹 谷
 
Zabbixのパフォーマンスチューニング & インストール時の注意点
Zabbixのパフォーマンスチューニング & インストール時の注意点Zabbixのパフォーマンスチューニング & インストール時の注意点
Zabbixのパフォーマンスチューニング & インストール時の注意点Kodai Terashima
 
本当のオブジェクト指向は可読性を上げる
本当のオブジェクト指向は可読性を上げる本当のオブジェクト指向は可読性を上げる
本当のオブジェクト指向は可読性を上げるWataru Terada
 
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/MinMasahiro Nagano
 
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)Aurimas Mikalauskas
 
MySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことMySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことyoku0825
 
Memory management in Linux
Memory management in LinuxMemory management in Linux
Memory management in LinuxRaghu Udiyar
 
逆説のスタートアップ思考
逆説のスタートアップ思考逆説のスタートアップ思考
逆説のスタートアップ思考Takaaki Umada
 

Andere mochten auch (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
 
逆説のスタートアップ思考
逆説のスタートアップ思考逆説のスタートアップ思考
逆説のスタートアップ思考
 

Ähnlich wie MySQL 初めてのチューニング

Webサーバのチューニング
WebサーバのチューニングWebサーバのチューニング
WebサーバのチューニングYu Komiya
 
Azure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL PoolベストプラクティスAzure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL PoolベストプラクティスMicrosoft
 
Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズAmazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズSORACOM, INC
 
dimSTATから見るベンチマーク
dimSTATから見るベンチマークdimSTATから見るベンチマーク
dimSTATから見るベンチマークhiroi10
 
スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門Hisashi HATAKEYAMA
 
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)Amazon Web Services Japan
 
今日から使い始めるChef
今日から使い始めるChef今日から使い始めるChef
今日から使い始めるChefMasahiro NAKAYAMA
 
Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)Taro Hirose
 
VarnishCache入門Rev2.1
VarnishCache入門Rev2.1VarnishCache入門Rev2.1
VarnishCache入門Rev2.1Iwana Chan
 
States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -States of Dolphin - MySQL最新技術情報2013秋 -
States of Dolphin - MySQL最新技術情報2013秋 -yoyamasaki
 
081108huge_data.ppt
081108huge_data.ppt081108huge_data.ppt
081108huge_data.pptNaoya 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.
 
LINEのMySQL運用について
LINEのMySQL運用についてLINEのMySQL運用について
LINEのMySQL運用についてLINE Corporation
 
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#14Masahiro 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
 

Ähnlich wie 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 パフォーマンスカウンター
 

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