gistfile1.txt

InnoDBの要注意パラメータをピックアップしてってる
 
innodb_adaptive_flushing_lwm
 
innodb_change_buffer_max_size
 
innodb_io_capacity
 
innodb_io_capacity_max
 
innodb_log_file_size 
 
innodb_concurrency_tickets
 
table_open_cache
 
thread_cache_size 
 
```select @@max_connections;```
で max_connectionsを確認。 
 
```pager grep -v Sleep
show processlist;
```
 
`show full processlist` で完全なメッセージ 
 
`pager grep -v Sleep | less` とかパイプできる
 
eq_range_index_dive_limit 
 
mysqlのバージョンは5.6
 
open_tablesとopened_tablesをみている。opened_tablesはめも。
 
eq_range_index_dive_limit の話。
5.6のデフォルトが10、5.7で200。INが多いときはこの数値をあげる。
eq_range_index_dive_limit + 1 以上でINをすると、indexを間違いやすくなる。 
 
5.5にはこの値が無いので、5.6にバージョンアップすると実行計画が急にアホになったようになってしまう（昔minneでもあったらしい）。
 
Q「増やしたことによる弊害は?」
A「Optimizeに時間かかるようになるが、頑張って時間をかけてもそんなに100msもかかるわけではない。あと、5.7でデフォルト200になってるということは...（そこまで弊害はなさそう？）」
 
index diveしたほうが統計情報の性能がいい。
 
10個だと10回index diveする、200個だと200回index diveするが、1回あたりマイクロ秒あたりなので弊害はなさそう。
 
つぎ、table_open_cacheの話。
 
opened_tablesを `show global status` を連圧して様子見してみる。増えたということは、table_open_cacheを増やすなどしてキャッシュを確保してもよさそう。
ただしメモリを消費するので、いきなりガツンと上げるのは注意。
 
thread_cache。接続する時に接続構造体をキャッシュする。キャッシュがあればポインタを使いまわす。なければcloneする。
 
thread_cache_size増やしてもそんな変わらないが、やれることをやっとけと言われたらやるというレベル。
 
```show engine innodb status\G
or
use information_schema;
show tables;
```
 
`select * from innodb_metrics;`
 
`show engine innodb status\G` の中身を pager lessモードでみてる
 
INSERT BUFFER AND ADAPTIVE HASH INDEXを眺めてた
 
innodbはすべてbuffer poolを経由して書き込む。
 
値なんだっけ
 
innodb_buffer_log_size ?
 
128M 2本だとmerge, check pointの頻度が高くなるのでminneのだと足りなそう
 
```---
LOG
---
Log sequence number 4217867003455
Log flushed up to   4217867003455
Pages flushed up to 4217863043390
Last checkpoint at  4217862777021
```
数値は bayt 数
Log sequence number が今
Last checkpoint at が最後の checkpoint
こまめに check point させないようにする
 
メディアだと1G * 2
 
↑書き込みが多いやつだとこれぐらいガッツリ使う。
 
バージョンによっては制限があったが、今はない
 
読み専門だと256MB * 2 
 
なくはないか、サイズが十分大きくなったので大丈夫
 
