VM上のMySQL、高IO待つが、TPSが低い
VMへのMySQLインストールの奇妙な状況を把握しようとしています。 Mysql5.7とXFSを搭載したRHEL7を使用しています。
いくつかの選択クエリを実行すると、ディスクの読み取り速度が25〜30 MBpsを超えないことがわかりますが、IOWaitが最大40〜50％競合します。
OSレベルで確認しましたが、ファイルのコピーやその他のディスクの読み取りと書き込みの速度テストを実行しようとすると、500〜600 MBpsを簡単に取得できます（したがって、ディスクではないと想定していますIOボトルネック） ）
IOPSは20,000以上を示し、平均は9〜10,000です。
ディスクの原因を突き止めようとしていますIO十分に高速なディスクと十分なCPUが確保できるまで待ちます。MySQLの主要な変数のいくつかを、以下に示します。
SHOW GLOBAL VARIABLES LIKE innodb_io％
innodb_io_capacity 200
innodb_io_capacity_max 2000
'％thread％'のようなグローバル変数を表示する
innodb_purge_threads 4
innodb_read_io_threads 4
innodb_thread_concurrency 0
innodb_thread_sleep_delay 10000
innodb_write_io_threads 4
max_delayed_threads 20
max_insert_delayed_threads 20
myisam_repair_threads 1
performance_schema_max_thread_classes 50
performance_schema_max_thread_instances -1
thread_cache_size 100
thread_handling接続ごとに1スレッド
thread_stack 262144
グローバルステータスを '％thread％'のように表示
Delayed_insert_threads 0
Performance_schema_thread_classes_lost 0
Performance_schema_thread_instances_lost 0
Slow_launch_threads 2
Threads_cached 61
Threads_connected 561
Threads_created 44399
Threads_running 2
@@ Max_connectionsを選択します：1200
1。遅いクエリの説明は次のとおりです：
EXPLAIN
SELECT COUNT(msgid)
FROM `2018-10-30`
WHERE priority=1
AND (message LIKE '%596f7572204f6e652054696d652050494e20%'
OR message LIKE '%4f545020666f7220%'
OR message LIKE '%4f545020616e642072656620%'
OR message LIKE '%4f545020746f20%'
);
iD 1
select_type SIMPLE
EXPLAIN
SELECT COUNT(msgid)
FROM 2018-10-30
WHERE priority=1
AND (message LIKE '%596f7572204f6e652054696d652050494e20%'
OR message LIKE '%4f545020666f7220%'
OR message LIKE '%4f545020616e642072656620%'
OR message LIKE '%4f545020746f20%'
);
表30-10-2018
パーティション\ N
タイプALL
possible_keys\N
キー\ N
key_len\N
ref\N
行28431345
フィルタリング3.76
追加の使用場所
2。遅いクエリの説明は次のとおりです：
EXPLAIN
SELECT COUNT(msgid)
FROM `2018-10-30`
WHERE priority=1
AND ISDFlag=0
AND msgsubmitid IS NOT NULL
AND (message LIKE '%596f7572204f6e652054696d652050494e20%'
OR message LIKE '%4f545020666f7220%'
OR message LIKE '%4f545020616e642072656620%'
OR message LIKE '%4f545020746f20%'
);
id 1
select_type SIMPLE
表30-10-2018
パーティション\ N
タイプALL
possible_keys index_msgsubmitid
キー\ N
key_len\N
参照\ N
行28431345
フィルタリングされた0.19
追加の使用場所
テーブルを作成
"CREATE TABLE 2018-10-30（MsgId bigint（20）NOT NULL、UserId int（11）NOT NULL、Status bit（1）DEFAULT NULL、Priority int（11）NOT NULL、MsgStatus int（11）DEFAULT '1111'、DestinationNumber varchar（50）NOT NULL、OrginatorName varchar（11）DEFAULT NULL、OrginatorNumber varchar（20）DEFAULT NULL、MsgSubmitID varchar（100）デフォルトのNULL、MsgStatusMsg varchar（1000）DEFAULT NULL、MsgDeliveryDateTime varchar（50）DEFAULT NULL、Message varchar（500）NOT NULL、IPaddress varchar（15）NOT NULL、TransDate datetime NOT NULL、SubmitDateTime datetime DEFAULT NULL、SMSType int（11）DEFAULT NULL、DateTimeToSend datetime DEFAULT NULL、Subject varchar（100）DEFAULT NULL、ISDFlag tinyint（4）DEFAULT NULL、GatewayID int（11）DEFAULT NULL、SmscSubmitDateTime datetime DEFAULT NULL、ClientMsgId varchar（100）DEFAULT NULL、Source int（10）DEFAULT '0'、CreatedDateTime datetime NOT NULL DEFAULT CURRENT_TIMESTAMP、UpdatedDateTime datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP、
主キー（MsgId）、
KEY index_msgsubmitid（MsgSubmitID）、
KEY index_gatewayid（GatewayID）、
キーindex_TransDate（TransDate）、
KEY index_dstn_no（DestinationNumber）、
キーindex_UserId（UserId）、
KEY index_MsgStatus（MsgStatus）
）ENGINE = InnoDB DEFAULT CHARSET = latin1 "
テーブルインデックス
ロード中のiostat
[ ~]$ iostat -xm 5 3
Linux 3.10.0-957.5.1.el7.x86_64 (...) 04/09/2019 _x86_64_ (24 CPU)
avg-cpu: %user %Nice %system %iowait %steal %idle
4.13 0.00 1.54 1.56 0.00 92.77
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
fd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 31.50 31.50 0.00 31.50 0.00
sde 0.00 0.03 45.51 54.98 0.73 2.30 61.65 0.17 1.64 0.95 2.22 0.49 4.89
sdi 0.00 0.00 0.46 0.18 0.23 0.09 1016.01 0.02 31.79 6.59 95.41 1.15 0.07
sdh 0.00 1.77 112.94 27.89 1.77 0.69 35.77 0.13 0.96 0.79 1.65 0.48 6.83
sdc 0.00 0.18 114.18 144.24 2.11 7.36 75.07 0.33 1.26 0.95 1.50 0.45 11.62
sda 0.00 0.01 0.01 0.04 0.00 0.00 245.47 0.00 9.96 4.75 11.82 0.84 0.00
sdj 0.00 0.01 65.86 4.17 1.04 0.10 33.41 0.06 0.87 0.80 1.92 0.54 3.77
sdd 0.57 0.91 0.12 0.18 0.00 0.00 64.37 0.00 4.88 1.43 7.12 1.90 0.06
sdb 0.00 0.05 12.34 7.21 0.31 0.37 71.69 0.03 1.30 0.88 2.03 0.57 1.11
sdf 0.00 0.00 33.24 9.79 0.52 0.33 40.69 0.04 1.01 0.82 1.67 0.53 2.27
sdg 0.00 0.00 71.83 6.64 1.12 0.26 35.98 0.07 0.84 0.72 2.13 0.51 3.97
dm-0 0.00 0.00 2.73 1.44 0.15 0.01 76.44 0.00 1.17 1.31 0.90 0.60 0.25
dm-1 0.00 0.00 0.68 1.09 0.00 0.00 8.01 0.02 10.23 1.22 15.91 0.31 0.06
dm-2 0.00 0.00 453.14 249.19 7.43 11.24 54.44 0.81 1.15 0.84 1.72 0.30 21.30
dm-3 0.00 0.00 0.00 0.04 0.00 0.00 105.64 0.00 10.38 2.45 10.40 0.56 0.00
dm-4 0.00 0.00 0.49 0.50 0.24 0.23 981.47 0.03 25.41 6.51 44.16 1.00 0.10
dm-5 0.00 0.00 0.01 6.02 0.00 0.03 9.42 0.01 1.07 4.12 1.07 0.46 0.28
avg-cpu: %user %Nice %system %iowait %steal %idle
4.40 0.00 1.44 15.94 0.00 78.22
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
fd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.00 941.00 4.40 14.70 1.94 36.05 0.90 0.96 0.92 9.68 0.81 76.62
sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdh 0.00 2.00 0.00 3.80 0.00 0.03 13.47 0.00 0.58 0.00 0.58 0.32 0.12
sdc 0.00 0.40 863.40 247.00 13.49 11.70 46.46 1.12 1.01 0.78 1.80 0.63 69.84
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdj 0.00 0.00 0.00 0.20 0.00 0.00 16.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 62.40 0.00 0.97 31.80 0.08 1.25 0.00 1.25 0.14 0.88
sdf 0.00 0.00 1818.40 0.00 28.41 0.00 32.00 2.10 1.15 1.15 0.00 0.54 98.94
sdg 0.00 0.00 131.40 0.20 2.05 0.00 32.00 0.18 1.34 1.34 1.00 1.33 17.50
dm-0 0.00 0.00 0.00 0.60 0.00 0.00 11.33 0.00 0.67 0.00 0.67 0.33 0.02
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 3754.60 314.00 58.67 14.61 36.88 4.38 1.08 1.02 1.79 0.25 99.90
dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-5 0.00 0.00 0.00 5.80 0.00 0.03 8.83 0.00 0.38 0.00 0.38 0.24 0.14
avg-cpu: %user %Nice %system %iowait %steal %idle
4.30 0.00 1.36 15.71 0.00 78.62
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
fd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.00 1004.60 3.60 15.70 1.70 35.34 0.89 0.89 0.86 9.11 0.78 78.80
sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdh 0.00 2.00 0.00 3.80 0.00 0.02 13.05 0.00 0.74 0.00 0.74 0.63 0.24
sdc 0.00 0.00 883.40 135.60 13.80 7.78 43.37 0.87 0.86 0.78 1.35 0.69 70.42
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdj 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 28.00 0.00 0.44 32.00 0.03 1.15 0.00 1.15 0.19 0.54
sdf 0.00 0.00 1762.60 0.00 27.54 0.00 32.00 2.09 1.19 1.19 0.00 0.56 98.88
sdg 0.00 0.00 126.00 0.00 1.97 0.00 32.00 0.18 1.39 1.39 0.00 1.39 17.54
dm-0 0.00 0.00 0.00 0.20 0.00 0.00 32.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 3776.20 167.00 59.00 9.91 35.79 4.07 1.03 1.01 1.49 0.25 99.96
dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-5 0.00 0.00 0.00 5.80 0.00 0.02 8.55 0.00 0.83 0.00 0.83 0.41 0.24
マウント出力
$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=49397072k,nr_inodes=12349268,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/rhel-root on / type xfs (rw,relatime,attr2,inode64,noquota)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
/dev/mapper/rhel-var on /var type xfs (rw,relatime,attr2,inode64,noquota)
/dev/mapper/rhel-home on /home type xfs (rw,nosuid,nodev,noexec,relatime,attr2,inode64,noquota)
/dev/mapper/rhel-tmp on /tmp type xfs (rw,relatime,attr2,inode64,noquota)
/dev/mapper/rhel-lv_dam on /dam_agent type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /boot type xfs (rw,relatime,attr2,inode64,noquota)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/42 type tmpfs (rw,nosuid,nodev,relatime,size=9882784k,mode=700,uid=42,gid=42)
tmpfs on /run/user/987 type tmpfs (rw,nosuid,nodev,relatime,size=9882784k,mode=700,uid=987,gid=981)
tmpfs on /run/user/1012 type tmpfs (rw,nosuid,nodev,relatime,size=9882784k,mode=700,uid=1012,gid=1012)
tmpfs on /run/user/1005 type tmpfs (rw,nosuid,nodev,relatime,size=9882784k,mode=700,uid=1005,gid=1005)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=51,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19059084)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=9882784k,mode=700)
サーバー統計
Cpus：24
コア：24
ソケット：12
RAM：96GB
ioping Stats
調査中に、次のioping統計が見つかりました。これは、一部のpingが5ミリ秒にもなることを示していますが、これがディスクに影響を与える可能性があるかどうかを調査していますIO帯域幅：
# ioping /var/
4 KiB <<< /var/ (xfs /dev/dm-2): request=1 time=6.12 ms (warmup)
4 KiB <<< /var/ (xfs /dev/dm-2): request=2 time=569.9 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=3 time=618.6 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=4 time=505.7 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=5 time=534.8 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=6 time=744.6 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=7 time=1.10 ms (slow)
4 KiB <<< /var/ (xfs /dev/dm-2): request=8 time=447.6 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=9 time=578.0 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=10 time=1.11 ms (slow)
4 KiB <<< /var/ (xfs /dev/dm-2): request=11 time=586.4 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=12 time=449.4 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=13 time=402.0 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=14 time=650.4 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=15 time=497.9 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=16 time=4.78 ms (slow)
4 KiB <<< /var/ (xfs /dev/dm-2): request=17 time=534.5 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=18 time=8.27 ms (slow)
4 KiB <<< /var/ (xfs /dev/dm-2): request=19 time=876.8 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=20 time=3.99 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=21 time=1.04 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=22 time=1.20 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=23 time=980.6 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=24 time=2.26 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=25 time=794.6 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=26 time=963.0 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=27 time=1.91 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=28 time=1.04 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=29 time=643.9 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=30 time=1.40 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=31 time=837.2 us
4 KiB <<< /var/ (xfs /dev/dm-2): request=32 time=1.54 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=33 time=5.13 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=34 time=381.3 us (fast)
4 KiB <<< /var/ (xfs /dev/dm-2): request=35 time=1.03 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=36 time=1.27 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=37 time=1.99 ms
4 KiB <<< /var/ (xfs /dev/dm-2): request=38 time=827.9 us
^C
--- /var/ (xfs /dev/dm-2) ioping statistics ---
37 requests completed in 52.5 ms, 148 KiB read, 705 iops, 2.75 MiB/s
generated 38 requests in 37.5 s, 152 KiB, 1 iops, 4.06 KiB/s
min/avg/max/mdev = 381.3 us / 1.42 ms / 8.27 ms / 1.59 ms
MySQLTuner出力は次のリンクにあります： https://Pastebin.com/H4pxRttg
MySQL my.cnf： https://Pastebin.com/CEcjvBRS
グローバルステータスを表示： https://Pastebin.com/c54xPmtT
グローバル変数を表示： https://Pastebin.com/9edrGmaL
プロセスリストを表示： https://Pastebin.com/gNwF0KpG
上
Ulimit
iostat
iostat2
df
どこを見ればよいかについての洞察をいただければ幸いです。
問題は、messageフィールドがvarchar()であり、インデックス付けされていない列全体で全文検索を実行していることです。クエリでは、先頭の%は、MySQLが従来のBTREEインデックスの最初のワイルドカードの前のデータのプレフィックスしか使用できないため、データの列全体の全文スキャンを引き起こします。
MySQLで全文検索を行うことは良いユースケースではありませんが、MySQLを使用することにした場合は、FULLTEXTインデックスを確認してください。これにより、MySQLは全表スキャンなしでデータを効率的にクエリできます。 。
https://dev.mysql.com/doc/refman/8.0/en/innodb-fulltext-index.html
InnoDBを調整しても、スキーマやクエリの設計の問題は修正されません。
COUNTsだけやってるの？そうでない場合は、realクエリを表示してください。 COUNTを高速にするためのショートカットがあります。それが本当の目標でない限り、私たちはそれらについて議論すべきではありません。
_SELECT COUNT(msgid)
FROM `2018-10-30`
WHERE priority=1
AND (message LIKE '%596f7572204f6e652054696d652050494e20%'
OR message LIKE '%4f545020666f7220%'
OR message LIKE '%4f545020616e642072656620%'
OR message LIKE '%4f545020746f20%'
);
_COUNT(msgid)とは言わないでください。これは、msgidが_NOT NULL_であることをテストすることを意味します。単にCOUNT(*)と言います。
主要なワイルドカードとORはどちらもパフォーマンスキラーです。ただし、REGEXPmightに変更すると、速度が向上します。現在、message列は最大4回スキャンされます。以下を使用すると、すべてが「一度に」実行されます。
_AND message REGEXP '596f7572204f6e652054696d652050494e20|4f545020666f7220|4f545020616e642072656620|4f545020746f20'
_priorityは4バイトを使用するようになりました。 TINYINTで十分ではないでしょうか？
もう1つの可能なスピードアップは、カバーインデックスを持つことです（そして `COUNT（*）を使用します）：
_INDEX(priority, message, ISDFlag, msgsubmitid)
_そうすると、提示したクエリはどれもスキャンするものが少なくなります。はるかに広いデータのBTreeではなく、インデックスのBTreeをスキャンします。
[〜＃〜] iops [〜＃〜]
テーブルのブロックはbuffer_poolにキャッシュされます。それがいっぱいになると、I/Oがいくつかのブロックを蹴り出し、他のブロックを持ち込みます。メインテーブルが本当に大きい場合は、I/Oが期待できます。それがbuffer_poolに収まる場合、テーブルスキャンであってもI/Oが表示されない可能性があります可能性があります。
[〜＃〜] unhex [〜＃〜]-messageはすべて16進数のようです。そうである場合は、UNHEX()およびHEX()を使用して、列がVARBINARY(250)になるように宣言し、サイズの半分になるようにします。繰り返しますが、小さい->少ないI/O（テーブルが大きすぎてキャッシュできない場合）。
innodb_buffer_pool_size-その値は何ですか？ 96GBのRAMを使用すると、約75Gになります。テーブルの大きさはどれくらいですか？このようなテーブルはたくさんありますか？ぎこちないテーブル名に基づいて、そこにあるのは間違いないでしょう。
同じメッセージが2つの異なる日に発生した場合はどうなりますか？
変数とステータスの分析
観察：
- バージョン：5.7.20-log
- 94.2GBのRAM
- 稼働時間= 30d 02:56:40
- Windowsで実行していません。
- 64ビットバージョンを実行しています
- 完全に（またはほとんど）InnoDBを実行しているようです。
より重要な問題：
いくつかの提案された変数の変更：
_innodb_page_cleaners = 16
innodb_buffer_pool_instances = 16
innodb_lru_scan_depth = 256
innodb_read_io_threads = 8
innodb_write_io_threads = 8
long_query_time = 2
_SELECTが非常に少ないですか？これは主に「書き込み専用」ですか？挿入はバッチ処理されますか？
_innodb_log_file_size_は、大量の書き込みアクティビティの場合よりも小さいですが、今変更する価値はありません。 （5Gは2Gより優れています。）
SSDを使用している場合は、_innodb_flush_neighbors_をオフにすることもできます。
I/Oは_innodb_io_capacity = 200_が示す以上の処理を行っているようです。それを上げます。 500を提案します。
レプリケーションは含まれていますか？マシンはスレーブですか？特に、レプリケーションに関連する値の一部が奇妙に見えます。_slave_skip_errors_が奇妙な値に設定されています。あなたは「敷物の下で問題を掃除していますか？」
SELECTのほぼ半分がテーブルスキャンを実行します。これはかなり高く、おそらく調査が必要です。 OTOH、選択の数はかなり少ないです。
保存されたルーチンを1日に約4回交換するのは、かなり高いです。
_SHOW TABLES_は1秒間に2〜3回発生していますが、これは避けられませんか？
詳細およびその他の所見：
_( Innodb_buffer_pool_reads ) = 1,006,346,347 / 2602600 = 386 /sec_- InnoDB buffer_pool I/O読み取り速度-innodb_buffer_pool_sizeを確認します
_( Innodb_buffer_pool_pages_flushed ) = 513,074,244 / 2602600 = 197 /sec_-書き込み（フラッシュ）-innodb_buffer_pool_sizeを確認します
_( Key_blocks_used * 1024 / key_buffer_size ) = 19 * 1024 / 1024M = 0.00%_-使用されたkey_bufferのパーセント。最高水準点。 -不要なメモリ使用を回避するために、key_buffer_sizeを小さくします。
_( table_open_cache ) = 32,163_-キャッシュするテーブル記述子の数-通常は数百が適切です。
_( innodb_buffer_pool_size / innodb_buffer_pool_instances ) = 71680M / 8 = 8960MB_-各buffer_poolインスタンスのサイズ。 -インスタンスは少なくとも1GBである必要があります。非常に大きなRAMには、16のインスタンスがあります。
_( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096_-1秒あたりのページクリーナーの作業量。 -"InnoDB：page_cleaner：1000msの意図されたループがかかりました..." lru_scan_depthを下げることで修正できる可能性があります：1000/innodb_page_cleanersを検討してください
_( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 8 = 0.5_ --innodb_page_cleaners-innodb_page_cleanersをinnodb_buffer_pool_instancesに設定することをお勧めします
_( innodb_lru_scan_depth ) = 1,024_- "InnoDB：page_cleaner：1000msの意図されたループがかかりました..." lru_scan_depthを下げることで修正できます
_( (Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) ) = ((1006346347 + 513074244) ) / 2602600 = 583 /sec_- InnoDB I/O-innodb_buffer_pool_sizeを増やしますか？
_( Innodb_os_log_written ) = 7,973,352,303,616 / 2602600 = 3063610 /sec_-これはInnoDBのビジー状態の指標です。 -非常にアイドル状態または非常にビジーなInnoDB。
_( Innodb_log_writes ) = 1,662,275,231 / 2602600 = 638 /sec_
_( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 7,973,352,303,616 / (2602600 / 3600) / 2 / 2048M = 2.57_-比率-（分を参照）
_( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 2,602,600 / 60 * 2048M / 7973352303616 = 11.7_-InnoDBログローテーション間の分5.6.8以降、これは動的に変更できます。 my.cnfも必ず変更してください。 -（ローテーション間の60分の推奨は多少恣意的です。）innodb_log_file_sizeを調整します。 （AWSでは変更できません。）
_( Com_rollback ) = 760,459 / 2602600 = 0.29 /sec_- InnoDBのロールバック。 -ロールバックの頻度が高すぎる場合は、アプリロジックが非効率的であることを示している可能性があります。
-（OTOH、Com_rollbackはCom_commitと比較して非常に低いです。）
_( Innodb_dblwr_writes ) = 29,374,160 / 2602600 = 11 /sec_-「ダブルライトバッファ」はディスクに書き込みます。 「ダブルライト」は信頼性機能です。新しいバージョン/構成の中には、それらを必要としないものがあります。 -（その他の問題の症状）
_( innodb_flush_neighbors ) = 1_-ブロックをディスクに書き込むときのマイナーな最適化。 -SSDドライブには0を使用します。 HDDの場合は1。
_( ( Innodb_pages_read + Innodb_pages_written ) / Uptime / innodb_io_capacity ) = ( 1021090541 + 513083786 ) / 2602600 / 200 = 294.7%_- 100％を超える場合は、さらにio_capacityが必要です。 -ドライブが処理できる場合は、innodb_io_capacityを増やします。
_( innodb_io_capacity ) = 200_-ディスクで可能な1秒あたりのI/Oops。遅いドライブの場合は100。ドライブの回転には200。 SSDの場合は1000〜2000。 RAID係数を掛けます。
_( sync_binlog ) = 0_-セキュリティを強化するために1を使用します。I/ O = 1のコストがかかると、多くの「クエリ終了」が発生する可能性があります。 = 0は、「不可能な位置でのbinlog」につながり、クラッシュ時にトランザクションを失う可能性がありますが、より高速です。
_( innodb_thread_concurrency ) = 0_- 0 = InnoDBにconcurrency_ticketsに最適なものを決定させます。 --0または64に設定します。これによりCPUが削減される可能性があります。
_( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF_-すべてのデッドロックをログに記録するかどうか。 -デッドロックに悩まされている場合は、これをオンにします。注意：デッドロックが多数ある場合、ディスクに大量の書き込みが発生する可能性があります。
_( local_infile ) = local_infile = ON_ --local_infile = ONは潜在的なセキュリティ問題です
_( bulk_insert_buffer_size / _ram ) = 8M / 101146479820.8 = 0.01%_-複数行のINSERTおよびLOAD DATAのバッファー-大きすぎるとRAMサイズが脅かされる可能性があります。小さすぎると、そのような操作が妨げられる可能性があります。
_( (Queries-Questions)/Queries ) = (5936481203-59444814)/5936481203 = 99.0%_-保存されたルーチン内にあるクエリの割合。 -（高くても悪くはありませんが、他の結論の妥当性に影響を与えます。）
_( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (2193033569 + 372855165 + 1643709242 + 0) / 1660237104 = 2.54_-コミットごとのステートメント（すべてのInnoDBを想定）-低：トランザクションでクエリをグループ化するのに役立つ可能性があります。高：長いトランザクションはさまざまなことに負担をかけます。
_( Select_scan ) = 7,124,788 / 2602600 = 2.7 /sec_-全テーブルスキャン-インデックスを追加する/クエリを最適化する（小さなテーブルでない限り）
_( Select_scan / Com_select ) = 7,124,788 / 15138927 = 47.1%_-全表スキャンを実行している選択の％。 （ストアドルーチンにだまされる可能性があります。）-インデックスを追加する/クエリを最適化する
_( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (2193033569 + 1643709242 + 0 + 0 + 372855165 + 571) / 2602600 = 1617 /sec_-書き込み/秒-50書き込み/秒+ログのフラッシュにより、通常のドライブのI/O書き込み容量が最大になる
_( expire_logs_days ) = 3_-binlogを自動的にパージするまでの時間（この日数が経過した後）-大きすぎる（またはゼロ）=ディスク領域を消費します。小さすぎる=ネットワーク/マシンのクラッシュに迅速に対応する必要があります。 （log_bin = OFFの場合は関係ありません）
_( slave_pending_jobs_size_max / max_allowed_packet ) = 16M / 4M = 4_-並列スレーブスレッドの場合-slave_pending_jobs_size_maxはmax_allowed_packet以上である必要があります
_( slave_skip_errors ) = slave_skip_errors = 1 03 21 05 41 062_-無視するエラーケース-ラグの下で問題をスイープするよりもコードを変更する方が良いでしょう。
_( long_query_time ) = 10_-「遅い」クエリを定義するためのカットオフ（秒）。 -提案2
異常に小さい：
_(Com_select + Qcache_hits) / (Com_insert + Com_update + Com_delete + Com_replace) = 0.0036
_異常に大きい：
_( Innodb_pages_read + Innodb_pages_written ) / Uptime = 589
Binlog_cache_use = 635 /sec
Com_begin = 633 /sec
Com_commit = 637 /sec
Com_commit + Com_rollback = 638 /sec
Com_create_procedure = 0.15 /HR
Com_dealloc_sql = 39 /HR
Com_delete = 631 /sec
Com_do = 2.3 /HR
Com_drop_procedure = 0.15 /HR
Com_execute_sql = 42 /HR
Com_insert = 842 /sec
Com_load = 0.79 /HR
Com_prepare_sql = 42 /HR
Com_rename_table = 0.05 /HR
Com_show_create_proc = 2.9 /sec
Com_show_tables = 2.6 /sec
Com_show_warnings = 92 /HR
Com_signal = 4.6 /HR
Com_slave_start = 0.0014 /HR
Com_slave_stop = 0.0014 /HR
Com_update = 143 /sec
Handler_commit = 4507 /sec
Handler_delete = 635 /sec
Handler_prepare = 4503 /sec
Handler_update = 2978 /sec
Innodb_buffer_pool_pages_data = 4.51e+6
Innodb_buffer_pool_pages_total = 4.59e+6
Innodb_buffer_pool_write_requests = 27091 /sec
Innodb_data_read = 6426970 /sec
Innodb_data_reads = 392 /sec
Innodb_data_writes = 848 /sec
Innodb_data_writes - Innodb_log_writes - Innodb_dblwr_writes = 198 /sec
Innodb_data_written = 9506808 /sec
Innodb_dblwr_pages_written = 196 /sec
Innodb_log_write_requests = 4670 /sec
Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group = 5,259.0MB
Innodb_pages_created = 30 /sec
Innodb_pages_read = 392 /sec
Innodb_pages_read + Innodb_pages_written = 1.53e+9
Innodb_pages_written = 197 /sec
Innodb_rows_deleted = 635 /sec
Innodb_rows_deleted + Innodb_rows_inserted = 1945 /sec
Innodb_rows_inserted = 1310 /sec
Innodb_rows_updated = 663 /sec
Max_execution_time_set = 16
Ongoing_anonymous_transaction_count = 1
Open_tables = 4,129
Performance_schema_digest_lost = 2.23e+7
Select_range / Com_select = 49.2%
Threads_cached = 315
auto_increment_offset = 2
innodb_open_files = 32,163
port = 3317
report_port = 3317
_異常な文字列：
_Ssl_session_cache_mode = Unknown
event_scheduler = ON
have_ssl = YES
have_symlink = DISABLED
innodb_data_home_dir = /var/lib/mysql
innodb_fast_shutdown = 1
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
session_track_system_variables = time_zone, autocommit, character_set_client, character_set_results, character_set_connection
slave_compressed_protocol = ON
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
_MySQL IOPSを改善するためにインスタンスで検討すべき提案、
SET GLOBAL innodb_io_capacity_max=18000 # from 2000
SET GLOBAL innodb_io_capacity=9000 # from 200
テスト用で、サービスの次の停止/開始の前にmy.cnf [mysqld]セクションに適用されます。
免責事項：私は自分のプロファイル、ネットワークプロファイルに記載されているWebサイトのコンテンツ作成者であり、追加の提案を提供できます。
2019年4月18日、SET GLOBAL variable_name = valueは「新しい接続」に適用されるため、IO待機時間への影響を確認するには、最低1時間待ってください。プロセスに通常3時間かかる場合は、3時間待って影響を確認してください。
1秒あたりのレート= RPS-my.cnf [mysqld]セクションで検討する提案。これらはすべて動的変数であり、SET GLOBAL global_name = Valueで設定できます。
read_rnd_buffer_size=262144 # from 8M to reduce handler_read_rnd_next RPS of 22,915
read_buffer_size=262144 # from 2M to reduce handler_read_next RPS of 52,015
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
innodb_flushing_avg_loops=5 # from 30 to reduce innodb_buffer_pool_pages_dirty count of 17,452
innodb_change_buffer_max_size=15 # from 25 percent set aside from innodb_buffer_pool_size
免責事項：私は自分のプロファイル、連絡先情報を含むネットワークプロファイルで指定されたサイトのWebコンテンツの作成者です。
SHOW GLOBAL STATUS LIKE '％dirty％'を使用できます。 innodbデータテーブルのREADSRPSの削減にプラスの影響を与える、innodb_buffer_pool_dirty_pagesカウントの削減を1時間ごとに確認します。