私はMySQLサーバーを最適化しており、いくつかのクエリを調整した後、下の抜粋に示すように、pt-query-digest出力の上にCOMMITアイテムができました。
# 322s user time, 770ms system time, 71.75M rss, 223.13M vsz
# Current date: Sat Oct 1 11:12:58 2016
# Hostname: XXXX
# Files: /home/tools/Slow10.log
# Overall: 1.08M total, 1.47k unique, 61.74 QPS, 0.17x concurrency _______
# Time range: 2016-10-01 06:15:09 to 11:06:35
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 2913s 1us 14s 3ms 15ms 27ms 194us
# Lock time 123s 0 2s 113us 167us 3ms 42us
# Rows sent 1019.81k 0 8.58k 0.97 0.99 26.59 0
# Rows examine 314.86M 0 2.13M 305.82 234.30 7.13k 0
# Query size 321.03M 6 14.64k 311.81 1.14k 743.10 88.31
# Profile
# Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== =============== ====== ====== ===== ============
# 1 0x813031B8BBC3B329 1676.7355 57.6% 70006 0.0240 0.02 COMMIT
# 2 0xBC10C51A724ECD57 61.8928 2.1% 211 0.2933 0.08 SELECT users
クエリは次のように表示されます。
# Query 1: 4.00 QPS, 0.10x concurrency, ID 0x813031B8BBC3B329 at byte 462955973
# This item is included in the report because it matches --limit.
# Scores: V/M = 0.02
# Time range: 2016-10-01 06:15:09 to 11:06:34
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 6 70006
# Exec time 57 1677s 9us 2s 24ms 56ms 24ms 16ms
# Lock time 0 0 0 0 0 0 0 0
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 0 0 0 0 0 0 0 0
# Query size 0 410.19k 6 6 6 6 0 6
# String:
# Databases XXX_XX... (9419/13%)... 40 more
# Hosts localhost
# Query_time distribution
# 1us #
# 10us #
# 100us #
# 1ms ####
# 10ms ################################################################
# 100ms #
# 1s #
# 10s+
commit\G
どうすればこれを最適化できますか?
さらに情報が必要な場合はお知らせください!
前もって感謝します!
編集2016-02-10:クエリ最適化前の最初の分析は次のようになりました:
# Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== ================ ======= ====== ===== ==========
# 1 0x62057CDB69C17D23 18377.2125 46.3% 139328 0.1319 0.15 SELECT AAAA
# 2 0xEC77079791A0E274 6992.0443 17.6% 127446 0.0549 0.09 SELECT BBBB
# 3 0xB8A934DECC36D811 6283.1217 15.8% 247595 0.0254 0.03 UPDATE users_sessions
# 4 0x813031B8BBC3B329 2042.6094 5.1% 89046 0.0229 0.04 COMMIT
サーバーには8 GbがありますRAM with innodb_buffer_pool_size=5G
それぞれ約140のテーブルを持つ約70のデータベース。
2016-10-06を編集:
# grep innodb /etc/my.cnf
innodb_flush_method=O_DIRECT
innodb_buffer_pool_size=5G
innodb_log_buffer_size=4M
法医学...
COMMITs
の時間の中央値:16ミリ秒。innodb_flush_log_at_trx_commit
:1は、コミットのたびにディスクにフラッシュすることを意味します。結論:キラーはライブラリでローソク足を使用しました。または..あなたがしていることのほとんどは、非常に迅速にトランザクションをコミットすることです。
スピードアップする可能な方法:
innodb_flush_log_at_trx_commit = 2
-これは、トランザクションごとに1回ではなく、毎秒1回フラッシュします。それはそれほど安全ではありませんが、someユーザーにとってはトレードオフの価値があります。INSERT
ごとに1つのCOMMIT
ではなく、INSERTs
をたくさん実行します。 COMMIT
の主なコストは、トランザクションの進行状況に関係なく、1回の書き込みをロールバックログにフラッシュすることです。COMMITs
が1秒以上かかっているので、それらを探して、トランザクションが改善されるかどうかを確認できます。使用する SHOW ENGINE INNODB STATUS
より多くの情報を取得します。
これは、あなたのCOMMIT
に長い時間がかかることを意味します。それを引き起こす可能性があるサーバーの問題があります:
CPUバウンドまたはI/Oバウンド。
この場合、どのトランザクションが遅いかを見つけ、それを最適化することができます。
InnoDBロック。
この場合、取得されるロックの種類と起こり得るデッドロック(InnoDBでは検出されない可能性があります)を確認し、最適化できます。