搜尋
首頁資料庫mysql教程一个有趣的现象----innodb_io_capacity_MySQL

之前公司客户有出现过一种情况,是使用sysbench 进行压力测试,在测试的过程中发生一个现象,如下所示

下面是客户那里的输出结果:

[1310s] threads: 600, tps: 2176.70, reads: 1087.10, writes: 1089.60, response time: 1076.07ms (95%), errors: 0.00, reconnects:  0.00
[1320s] threads: 600, tps: 2292.10, reads: 1144.30, writes: 1147.80, response time: 805.14ms (95%), errors: 0.00, reconnects:  0.00
[1330s] threads: 600, tps: 2205.90, reads: 1103.30, writes: 1102.60, response time: 969.33ms (95%), errors: 0.00, reconnects:  0.00
[1340s] threads: 600, tps: 2038.20, reads: 1015.80, writes: 1022.40, response time: 920.41ms (95%), errors: 0.00, reconnects:  0.00
[1350s] threads: 600, tps: 2002.90, reads: 998.90, writes: 1004.00, response time: 1096.88ms (95%), errors: 0.00, reconnects:  0.00
[1360s] threads: 600, tps: 2002.90, reads: 1000.10, writes: 1002.80, response time: 1108.77ms (95%), errors: 0.00, reconnects:  0.00
[1370s] threads: 600, tps: 2114.90, reads: 1057.60, writes: 1057.30, response time: 930.94ms (95%), errors: 0.00, reconnects:  0.00
[1380s] threads: 600, tps: 2073.30, reads: 1033.90, writes: 1039.40, response time: 967.59ms (95%), errors: 0.00, reconnects:  0.00
[1390s] threads: 600, tps: 2314.09, reads: 1153.99, writes: 1160.09, response time: 1016.58ms (95%), errors: 0.00, reconnects:  0.00
[1400s] threads: 600, tps: 1850.91, reads: 924.21, writes: 926.71, response time: 1543.45ms (95%), errors: 0.00, reconnects:  0.00
[1410s] threads: 600, tps: 2493.41, reads: 1243.81, writes: 1249.91, response time: 1124.14ms (95%), errors: 0.00, reconnects:  0.00
[1420s] threads: 600, tps: 1628.29, reads: 815.40, writes: 812.60, response time: 1302.12ms (95%), errors: 0.00, reconnects:  0.00
[1430s] threads: 600, tps: 1737.90, reads: 865.30, writes: 872.60, response time: 1128.86ms (95%), errors: 0.00, reconnects:  0.00
[1440s] threads: 600, tps: 1576.90, reads: 787.60, writes: 789.30, response time: 1375.44ms (95%), errors: 0.00, reconnects:  0.00
[1450s] threads: 600, tps: 1773.60, reads: 884.00, writes: 889.60, response time: 1374.20ms (95%), errors: 0.00, reconnects:  0.00
[1460s] threads: 600, tps: 1845.71, reads: 922.71, writes: 923.01, response time: 1252.42ms (95%), errors: 0.00, reconnects:  0.00
[1470s] threads: 600, tps: 2229.28, reads: 1111.89, writes: 1117.39, response time: 1001.47ms (95%), errors: 0.00, reconnects:  0.00
[1480s] threads: 600, tps: 2510.32, reads: 1254.31, writes: 1256.71, response time: 918.75ms (95%), errors: 0.00, reconnects:  0.00
[1490s] threads: 600, tps: 1908.09, reads: 951.79, writes: 955.59, response time: 1148.29ms (95%), errors: 0.00, reconnects:  0.00
[1500s] threads: 600, tps: 2327.93, reads: 1161.71, writes: 1166.41, response time: 1395.34ms (95%), errors: 0.00, reconnects:  0.00
[1510s] threads: 600, tps: 2329.08, reads: 1162.89, writes: 1165.99, response time: 988.08ms (95%), errors: 0.00, reconnects:  0.00
[1520s] threads: 600, tps: 2036.43, reads: 1017.81, writes: 1018.61, response time: 938.21ms (95%), errors: 0.00, reconnects:  0.00
[1530s] threads: 600, tps: 787.59, reads: 393.19, writes: 394.39, response time: 1060.72ms (95%), errors: 0.00, reconnects:  0.00
[1540s] threads: 600, tps: 0.00, reads: 0.00, writes: 0.00, response time: 0.00ms (95%), errors: 0.00, reconnects:  0.00
[2120s] threads: 600, tps: 0.00, reads: 0.00, writes: 0.00, response time: 0.00ms (95%), errors: 0.00, reconnects:  0.00
[2130s] threads: 600, tps: 0.00, reads: 0.00, writes: 0.00, response time: 0.00ms (95%), errors: 0.00, reconnects:  0.00
[2140s] threads: 600, tps: 219.00, reads: 108.30, writes: 110.70, response time: 615414.74ms (95%), errors: 0.00, reconnects:  0.00
[2150s] threads: 600, tps: 2046.80, reads: 1023.90, writes: 1022.90, response time: 1158.65ms (95%), errors: 0.00, reconnects:  0.00
[2160s] threads: 600, tps: 2560.12, reads: 1275.81, writes: 1284.31, response time: 854.55ms (95%), errors: 0.00, reconnects:  0.00
[2170s] threads: 600, tps: 3093.08, reads: 1542.49, writes: 1550.59, response time: 783.97ms (95%), errors: 0.00, reconnects:  0.00
[2180s] threads: 600, tps: 3234.00, reads: 1616.00, writes: 1618.00, response time: 698.42ms (95%), errors: 0.00, reconnects:  0.00
[2190s] threads: 600, tps: 3709.84, reads: 1851.62, writes: 1858.62, response time: 772.09ms (95%), errors: 0.00, reconnects:  0.00
[2200s] threads: 600, tps: 3492.39, reads: 1741.19, writes: 1750.79, response time: 762.67ms (95%), errors: 0.00, reconnects:  0.00
[2210s] threads: 600, tps: 3282.96, reads: 1639.88, writes: 1643.08, response time: 889.00ms (95%), errors: 0.00, reconnects:  0.00
[2220s] threads: 600, tps: 3922.43, reads: 1958.12, writes: 1964.32, response time: 690.32ms (95%), errors: 0.00, reconnects:  0.00
[2230s] threads: 600, tps: 3949.69, reads: 1972.60, writes: 1977.10, response time: 836.58ms (95%), errors: 0.00, reconnects:  0.00
[2240s] threads: 600, tps: 4091.38, reads: 2042.09, writes: 2049.29, response time: 617.39ms (95%), errors: 0.00, reconnects:  0.00

