web-dev-qa-db-ja.com

pt-query-digest出力の上にCOMMIT

私は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
6
LeG

法医学...

  • COMMITsの時間の中央値:16ミリ秒。
  • ディスク書き込みの典型的な時間:10ms。
  • デフォルト設定のinnodb_flush_log_at_trx_commit:1は、コミットのたびにディスクにフラッシュすることを意味します。

結論:キラーはライブラリでローソク足を使用しました。または..あなたがしていることのほとんどは、非常に迅速にトランザクションをコミットすることです。

スピードアップする可能な方法:

  • innodb_flush_log_at_trx_commit = 2-これは、トランザクションごとに1回ではなく、毎秒1回フラッシュします。それはそれほど安全ではありませんが、someユーザーにとってはトレードオフの価値があります。
  • アクションをバッチ処理します。 INSERTごとに1つのCOMMITではなく、INSERTsをたくさん実行します。 COMMITの主なコストは、トランザクションの進行状況に関係なく、1回の書き込みをロールバックログにフラッシュすることです。
  • ハードウェア-SSD-10msを1msに落とします(またはそのようなもの)。バッテリーバックアップ式ライトキャッシュを備えたRAID-安全性を失うことなく、書き込みに実質的に0 msかかります。
  • いくつかのCOMMITsが1秒以上かかっているので、それらを探して、トランザクションが改善されるかどうかを確認できます。
1
Rick James

要するに

使用する SHOW ENGINE INNODB STATUSより多くの情報を取得します。

ロングバージョン

これは、あなたのCOMMITに長い時間がかかることを意味します。それを引き起こす可能性があるサーバーの問題があります:

  • CPUバウンドまたはI/Oバウンド。

    この場合、どのトランザクションが遅いかを見つけ、それを最適化することができます。

  • InnoDBロック。

    この場合、取得されるロックの種類と起こり得るデッドロック(InnoDBでは検出されない可能性があります)を確認し、最適化できます。

0
Gea-Suan Lin