Share via

SQL Server 中記憶體內部 OLTP 的硬體考量

  • 發行項

In-Memory OLTP 會以不同於傳統磁碟資料表的方式，使用記憶體和磁碟。 您看到使用 In-Memory OLTP 提升的效能取決於您所使用的硬體。 在本文中，我們會討論數個一般硬體考量，並針對搭配 In-Memory OLTP 使用的硬體，提供常用的指導方針。

注意

本文已在 2013 年 8 月 1 日，由 Microsoft SQL Server 2014 小組發佈在部落格上。 即將淘汰的部落格網頁。

SQL Server In-Memory-OLTP

CPU

記憶體內部 OLTP 不需要高階的伺服器，就可以支援高輸送量的 OLTP 工作負載。 我們建議使用含有兩個 CPU 插槽的中型伺服器。 由於記憶體內部 OLTP 允許的輸送量不斷增加，兩個通訊端對於您的業務需求可能就已經足夠。

我們建議使用記憶體內部 OLTP 同時開啟同步多執行緒 (SMT)。 對於部分 OLTP 工作負載，使用 SMT 時，我們看到效能提升高達 40%。

記憶體

所有記憶體最佳化資料表都完全位於記憶體中。 因此，您必須擁有足夠的實體記憶體供資料表本身使用，並維持對資料庫執行的工作負載。您實際上需要的記憶體數量事實上取決於工作負載，但您需要足夠的可用記憶體供大約兩倍的資料大小，作為起點。 您也需要足夠的記憶體供緩衝集區使用，以免工作負載也在傳統磁碟資料表上運作。

若要判斷指定的記憶體最佳化資料表所使用的記憶體數量，請執行下列查詢：

select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;

結果顯示用於記憶體最佳化資料表及其索引的記憶體。 資料表資料包括使用者資料，以及執行交易仍然需要，或者系統尚未清理的所有舊版資料列。 雜湊索引所使用的記憶體為常數，而且不取決於資料表中的資料列數目。

請務必請記住，當您使用記憶體內部 OLTP 時，整個資料庫都不需要納入記憶體中。 您可以擁有好幾 TB 的資料庫，而且仍然受益於記憶體內部 OLTP，但前提是您常用資料 (亦即，記憶體最佳化資料表) 的大小不超過 256 GB。 SQL Server 可以為單一資料庫管理的檢查點資料檔案數目上限為 4,000 個檔案，而且每個檔案大小都是 128 MB。 理論上的最大值為 512 GB，但是為了保證 SQL Server 可以跟上合併檢查點檔案，而且不會達到 4,000 個檔案的限制，我們支援最多 256 GB。 此限制僅適用於記憶體最佳化資料表；傳統磁碟資料表在相同的 SQL Server 資料庫中則沒有這類大小限制。

非持久性記憶體最佳化資料表 (NDT)，也就是 DURABILITY=SCHEMA_ONLY 的記憶體最佳化資料表，並不會保存在磁碟上。 雖然 NDT 不會受到檢查點檔案數目的限制，但只會支援 256 GB。 本文其餘部分的記錄檔和資料磁碟機考量不適用於非持久性資料表，因為資料只存在於記憶體中。

記錄磁碟機

有關記憶體最佳化資料表的記錄檔記錄以及其他 SQL Server 記錄檔記錄會寫入資料庫交易記錄檔。

請務必一律將記錄檔放在具有低延遲的磁碟機上，讓交易不需要等候太久，並避免爭用記錄 IO。 您的系統將與您最慢的元件 (阿姆達爾定律) 執行得一樣快。 您需要確保在執行記憶體內部 OLTP 時，您的記錄 IO 裝置不會成為瓶頸。 建議使用具有低延遲的儲存裝置，至少是 SSD。

經記憶體最佳化的資料表使用的記錄檔頻寬比以磁碟資料表少，因為它們不會記錄索引作業，而且不會記錄 UNDO 記錄。 這有助於減輕記錄 I/O 爭用。

資料磁碟機

使用檢查點檔案的記憶體最佳化資料表持續性會使用串流 I/O。 因此，這些檔案不需要具有低延遲或快速隨機 I/O 的磁碟機。 但是，這些磁碟機的主要因素是連續 I/O 的速度以及主機匯流排介面卡 (HBA) 的頻寬。 因此，您不需要為檢查點檔案使用 SSD；您可以將這些檔案放在高效能讀寫頭上 (例如 SAS)，但前提是，其連續 I/O 速度符合您的需求。

判斷速度需求的最大要素是伺服器重新啟動時的 RTO [復原時間目標]。 在資料庫復原期間，記憶體最佳化資料表中的所有資料都必須從磁碟讀入記憶體中。 資料庫復原會以 I/O 子系統的連續讀取速度進行；磁碟是瓶頸。

若要滿足嚴苛的 RTO 需求，建議將檢查點檔案分散在多個磁碟中，方法是將多個容器加入至 MEMORY_OPTIMIZED_DATA 檔案群組。 SQL Server 支援從多個磁碟機平行載入檢查點檔案，復原會以磁碟機的彙總速度進行。

磁碟容量方面，我們建議具備 2-3 倍的可用記憶體最佳化資料表大小。

相關內容