本文主要介紹postgresql 在中高端x86伺服器上的資料插入速度(目标表包含一個時間字段的索引),幫助企業使用者了解postgresql在這類場景下的性能表現。
平均每條記錄長度360位元組(比較常見的長度);
時間字段建立索引;
每輪測試插入12tb資料,插入完12t後清除資料繼續插入。循環;
測試滿24小時停止測試;
統計24小時插入的記錄數;
24小時一共完成12輪測試,平均每輪測試耗時7071秒。
506萬行/s,1.78 gb/s,全天插入4372億,154tb資料。
<a href="https://github.com/digoal/pgsql_admin_script/blob/master/pgsql_perf_tuning.md" target="_blank">pgsql_perf_tuning</a>
<a href="https://yq.aliyun.com/articles/8482" target="_blank">postgresql支援hugepage的方法</a>
參數
建立測試表 :
每32k的block存儲89條記錄, 每條記錄360位元組。
分别在3個實體塊裝置上建立3個表空間目錄,同時在資料庫中建立表空間。
tbs1, tbs2, tbs3.
建立多個分表,用于減少 block extend 沖突。
這裡使用的是brin範圍索引,postgresql 針對物聯網流式資料的黑科技。
生成測試腳本, 一個連接配接一次插入178條記錄,占用2個32kb的block :
開始測試前清除資料:
測試方法:
每輪測試插入12tb資料。通過以下方式控制:
使用128個并行連接配接,每個連接配接執行1572864個事務;
一共執行201326592個事務(每個事務插入178條記錄);
一共插入35836133376條記錄(358.36 億記錄)(共計12tb 資料,索引空間另算)。
進行下一輪測試前,輸出日志,并truncate所有的資料,然後重複以上測試。直到測試滿24小時,輸出統計資料。
測試腳本如下 :
測試
這個case主要的應用場景是實時的大資料入庫,例如物聯網的應用場景,大量的傳感器會産生龐大的資料。
又比如傳統的營運商網關,也會有非常龐大的流量資料或業務資料需要實時的入庫。索引方面,用到了postgresql黑科技brin。
瓶頸, 還是在io上面 , 有幾個表現,top大量程序處于d(front io)狀态 。
所有塊裝置的使用率均達100% 。
清理資料時 :
插入資料時:
io層面的性能問題,可以通過優化代碼(例如 postgresql bgwriter 在寫出資料時,盡量順序寫出),便于os層進行io合并,來緩解io壓力,從這個資訊來看,單次寫io的大小還可以再大點。
有幾個工具你可能用得上,perf、systemtap和goprof。如果要較全面的分析,建議把 postgresql –enable-profiling 打開用于診斷。