從尿檢取中段談資料庫壓測

想必大家都參加過一年一次的體檢，在進行尿液體檢的時候，醫生會告訴你要留中段尿！要留中段尿！要留中段尿！重要的事情說三遍。

為什麼尿液化驗要取中段尿呢？

因為前段尿和後段尿容易被污染,是以在進行尿正常和尿培養檢查時都建議留取中段尿。

我們在做資料庫壓測時，也會遇到類似的情況，比如一個持續數天的tpcc壓測，tps在時間曲線上的表現可能會是這樣的：

開始時tps緩慢的攀升，然後會經過一個較長時間的平穩期，(期間可能還有有一些短暫的抖動)，最後又會以非常平緩的曲線開始性能慢慢下降。

簡單分析

前段tps攀升的原因，

開始時tps緩慢攀升，是因為資料庫的shared buffer還沒有被填滿，所有的查詢都是從塊裝置直接讀取的，是以由于塊裝置和記憶體通路速度的差異造成了一開始的速度會較慢。

然後随着資料庫shared buffer的填充，以及os層cache的填充(如果沒有使用dio)，命中率高了之後，rt會下降，tps自然就升上去了。

中段tps平穩的原因，

資料庫的shared buffer和os cache都被熱資料填充，是以在tpcc壓測時，rt是比較均勻的。

期間tps抖動的原因，

資料庫在産生了一定數量的髒頁後，需要将做檢查點，将shared buffer的髒頁刷回磁盤，是以會增加額外的分段批量寫io的操作（檢查點的io優化操作在此文不展開，我以前有針對postgresql檢查點的優化寫過文章），特别是兩個檢查點之間的髒頁很多時，抖動會較為明顯。

後段tps下降的原因，

因為tpcc涉及到較多的更新和插入操作。

随着資料不斷的插入，表的資料量變大後，對應的索引的層次可能會變深，層次變深後，通過索引通路資料需要掃描的塊就會增加，這是影響性能的原因之一。

另一方面，随着資料的更新，垃圾tuple會增加到一定的量，同時索引可能會膨脹，深度變深。需要通路的頁數增加，也是導緻性能下降的原因之一。

并不是所有的壓測都會出現後段性能下降的情況，例如隻讀的場景，就不會出現後段的問題。

對于寫入和更新的場景，如果控制好表的大小，如使用分區，也不會出現後段的情況，因為索引頁的深度是可控的。

例如一組這樣的測試結果，每輪測試2分鐘，連續測n輪。

建議也是取中段，去掉最低值和最高值，取平均值。