pos機客戶反饋, 客戶說 insert 慢

新聞資訊 | 2023-04-23 10:05 | 投稿人：pos機之家

網(wǎng)上有很多關于pos機客戶反饋, 客戶說 insert 慢的知識，也有很多人為大家解答關于pos機客戶反饋的問題，今天pos機之家(m.afbey.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機客戶反饋

pos機客戶反饋

作者：張昊

DBA，主要負責mysql故障處理、DMP產品支持，擅長MySQL，喜歡打球~唱歌~。本文來源：原創(chuàng)投稿

*愛可生開源社區(qū)出品，原創(chuàng)內容未經(jīng)授權不得隨意使用，轉載請聯(lián)系小編并注明來源。

本文章比較側重于分析流程，細節(jié)方面可能有所不足。

嘮嗑環(huán)節(jié)

前段時間客戶反饋有 insert 慢，查看 slow.log ，發(fā)現(xiàn)確實慢，不光它慢，別的也慢；(客戶只關注客戶的重點，運維要全面的進行分析)。

之前也遇到過類似問題，從領導那里求取真經(jīng)，下面給大家簡單分享下真經(jīng)內容：

先整體觀察某一天或這某個時間段內慢sql的記錄情況，重點觀察慢sql記錄時間點、sql類型；如果是insert之類的sql慢，懷疑的維度大概是：磁盤io、鎖、半同步復制；如果有批量慢sql的情況，重點關注select，用以排查半同步復制。開始實戰(zhàn)1. 宏觀統(tǒng)計 slow.log ，經(jīng)過統(tǒng)計發(fā)現(xiàn)慢 sql 呈現(xiàn)出批量慢的情況

記錄到 slow.log 的 sql 類型比較多，有 select 、insert 、delete 、update 、COMMIT 和 show 開頭的管理類 sql 。

[root@big hao]# less slow.log |grep "# Tim"|awk -F "." '{print $1}'|termsql -0 "select COL2 time,COUNT(COL2) sql_count from tbl group by COL2"time|sql_count2022-08-30T00:05:56|632022-08-30T00:27:37|652022-08-30T00:34:58|312022-08-30T00:49:22|652022-08-30T00:56:41|612022-08-30T01:11:04|642022-08-30T01:32:50|632022-08-30T01:40:06|602022-08-30T01:54:32|592022-08-30T02:01:47|582022-08-30T02:16:16|622022-08-30T02:23:28|582022-08-30T02:37:58|582022-08-30T02:45:10|542022-08-30T02:59:40|442022-08-30T03:06:52|552022-08-30T03:21:24|552022-08-30T03:28:35|592022-08-30T03:43:08|272022-08-30T03:50:17|272022-08-30T04:04:53|582022-08-30T04:11:59|482022-08-30T04:26:34|602022-08-30T04:33:41|282022-08-30T04:48:19|242022-08-30T05:10:04|592022-08-30T05:17:07|602022-08-30T05:31:47|452022-08-30T05:38:48|612022-08-30T05:53:30|652022-08-30T06:00:30|632022-08-30T06:15:16|642022-08-30T06:22:14|652022-08-30T06:37:01|662022-08-30T06:43:55|572022-08-30T06:58:45|652022-08-30T07:05:39|652022-08-30T07:20:28|362022-08-30T07:42:10|212022-08-30T07:49:03|652022-08-30T08:03:53|352022-08-30T08:10:47|652022-08-30T08:25:37|352022-08-30T08:32:28|252022-08-30T08:47:23|512022-08-30T08:54:09|362022-08-30T09:09:07|832022-08-30T09:09:13|12022-08-30T09:15:51|742022-08-30T09:30:49|362022-08-30T09:37:35|332022-08-30T09:52:34|862022-08-30T09:59:17|212022-08-30T10:14:16|812022-08-30T10:21:01|332022-08-30T10:36:02|812022-08-30T10:42:44|722022-08-30T10:57:45|842022-08-30T11:04:27|202022-08-30T11:19:25|172022-08-30T11:41:10|202022-08-30T11:47:50|172022-08-30T12:02:52|702022-08-30T12:09:34|182022-08-30T12:24:39|652022-08-30T12:31:19|672022-08-30T12:46:20|662022-08-30T12:53:05|182022-08-30T13:08:09|672022-08-30T13:14:50|312022-08-30T13:29:56|662022-08-30T13:36:33|66

[root@big hao]# less slow.log |grep "# Time" -A 6 |egrep -i "insert|delete|update|select|commit|show" |awk '{print $1}'|sed -e 's/;/ /g' |termsql -0 "select COL0 sql_stat,count(COL0) sql_count from tbl group by COL0"sql_stat|sql_countCOMMIT|59DELETE|11INSERT|321SELECT|18UPDATE|6commit|2627select|16show|17update|6282. 結合 mysql 的 error.log 中的 flush 信息進行排查

從 error.log 中看到有大量的 flush 信息輸出，時間點跟 slow.log 高度重合；error.log 中的 flush 信息是表示這個時間點 mysql 在進行刷盤的時候效率比較低，進一步可以排查磁盤 io 情況。

[root@big hao]# less mysql-error.log |grep "2022-08-30T" |grep flush2022-08-30T00:05:56.685140+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 5301ms to flush 121 and evict 0 pages2022-08-30T00:27:37.800463+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4028ms to flush 120 and evict 0 pages2022-08-30T00:49:22.874045+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4992ms to flush 24 and evict 0 pages2022-08-30T01:11:04.900200+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4947ms to flush 16 and evict 0 pages2022-08-30T01:32:50.117427+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 6136ms to flush 112 and evict 0 pages2022-08-30T01:54:32.106385+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4912ms to flush 18 and evict 0 pages2022-08-30T02:16:16.060394+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4870ms to flush 16 and evict 0 pages2022-08-30T02:37:58.933258+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4796ms to flush 16 and evict 0 pages2022-08-30T02:59:40.755206+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4741ms to flush 24 and evict 0 pages2022-08-30T03:43:08.053816+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4230ms to flush 105 and evict 0 pages2022-08-30T04:04:53.504756+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4381ms to flush 16 and evict 0 pages2022-08-30T06:15:16.414777+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4380ms to flush 18 and evict 0 pages2022-08-30T06:37:01.679180+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 7198ms to flush 24 and evict 0 pages2022-08-30T06:58:45.807908+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 6052ms to flush 120 and evict 0 pages2022-08-30T07:20:28.078480+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 5189ms to flush 26 and evict 0 pages2022-08-30T07:42:10.509536+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 7349ms to flush 120 and evict 0 pages2022-08-30T08:03:53.622772+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 7035ms to flush 40 and evict 0 pages2022-08-30T08:25:37.692469+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 6982ms to flush 120 and evict 0 pages2022-08-30T08:47:23.035222+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10264ms to flush 137 and evict 0 pages2022-08-30T09:09:07.647213+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 8538ms to flush 136 and evict 0 pages2022-08-30T09:30:49.287417+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 6570ms to flush 121 and evict 0 pages2022-08-30T09:52:34.201334+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 8821ms to flush 120 and evict 0 pages2022-08-30T10:14:16.708964+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 6419ms to flush 128 and evict 0 pages2022-08-30T10:36:02.241341+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 7444ms to flush 128 and evict 0 pages2022-08-30T10:57:45.240046+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 7926ms to flush 144 and evict 0 pages2022-08-30T11:19:25.457821+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4146ms to flush 11 and evict 0 pages2022-08-30T11:41:10.135784+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 5599ms to flush 9 and evict 0 pages2022-08-30T12:02:52.696129+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 6495ms to flush 10 and evict 0 pages2022-08-30T12:24:39.010150+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 8246ms to flush 10 and evict 0 pages2022-08-30T12:46:20.517719+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4433ms to flush 11 and evict 0 pages2022-08-30T13:08:09.203494+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10607ms to flush 123 and evict 0 pages2022-08-30T13:29:56.427760+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 11156ms to flush 24 and evict 0 pages2022-08-30T13:51:44.961560+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 12464ms to flush 19 and evict 0 pages2022-08-30T14:13:30.720673+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9677ms to flush 17 and evict 0 pages2022-08-30T14:35:16.044102+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 11250ms to flush 185 and evict 0 pages2022-08-30T14:57:01.166176+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10031ms to flush 113 and evict 0 pages2022-08-30T15:18:46.788154+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 11545ms to flush 104 and evict 0 pages2022-08-30T15:40:31.365101+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9504ms to flush 10 and evict 0 pages2022-08-30T16:02:18.469655+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10029ms to flush 9 and evict 0 pages2022-08-30T16:24:00.665416+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 7106ms to flush 13 and evict 0 pages2022-08-30T16:45:48.000669+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10248ms to flush 10 and evict 0 pages2022-08-30T17:07:32.486231+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10406ms to flush 24 and evict 0 pages2022-08-30T17:29:19.041210+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10477ms to flush 24 and evict 0 pages2022-08-30T17:51:06.170389+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 12039ms to flush 104 and evict 0 pages2022-08-30T18:12:52.601286+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10351ms to flush 16 and evict 0 pages2022-08-30T18:34:40.850308+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 12176ms to flush 106 and evict 0 pages2022-08-30T18:56:27.521509+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 8591ms to flush 25 and evict 0 pages2022-08-30T19:18:12.374391+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9778ms to flush 17 and evict 0 pages2022-08-30T19:39:59.425549+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10982ms to flush 17 and evict 0 pages2022-08-30T20:01:43.432897+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 8925ms to flush 16 and evict 0 pages2022-08-30T20:23:31.657359+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 12138ms to flush 18 and evict 0 pages2022-08-30T20:45:16.677588+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9932ms to flush 27 and evict 0 pages2022-08-30T21:07:03.512955+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10763ms to flush 25 and evict 0 pages2022-08-30T21:28:48.726420+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9139ms to flush 18 and evict 0 pages2022-08-30T21:50:35.496745+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10696ms to flush 16 and evict 0 pages2022-08-30T22:12:20.785958+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9216ms to flush 16 and evict 0 pages2022-08-30T22:34:05.561838+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 8703ms to flush 18 and evict 0 pages2022-08-30T22:55:50.686158+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9042ms to flush 16 and evict 0 pages2022-08-30T23:17:36.178498+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10405ms to flush 18 and evict 0 pages2022-08-30T23:39:22.707252+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 10440ms to flush 16 and evict 0 pages3. 配置磁盤監(jiān)控腳本，分析監(jiān)控數(shù)據(jù)

分析部分時間點發(fā)現(xiàn)磁盤 io 確實存在異常情況，跟 mysql-error.log 中 flush 的時間點完全重合。

//磁盤io監(jiān)控腳本#!/bin/bashwhile sleep 1;doecho "########`date '+%F %H:%M:%S'`" >> /app/monitor/diskmoni$(date "+%Y%m%d").logsar -d -p 1 10 >> /app/monitor/diskmoni$(date "+%Y%m%d").logdone4. 其他時間點的慢sql分析

在 slow.log 中還有一些時間點也出現(xiàn)了大量的慢 sql ，這個時間點主庫的磁盤 io 是正常的，例如 slow.log 中的“2022-08-30T11:04:27”，分析這個時間點的慢 sql ，首先沒發(fā)現(xiàn) select 語句，其次鎖等待時間基本可以忽略，那么此時要考慮半同步復制機制的影響。

[root@big hao]# less slow.log |grep "2022-08-30T11:04:27" -A 6 |egrep -i "2022-08-30T11:04:27|insert|delete|update|select|commit|show" |sed -e 's/# Time:/ /g'|awk '{print $1,$2}'|awk '{print $1}'|awk -F '.' '{print $1}'|termsql -0 "select COL0 ,count(COL0) count from tbl group by COL0"COL0|count2022-08-30T11:04:27|20COMMIT;|1DELETE|1INSERT|5update|13 [root@big hao]# less slow.log |grep "2022-08-30T11:04:27" -A 3 |grep "Lock_time"|awk '{print $4,$5,$8,$9}'Lock_time: 0.000105 Rows_examined: 1Lock_time: 0.000130 Rows_examined: 1Lock_time: 0.000113 Rows_examined: 1Lock_time: 0.000000 Rows_examined: 0Lock_time: 0.000105 Rows_examined: 0Lock_time: 0.000469 Rows_examined: 0Lock_time: 0.000109 Rows_examined: 1Lock_time: 0.000110 Rows_examined: 1Lock_time: 0.000114 Rows_examined: 1Lock_time: 0.000112 Rows_examined: 2Lock_time: 0.000114 Rows_examined: 2Lock_time: 0.000107 Rows_examined: 0Lock_time: 0.000107 Rows_examined: 1Lock_time: 0.000116 Rows_examined: 1Lock_time: 0.000137 Rows_examined: 1Lock_time: 0.000112 Rows_examined: 1Lock_time: 0.000097 Rows_examined: 0Lock_time: 0.000143 Rows_examined: 1Lock_time: 0.000098 Rows_examined: 3Lock_time: 0.000611 Rows_examined: 0

開啟主庫半同步復制的 strace 日志，開啟步驟如下，開啟之后會將半同步信息記錄到 mysql-error.log 中，開啟之后首先會占用大量磁盤空間，其次是占用磁盤 io ，所以生產環(huán)境最好不要長時間開啟。

//開啟半同步strace日志mysql> show variables like 'rpl_semi_sync_slave_trace_level';+---------------------------------+-------+| Variable_name | Value |+---------------------------------+-------+| rpl_semi_sync_slave_trace_level | 32 |+---------------------------------+-------+1 row in set (0.01 sec) mysql> set global rpl_semi_sync_slave_trace_level = 16;Query OK, 0 rows affected (0.00 sec) mysql> show variables like 'rpl_semi_sync_slave_trace_level';+---------------------------------+-------+| Variable_name | Value |+---------------------------------+-------+| rpl_semi_sync_slave_trace_level | 16 |+---------------------------------+-------+1 row in set (0.04 sec) //關閉半同步strace日志 mysql> set global rpl_semi_sync_slave_trace_level = 32;Query OK, 0 rows affected (0.00 sec) mysql> show variables like 'rpl_semi_sync_slave_trace_level';+---------------------------------+-------+| Variable_name | Value |+---------------------------------+-------+| rpl_semi_sync_slave_trace_level | 32 |+---------------------------------+-------+1 row in set (0.01 sec)

查看半同步日志之前先分享兩個日志標識：

ReplSemiSyncMaster::updateSyncHeader:主庫更新packet頭部標記位為Sync，緊接著就會發(fā)送binlog給從庫；

ReplSemiSyncMaster::reportReplyPacket:主庫接受到從庫返回的ack信息，附帶有l(wèi)og_file、log_pos、從庫的server_id。

這兩個標識之間的時間差可以理解為半同步復制機制對業(yè)務性能的主要影響，可以看到下面的日志中主庫發(fā)送給從庫 binlog 6s 之后才收到從庫的ack信息；首先網(wǎng)絡情況會影響半同步復制，其次從庫的 io 能力也會影響半同步復制，因為當主庫發(fā)送 binlog 給從庫之后，從庫要先將 binlog 寫入自己的 relaylog 中然后再返回給主庫 ack 。

//提取出的半同步部分日志2022-08-30T11:04:21.919587+08:00 23176 [Note] [MY-011133] [Repl] ActiveTranx:insert_tranx_node: insert (mysql-bin.003497, 9432086) in entry(4191).2022-08-30T11:04:21.920085+08:00 655 [Note] [MY-011134] [Repl] ActiveTranx::is_tranx_end_pos: probe (mysql-bin.003497, 9432086) in entry(4191).2022-08-30T11:04:21.920102+08:00 655 [Note] [MY-011158] [Repl] ReplSemiSyncMaster::updateSyncHeader: server(11111), (mysql-bin.003497, 9432086) sync(1), repl(1).2022-08-30T11:04:27.599408+08:00 0 [Note] [MY-011140] [Repl] ReplSemiSyncMaster::reportReplyPacket: Got reply(mysql-bin.003497, 9432086) from server 11111.2022-08-30T11:04:27.599423+08:00 0 [Note] [MY-011146] [Repl] ReplSemiSyncMaster::reportReplyBinlog: Got reply at (mysql-bin.003497, 9432086).

查看這段時間主庫跟從庫的網(wǎng)絡監(jiān)控發(fā)現(xiàn)網(wǎng)絡沒有太大問題。

[root@big hao]# grep -A 20 "2022-08-30 11:04:" ping20220830.log########2022-08-30 11:04:04PING *.*.*.* (*.*.*.*) 56(84) bytes of data.64 bytes from *.*.*.*: icmp_seq=1 ttl=64 time=0.050 ms64 bytes from *.*.*.*: icmp_seq=2 ttl=64 time=0.061 ms64 bytes from *.*.*.*: icmp_seq=3 ttl=64 time=0.044 ms64 bytes from *.*.*.*: icmp_seq=4 ttl=64 time=0.046 ms64 bytes from *.*.*.*: icmp_seq=5 ttl=64 time=0.057 ms64 bytes from *.*.*.*: icmp_seq=6 ttl=64 time=0.062 ms64 bytes from *.*.*.*: icmp_seq=7 ttl=64 time=0.067 ms64 bytes from *.*.*.*: icmp_seq=8 ttl=64 time=0.063 ms64 bytes from *.*.*.*: icmp_seq=9 ttl=64 time=0.057 ms64 bytes from *.*.*.*: icmp_seq=10 ttl=64 time=0.067 ms --- *.*.*.* ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9229msrtt min/avg/max/mdev = 0.044/0.057/0.067/0.010 ms########2022-08-30 11:04:14PING *.*.*.* (*.*.*.*) 56(84) bytes of data.64 bytes from *.*.*.*: icmp_seq=1 ttl=64 time=0.057 ms64 bytes from *.*.*.*: icmp_seq=2 ttl=64 time=0.051 ms64 bytes from *.*.*.*: icmp_seq=3 ttl=64 time=0.059 ms64 bytes from *.*.*.*: icmp_seq=4 ttl=64 time=0.063 ms64 bytes from *.*.*.*: icmp_seq=5 ttl=64 time=0.070 ms64 bytes from *.*.*.*: icmp_seq=6 ttl=64 time=0.062 ms64 bytes from *.*.*.*: icmp_seq=7 ttl=64 time=0.069 ms64 bytes from *.*.*.*: icmp_seq=8 ttl=64 time=0.050 ms64 bytes from *.*.*.*: icmp_seq=9 ttl=64 time=0.049 ms64 bytes from *.*.*.*: icmp_seq=10 ttl=64 time=0.065 ms --- *.*.*.* ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9230msrtt min/avg/max/mdev = 0.049/0.059/0.070/0.010 ms########2022-08-30 11:04:25PING *.*.*.* (*.*.*.*) 56(84) bytes of data.64 bytes from *.*.*.*: icmp_seq=1 ttl=64 time=0.057 ms64 bytes from *.*.*.*: icmp_seq=2 ttl=64 time=0.053 ms64 bytes from *.*.*.*: icmp_seq=3 ttl=64 time=0.045 ms64 bytes from *.*.*.*: icmp_seq=4 ttl=64 time=0.057 ms64 bytes from *.*.*.*: icmp_seq=5 ttl=64 time=0.063 ms64 bytes from *.*.*.*: icmp_seq=6 ttl=64 time=0.055 ms64 bytes from *.*.*.*: icmp_seq=7 ttl=64 time=0.061 ms64 bytes from *.*.*.*: icmp_seq=8 ttl=64 time=0.069 ms64 bytes from *.*.*.*: icmp_seq=9 ttl=64 time=0.062 ms64 bytes from *.*.*.*: icmp_seq=10 ttl=64 time=0.067 ms

查看從庫磁盤 io 監(jiān)控發(fā)現(xiàn)從庫磁盤出現(xiàn) io 異常，也就是說 slow.log 中其他時間點的慢 sql 是跟半同步復制有關系，但原因還是因為磁盤的 io 異常所導致。

總結慢日志中被大量記錄的sql是commit，其次是update和insert，這類sq相對比較吃io；如果一批sql中帶有簡單的select語句，大概率跟半同步復制關系不大；慢日志中記錄了88show master status語句，大家可以猜一猜它為什么也會慢呢？

小貼士

大多數(shù)監(jiān)控平臺對于磁盤io監(jiān)控數(shù)據(jù)采集的頻率為15s/次，此時查看監(jiān)控平臺很難看到磁盤的異常情況，所以本次通過手工部署監(jiān)控腳本來檢測磁盤io情況

以上就是關于pos機客戶反饋, 客戶說 insert 慢的知識，后面我們會繼續(xù)為大家整理關于pos機客戶反饋的知識，希望能夠幫助到大家！