之前公司客户有出现过一种情况,是使用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.
修改之后重新测试,发现不会出现问题.解决的很漂亮有木有.

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

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

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

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

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

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

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

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


熱AI工具

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

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

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

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

熱門文章

熱工具

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

禪工作室 13.0.1
強大的PHP整合開發環境

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

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

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