在中途会有一阵TPS为零,为什么会出现上述的情况呢,是因为脏页过多,MySQL 必须先将脏页刷到磁盘才能继续工作.

要想了解脏页与redo log 之间的关系,请看 http://blog.csdn.net/yaoqinglin/article/details/46646267

当脏页刷新的速度不及事务提交的速度,导致脏页过多时,就会触发MySQL 的保护机制,停止写入的操作,只刷盘,直到MySQL认为OK了才好.

配置文件如下

innodb_log_file_size = 1000M 
innodb_log_files_in_group = 4
innodb_max_dirty_pages_pct = 75 
innodb_io_capacity  = 200

 

问题的原因找到了,那怎么解决这个问题呢?

个人觉得应该:最为重要的是 减小 innodb_io_capacity

原理分析:

首先看下图

\

当Log Pad 占了redo log 的75%以上,MySQL会异步的将Log pad所表示的脏页刷到磁盘中,但是此时MySQL不会停止事务的提交以及写入redo log.

当Log Pad 占了redo log 的90%时,MySQL会停止全部的写入操作,将Log Pad 刷新到磁盘.

造成这种情况的原因呢,自然是刷新的速度比不上事务的提交的速度.但是我们在发生问题之间的监控表示,磁盘的I/O并没有被大量的使用,那么MySQL为甚么不

在发生问题之前使用磁盘I/O开始刷,以减轻发生问题时的压力.

原因是MySQL有一种自适应的刷盘方式,控制整个刷新进程.innodb_adaptive_flushing,innodb_io_capacity, innodb_max_dirty_pages_pct, redo log 大小来判断什么时候

开始刷新脏页.怎么判断呢,大致上MySQL 会根据innodb_io_capacity来判断更新的速度能不能在可控的范围内.如果innodb_io_capacity设置过大,则会造成MySQL高估了

磁盘的能力,导致脏页堆积,就会出现本文所说的问题.如果设置过低,则会出现MySQL低估了磁盘的能力,使得数据库能够单位时间内提交的事务数(tps)降低.

我们的服务器的磁盘是7200rpm,属于比较低级的磁盘,根据MySQL 官方的建议,应该将innodb_io_capacity降低到100.

 

[root@t1 bin]# ./sg_vpd /dev/sda --page=0xb1
Block device characteristics VPD page (SBC):
  <strong>Nominal rotation rate: 7200 rpm</strong>
  Product type: Not specified
  WABEREQ=0
  WACEREQ=0
  Nominal form factor: 3.5 inch
  HAW_ZBC=0
  FUAB=0
  VBULS=0

官方的建议:

 

 

For systems with individual 5400 RPM or 7200 RPM drives, you might lower the value to the former default of 100.

修改之后重新测试,发现不会出现问题.解决的很漂亮有木有.

 

陳述
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
MySQL字符串類型:存儲,性能和最佳實踐MySQL字符串類型:存儲,性能和最佳實踐May 10, 2025 am 12:02 AM

mySqlStringTypesimpactStorageAndPerformanCeaseAsfollows:1)長度,始終使用theSamestoragespace,whatcanbefasterbutlessspace-felfficity.2)varCharisvariable varcharisvariable length,morespace-morespace-morespace-effficitybuteftife buteftife butfority butfority textifforlyslower.3)

了解MySQL字符串類型:VARCHAR,文本,char等了解MySQL字符串類型:VARCHAR,文本,char等May 10, 2025 am 12:02 AM

