python

linux系統資料庫伺服器的效能調優方法論

一、I/O調優

在進行 I/O調優時必須做出許多決策。是否使用原始裝置或檔案系統?是否使用直接 I/O?應該為資料庫選取多大的塊尺寸? 如果正在嚴格地執行線上事務處理(其特徵為小型的隨機讀/寫操作)工作負荷, 則應該選擇較小的塊尺寸如 2KB。 對於 DSS中長期執行的查詢操作而言,在實現了複雜的查詢最佳化器以及複雜的記憶體(分類/雜湊區域)引數控制的資料庫中, 更大的塊尺寸會提高資料庫掃描速度, 例如 8KB(如果資料庫支援, 或者可選更大尺寸)。在工作負荷同時包含 OLTP 和 DSS的情況下該如何處理?這時需要對資料庫引數的調優加以仔細考慮。 在某些情況下有必要做出折中選擇, 也許4KB的塊大小比較合適。

二、佇列長度與響應時間

在Linux系統中, vmstat是很好的 I/O頻寬測量工具。該工具的“ I/O section” 結果中bi和bo兩列原本分別表示輸入到塊裝置以及從塊裝置中輸出的塊數,如vmstat的man幫助命令所述。然而,在各種 Linux發行版本中這些列實際上以 KBps為單位報告字元裝置或塊裝置(檔案系統)在測量期間的傳輸率。對於這兩種工作負荷,如果佇列長度大於 1, 則存在著某種衝突的可能性。 對於 OLTP來說, 超過 50ms的響應時間是需要解決的問題。

三、負載平衡

Linux系統提供了多個工具來判定資料庫系統是否需要負載平衡。完成這項工作的一種簡單方法是使用 iostat。

下面給出了 iostat –x的輸出示例:

linux系統資料庫伺服器的效能調優方法論

如果未使用軟體分條(striping)能力,則應該確保資料庫中全部的表都均勻地分佈到所有磁碟上。在該基準測試的這個只讀操作部分中,磁碟 sdi實際上正在執行寫操作,因為日誌顯然儲存在該磁碟上。日誌應該位於單獨的帶卷(stripe volume)上,在可能的情況下甚至位於單獨的磁碟上,以便磁碟 sdi的速度不會受到基準測試其他方面的影響。

四、全域性記憶體

對於 OLTP工作負荷來說,通常應該利用資料庫的全域性快取將盡可能多的 I/O操作移至記憶體中。多數資料庫都提供了工具來檢視使用者事務是否被快取,包括關於髒(dirty)緩衝區和已用緩衝區的統計資料。在 Oracle 中若要適當估測記憶體,需要設定引數database_block_ buffers。這隻需確定資料庫專用的空閒記憶體量,然後將該值除以database_block_size即可,如下所示:

4GB記憶體中為資料庫分配 2.5GB,因此 database_block_buffers取值為 2684354560 /4096= 655360

下面給出一個 db_block_buffers公式的示例:

linux系統資料庫伺服器的效能調優方法論

依賴於主關鍵字索引查詢的 OLTP/WEB工作負荷受益於透過大型緩衝池來快取結果並減少I/O子系統的I/O吞吐率(每秒的I/O工作量)瓶頸。DSS工作負荷常常需要執行大型表掃描操作並返回眾多表格行結果。 針對這類工作負荷, 透過為大量sort和join操作分配記憶體,可以避免在臨時磁碟空間上發生會損害高I/O頻寬/吞吐率(MBps)的溢位現象。這透過配置 hash和 sort尺寸這些資料庫引數來完成。這些工作負荷的全域性快取容量不必很大——可以比 OLTP工作負荷所需的全域性快取小多個數量級。

下面給出一個使用 vmstat來確定空閒記憶體和已用記憶體的示例, 隨後對各個相關列加以描述。注意該例中包含vmstat在正常情況下可返回的多個數據列。

linux系統資料庫伺服器的效能調優方法論

  • free 列以千位元組為單位顯示。 如果仍存在著可用的空閒記憶體, 那麼這可能並不是制約資源。
  • swpd 列以千位元組為單位顯示,報告所用的虛存量或被換出到磁碟上的記憶體量。
  • si 列給出在報告期間從磁碟上換入的記憶體量。
  • so 列給出在報告期間換出到磁碟(虛存)上的記憶體量。

如果swpd值較大並且從 si 和 so列中可發現大量交換活動,則可能需要新增更多記憶體或減少為資料庫分配的記憶體量,從而為應用程式保留更多記憶體。要確保存在著可分配給資料庫的記憶體。另外,這還假定了Linux中已經考慮到鎖定資料庫的全域性快取區域。

也可以使用 Linux的 top命令來獲得關於佔用記憶體較多的程序的更詳細資訊。在執行 top命令時輸入 h,可以得到選項列表;輸入 m可根據常駐記憶體使用情況進行排序,從而確定哪些程序消耗的記憶體最多。 Linux的/usr/bin/top工具比 vmstat具有更大的干擾,也佔用更多 CPU時間。因此首先應使用 vmstat,在需要額外資訊時再使用 top工具。

應記住, 在 32位 Linux系統上, 記憶體容量可能會超出資料庫軟體的定址能力。 在這種情況下, 如果出現 I/O問題, 應該尋找新型的空閒記憶體使用方式。 為了減少 I/O操作,應儘量使用記憶體。在某些情況下, 可以利用資料庫的臨時空間區域, 尤其對於使用了 sort或 hash區域的具體程序(典型存在於 DSS工作負荷中)。要確保控制這些區域的資料庫引數被置為最大值(除以資料庫代理的數目),同時仍不超過系統的記憶體(包括核心)範圍。

五、 日誌裝置

當其他所有瓶頸都被解決後,對日誌記錄裝置的最佳化往往將最終決定 OLTP資料庫的效能。儘量將日誌檔案與所有其他資料庫檔案加以分離是很重要的。

下一步應決定使用原始裝置還是檔案系統裝置來執行日誌檔案。歷史上,原始裝置對於支援資料庫來說是首選的日誌記錄裝置。有些資料庫使用了直接 I/O檔案系統,其效能可以達到原始裝置的 5%。 另一些(通常為非商用的)資料庫則利用 Linux提供的緩衝機制來進行檔案系統緩衝。建議在具體設定的環境中對這些方案進行直接比較。

本文章已修改原文用詞符合繁體字使用者習慣使其容易閱讀

版權宣告:此處為CSDN博主「自由的♂」的原創文章,依據CC 4.0 BY-SA版權協議,轉載請附上原文出處連結及本宣告。

原文連結:https://blog.csdn.net/weixin_49592546/article/details/109352002