( ちなみに自分が貼ったのは cmsp の mysql です
 
ibdファイルに書くときはランダムアクセスになってしまう
 
ログはシーケンシャル
 
パラメータは誰か頼む
 
logのほうがibdにかくよりIO負荷が低い
 
innodb_adaptive_flushing_lwm
default 10
dirty page -> まだ check point かかっていない場所
dirty page を flush させにくくする
最大値 70 %
最大値にしていることが多い
 
alterがログを結構使う
 
innodb_io_capacity
ログが食いきらない程度に小さくする
 
innodb_concurrenty_ticketsのはなし
 
今 5000
100 切るくらいまで小さくしている
(理屈の話が脳に浸透しなかった)
 
おなじくｗ
 
mutexに入ったあとのスレッド使い回しの回数？
 
http://d.hatena.ne.jp/sh2/20090618
SH2の日記
MySQL InnoDBにおけるロック競合の解析手順
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時ま..
 
http://d.hatena.ne.jp/sh2/20090618
 
「ロック競合を表示するSQL」
 
ロック待ちがなければ空になるらしい 
 
いま空だった :relaxed:
 
サイトに載っているクエリをコピペして調査している 
 
ロックの情報はどこにも残らない
 
その時ロックがあるかどうかなので、cronとかでポーリングして上げる必要がある
 
結果と時刻をみえるようにしておけば、いつロックしていつなくなったかがわかる
inamuu  
作業でいけないのツライ..
 
SlowLogだけ見て六供町じゃないね、とはいえなくなってきている
 
六供町でもSendingDataと書かれるため区別できない
 
lock 待ちでも sending data となっている
 
なるほどなあ
 
show process listをtopみたいに見るやつ
 
transactionも同じ
 
Undo はそのクエリが今まで何行更新したか
 
便利すぎる…
 
show status がリアルタイムに参照できる 
 
なんてツール！？
 
innotopか
 
show slave status を innotop で眺めると master との差分時間とか見れる
 
全サービス入れよう
 
「だれか pt-query-digest は入ってますか？」
 
RDS からのワンライナーでスロークエリ見れる話 from Qiita 
 
http://qiita.com/ysk_1031/items/0efc7aa17a57316ec328
Qiita
AWS CLIでRDSのスロークエリを見る - Qiita
毎回マネジメントコンソールから確認するのも面倒なので、とりあえずターミナルから見れるように。# AWS CLIのインストールMacにコマンドラインツールが入ってなかったのでインストール。EC2(Amazon Linux)には...
 
mickey  
pt-query-digest , Mac なら `brew install percona-toolkit` で入りそう
 
勝てる
 
calamel で入れた気がするけど全く活用していない...
 
minne のスロークエリをマネジメントコンソールから見てみようの巻 
 
あんまないように見える
 
-> minne はスロークエリはテーブルに吐いてる…？
 
スロークエリをテーブルに書いているとそこがボトルネックになる場合がある
 
ログファイルがデカイとMySQL起動時にファイルポインタを末尾に動かすのに時間かかる -> 起動に時間かかる 
mickey  
スローログは CSV ストレージエンジンてのを使っているらしい
 
https://dev.mysql.com/doc/refman/5.6/ja/csv-storage-engine.html
 
`select * from slow_log limit 3;` 見てる
 
`\c`
 
`\c` で clear できる
 
```mysql> hoge
    -> \c
mysql>
```
 
http://qiita.com/ystg/items/b4a84691c357167c89c2
Qiita
MySQLのコマンドラインで入力をキャンセルする - Qiita
# \cを入力して改行MySQLのコマンドラインで、入力途中でコマンドを取り消したい場合、以下の方法があります。お好みの方法を選択しましょう。1. backspaceですべて消す（改行が入ってると対応できない）2. 諦めて...
 
 
実際に出たスロークエリの EXPLAIN を見る

```# あるある
mysql> ls
;
```
 
実実行で SELECT のパフォーマンス見るときは buffer_pool あっためるために3回くらい実行したときの値を見る
 
use index(primary) 入れてみる -> 1.3secのクエリが 0.01sec に
 
元の index は deleted_at に張られていた
 
deleted_at カラム使わなそうだし消してしまうのはどうか？
 
performance schemaであまり使われないインデクスを調べられる
 
使ってるかどうかは統計情報から確認できる
 
カラム、master で使ってなかったけど slave で使ってて爆死することがあるので注意
 
逆も然り
gyugyu  
カーディナリティが低いカラムに対する index だ
 
最近minneで負荷が高まったときのスロークエリを見てみよう
udzura  
:eyes:
 
火曜夜にやったキャンペーン、2回ほど山があったのでそこを見て見る
 
`select * from mysql.slow_log where start_time > '2017-01-17 19:05:00' and start_time < '2017-01-17 19:10:00' limit 3\G` 
 
CSV ストレージエンジンでは CSV を頭からなめてく
 
＞ Empty set ＜ 
 
一定期間ためるようにしておいた方がよさそう
 
テーブルの上では 0.1 sec も 0.9 sec も 1sec
 
「innodb 圧縮使ってるところはある？」
 
見てみる -> かかってなかった
 
INSERT は基本的に詰まる要素がない -> 時間がかかることがあれば buffer_pool から落ちて引いてくるのを待ってるような状況とか 
 
mackerelでopens_tableを描画してみる。重ねあわせてキャッシュが足りなかったのかな？とか
 
yoku さんのところは細かい DB のパラメータ可視化に cacti 使ってる 
 
manage001にmackerelのプラグインいれてたので、それを見ている
 
mackerel で minne の MySQL データ鑑賞中
 
Opened_tables はメトリクスになかった、残念〜
 
とるようにしよう
 
innodb process list から Sleep を抜いたやつとっとくとよい
 
show processlist も併せてとっておく
 
mackerel-plugin-mysql でとれそうだな
 
innotop をバッチモードでだらだら吐き出しとくのもよし 
 
機嫌が良いときは1秒毎
 
mackerel-plugin-mysqlでenable_extended=trueにするといいみたい…
 
「Unicorn 再起動してる？」「してる。デプロイ時とかリクエスト数に応じてとか」「その時に show create table がキャッシュを食っていくから危ないかも」
 
!
 
質問タイム
 
hiboma「MySQL のソースはどういうふうに読んでますか」
 
エラーメッセージで検索することがおおい
 
パラメータの innodb_* はソース上だと innodb_ はつかない 
 
大体 srv_* が付く
 
ex) srv_buffer_pool_size
 
「ここだけは読んでおいたほうが良いソースは？」
 
include/mysqld_errname.h にエラーメッセージがばっとある
 
そのマクロ名から検索
 
基本的にコアは全部 sql/ 以下にある 
 
エントリポイントは sql/main.cc
 
「MySQL のマニュアルの精度は？」「大体あってる」
 
書いてあることは大体あってるけど情報が足りてないことがしばしばある
 
カーネルだとマニュアル間違ってるからソース読むか、となることがよくある
 
「MySQL 5.7 にあげる利点は？」
 
準同期レプリケーションのスループットが上がった 
 
ロスレス = リレーログが渡っている
 
slave の master 昇格を優先させるケース
 
master と slave どっちを優先させるか
 
レイテンシーはそこまで変わらない
 
準同期レプリケーションのロスレスについて