mysqlStringTypesIncludeVarChar,文本,char,Enum和set.1)varCharisVersAtileForvariable-lengthStringStringSuptoPuptOuptoPepePecifiedLimit.2)textisidealforlargetStortStorStoverStoverStorageWithoutAutAdefinedLength.3)charlisfixed-lenftenge,for forConsistentDatalikeCodes.4)

MySQL中的字符串數據類型是什麼?MySQL中的字符串數據類型是什麼?May 10, 2025 am 12:01 AM

MySQLoffersvariousstringdatatypes:1)CHARforfixed-lengthstrings,2)VARCHARforvariable-lengthtext,3)BINARYandVARBINARYforbinarydata,4)BLOBandTEXTforlargedata,and5)ENUMandSETforcontrolledinput.Eachtypehasspecificusesandperformancecharacteristics,sochoose

如何向新的MySQL用戶授予權限如何向新的MySQL用戶授予權限May 09, 2025 am 12:16 AM

TograntpermissionstonewMySQLusers,followthesesteps:1)AccessMySQLasauserwithsufficientprivileges,2)CreateanewuserwiththeCREATEUSERcommand,3)UsetheGRANTcommandtospecifypermissionslikeSELECT,INSERT,UPDATE,orALLPRIVILEGESonspecificdatabasesortables,and4)

如何在MySQL中添加用戶:逐步指南如何在MySQL中添加用戶:逐步指南May 09, 2025 am 12:14 AM

toadduserInmysqleffect和securly,跟隨台詞:1)USEtheCreateUserStattoDaneWuser,指定thehostandastrongpassword.2)GrantNecterAryAryaryPrivilegesSustherthing privilegesgeStatement,usifementStatement,adheringtotheprinciplelastprefilegege.3)

mysql:添加具有復雜權限的新用戶mysql:添加具有復雜權限的新用戶May 09, 2025 am 12:09 AM

toaddanewuserwithcomplexpermissionsinmysql,loldtheSesteps:1)創建eTheEserWithCreateuser'newuser'newuser'@''localhost'Indedify'pa ssword';。 2)GrantreadAccesstoalltablesin'mydatabase'withGrantSelectOnMyDatabase.to'newuser'@'localhost';。 3)GrantWriteAccessto'

mysql:字符串數據類型和coltrationsmysql:字符串數據類型和coltrationsMay 09, 2025 am 12:08 AM

MySQL中的字符串數據類型包括CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT,排序規則(Collations)決定了字符串的比較和排序方式。 1.CHAR適合固定長度字符串,VARCHAR適合可變長度字符串。 2.BINARY和VARBINARY用於二進制數據,BLOB和TEXT用於大對像數據。 3.排序規則如utf8mb4_unicode_ci忽略大小寫,適合用戶名;utf8mb4_bin區分大小寫,適合需要精確比較的字段。

MySQL:我應該在Varchars上使用什麼長度?MySQL:我應該在Varchars上使用什麼長度?May 09, 2025 am 12:06 AM

最佳的MySQLVARCHAR列長度選擇應基於數據分析、考慮未來增長、評估性能影響及字符集需求。 1)分析數據以確定典型長度;2)預留未來擴展空間;3)注意大長度對性能的影響;4)考慮字符集對存儲的影響。通過這些步驟,可以優化數據庫的效率和擴展性。

See all articles

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

mPDF

mPDF

mPDF是一個PHP庫,可以從UTF-8編碼的HTML產生PDF檔案。原作者Ian Back編寫mPDF以從他的網站上「即時」輸出PDF文件,並處理不同的語言。與原始腳本如HTML2FPDF相比,它的速度較慢,並且在使用Unicode字體時產生的檔案較大,但支援CSS樣式等,並進行了大量增強。支援幾乎所有語言,包括RTL(阿拉伯語和希伯來語)和CJK(中日韓)。支援嵌套的區塊級元素(如P、DIV),

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

SecLists

SecLists

SecLists是最終安全測試人員的伙伴。它是一個包含各種類型清單的集合,這些清單在安全評估過程中經常使用,而且都在一個地方。 SecLists透過方便地提供安全測試人員可能需要的所有列表,幫助提高安全測試的效率和生產力。清單類型包括使用者名稱、密碼、URL、模糊測試有效載荷、敏感資料模式、Web shell等等。測試人員只需將此儲存庫拉到新的測試機上,他就可以存取所需的每種類型的清單。

MantisBT

MantisBT

Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

DVWA

DVWA

Damn Vulnerable Web App (DVWA) 是一個PHP/MySQL的Web應用程序,非常容易受到攻擊。它的主要目標是成為安全專業人員在合法環境中測試自己的技能和工具的輔助工具,幫助Web開發人員更好地理解保護網路應用程式的過程,並幫助教師/學生在課堂環境中教授/學習Web應用程式安全性。 DVWA的目標是透過簡單直接的介面練習一些最常見的Web漏洞,難度各不相同。請注意,該軟體中