帶有 HammerDB-Test 的 SQL 2016 低 TPM
我們在新安裝的 MSSQL 2016 伺服器上遇到了一些問題。伺服器是使用 VMware 最佳實踐的虛擬 VMware 機器。我們使用 HammerDB-Tool 以 TPC-C 標準測試 TPM。不幸的是，我們只能達到大約 130.000 TPM。對於新軟體，我們必須達到至少 200.000 TPM。
通過單獨測試我們看到的驅動器，SQL-Server 沒有為數據庫驅動器使用完整的吞吐量（我們得到了 1.2 GB/s 的 IOMeter 的吞吐量）。
*IOMeter 的參數為：12 工人，40000000 Sektors，未完成 I/O 數量 16
以下是一些新鮮的價值觀：
64 千字節；0% 閱讀；0% 隨機
IOPS: 14023 Total MBs per Second: 914.56 MBPS Average I/O Response Time (ms): 13.75 Maximum I/O Response Time (ms): 161.4064 千字節；50% 閱讀；0% 隨機
IOPS: 14412 Total MBs per Second: 944 MBPS Average I/O Response Time (ms): 13.30 Maximum I/O Response Time (ms): 413.5964 千字節；100% 閱讀；0% 隨機
IOPS: 14280 Total MBs per Second: 936.15 MBPS Average I/O Response Time (ms): 13.44 Maximum I/O Response Time (ms): 173.95用於數據庫的磁碟格式化為 64kb 塊大小。
甚至伺服器上的 CPU 和記憶體也不會 100% 使用（雖然測試 NUMA-Node1 僅消耗 20% 的資源，NUMA-Node2 低於 5%）。在執行 HammerDB 測試時，整個系統使用大約 5GB RAM。作業系統和 SQL-Service 由 Microsoft 和 HammerD-Tool 的建議配置。
所以這裡是虛擬機的一些其他規格： 5 個 HD 驅動器（OS、DB、TempDB、Log、TempLog；每個驅動器通過單獨的準虛擬 SCSI 控制器連接到 VM） 2 個插槽，每個插槽有 6 個 CPU，每個 128 GB RAM（ 110 為 MSSQL 保留）Windows Server 2012 R2 標準作業系統。如果我們使用 10 個虛擬使用者執行 HammerDB-Test，我們會得到 CPU 使用率，如圖所示：
我們的虛擬環境和我們的 SAN 通過 8 Gb/s 光纖通道連接進行連接，每個主機都有 2 個到 SAN 的連接。每個主機有 32 個物理 CPU，頻率為 2.6 GHz。在我們的 SAN 上，我們配置了一個 SSD Raid10 LUN 來儲存伺服器和數據。為了測試，我們在主機上沒有其他機器，所以沒有過度送出。從 BIOS 級別到 Windows 級別，每個配置參數都設置為高性能。
關於 SQL 配置：MAXDOP 設置為 0。未啟用“針對 Ad-Hoc 工作負載進行優化”。‘Lock pages in memory’ 設置為我們的 SQL-Service-Account。我們沒有向伺服器添加資源調控器策略。
我們現在已經使用 CPU、每個 SOCKET 的 CPU、RAM 和 MAXDOP 測試了一些不同的配置。在下表中，您可以看到每個測試配置的 TPM 結果：
| RAM | CPU/SOCKET | SOCKETS | MAXDOP | TMP MIN. | TMP MAX. | TMP AVG. | |------|------------|---------|--------|-----------|----------|----------| | 128 | 8 | 1 | 0 | 88,000 | 100,000 | 93,000 | | 128 | 8 | 1 | 1 | 85,000 | 92,000 | 88,500 | | 128 | 8 | 1 | 2 | 85,000 | 94,000 | 91,000 | | 128 | 8 | 1 | 4 | 92,000 | 103,000 | 98,000 | | 128 | 8 | 1 | 6 | 92,000 | 104,000 | 98,700 | | 128 | 8 | 1 | 8 | 92,000 | 101,000 | 97,600 | |------|------------|---------|--------|-----------|----------|----------| | 128 | 12 | 1 | 0 | 115,000 | 129,000 | 125,400 | | 128 | 12 | 1 | 1 | 127,000 | 142,000 | 134,300 | | 128 | 12 | 1 | 2 | 112,000 | 128,000 | 120,900 | | 128 | 12 | 1 | 4 | 114,000 | 128,000 | 120,800 | | 128 | 12 | 1 | 6 | 125,000 | 132,000 | 128,800 | | 128 | 12 | 1 | 8 | 125,000 | 138,000 | 131,300 | | 128 | 12 | 1 | 10 | 130,000 | 141,000 | 136,200 | | 128 | 12 | 1 | 12 | 123,000 | 133,000 | 128,100 | |------|------------|---------|--------|-----------|----------|----------| | 128 | 4 | 2 | 0 | 83,000 | 96,000 | 92,600 | | 128 | 4 | 2 | 1 | 82,000 | 90,000 | 85,600 | | 128 | 4 | 2 | 2 | 85,000 | 95,000 | 88,900 | | 128 | 4 | 2 | 4 | 94,000 | 100,000 | 97,800 | | 128 | 4 | 2 | 6 | 87,000 | 100,000 | 95,500 | | 128 | 4 | 2 | 8 | 94,000 | 102,000 | 97,400 | |------|------------|---------|--------|-----------|----------|----------| | 128 | 6 | 2 | 0 | 115,000 | 129,000 | 119,500 | | 128 | 6 | 2 | 1 | 117,000 | 142,000 | 129,300 | | 128 | 6 | 2 | 2 | 120,000 | 128,000 | 125,200 | | 128 | 6 | 2 | 4 | 125,000 | 134,000 | 128,800 | | 128 | 6 | 2 | 6 | 123,000 | 131,000 | 129,100 | | 128 | 6 | 2 | 8 | 125,000 | 138,000 | 132,800 | | 128 | 6 | 2 | 10 | 125,000 | 136,000 | 131,900 | | 128 | 6 | 2 | 12 | 129,000 | 141,000 | 134,700 | |------|------------|---------|--------|-----------|----------|----------| | 128 | 16 | 1 | 0 | 111,000 | 128,000 | 119,300 | | 128 | 16 | 1 | 12 | 129,000 | 138,000 | 134,900 | | 128 | 16 | 1 | 16 | 122,000 | 133,000 | 127,900 | |------|------------|---------|--------|-----------|----------|----------| | 64 | 12 | 1 | 0 | 116,000 | 128,000 | 121,800 | | 64 | 12 | 1 | 1 | 132,000 | 145,000 | 138,300 | | 64 | 12 | 1 | 2 | 123,000 | 134,000 | 128,200 | | 64 | 12 | 1 | 4 | 118,000 | 133,000 | 125,800 | | 64 | 12 | 1 | 6 | 123,000 | 134,000 | 129,400 | | 64 | 12 | 1 | 8 | 128,000 | 138,000 | 133,300 | | 64 | 12 | 1 | 10 | 114,000 | 133,000 | 124,400 | | 64 | 12 | 1 | 12 | 127,000 | 134,000 | 131,400 | |------|------------|---------|--------|-----------|----------|----------|我現在用 sp_BlitzFirst 測試了伺服器。但我知道的太少，無法正確解釋它們。到目前為止，我知道 CXPACKETS 意味著 CPU 處於空閒狀態。對於所有其他值，我需要你的幫助:(
查看活動監視器，我看到鎖定對等待狀態的影響最大。但目前，在我看來，減少鎖定有兩種可能性：a) 加快整體伺服器性能，因此當需要再次讀取時，頁面不會被鎖定。b) 更改軟體。沒有真正的選擇。以下是 HammerDB-Test 期間 Activity-Monitor 的結果：
在這一點上，我們不知道伺服器有什麼問題。我們已經看到其他資源/功率較低的基礎架構可以提供 200.000 TPM，唯一的區別是它們使用 Hyper-V 進行虛擬化。
希望有人可以幫助我們。
親切的問候
你寫了很多東西，但這是你的主要問題：
為什麼我的 TPC 基準測試數據不是我所期望的？
要找到答案，請在工作負載執行時檢查 SQL Server 的等待統計資訊。它們儲存在 sys.dm_os_wait_stats 中，但僅作為累積數字，因此我編寫了sp_BlitzFirst以便在繁重的工作負載期間為您進行微分。像這樣執行它：
sp_BlitzFirst @ExpertMode = 1, @Seconds = 30您將在測試期間擷取伺服器等待的 30 秒樣本。查看等待統計部分以確定您的伺服器正在等待什麼 - 並隨時發布該部分結果的圖片以獲得更多幫助。
瓶頸可能不是儲存或 CPU。等待統計數據是找到它的關鍵。
HammerDB 站點的文件部分中有很多資訊可以幫助您，尤其是 SQL Server OLTP 最佳實踐指南。您需要進行許多基本檢查來確定瓶頸。1. 請記住，報告的 TPM 是一個平均值，因此當您在測試期間執行 HammerDB 事務監視器時，它會加速並達到一條直線和穩定的線，還是有“峰和谷” - 如果是後者，那麼這是瓶頸的第一個跡象，您的工作量正在停止和啟動。2. 在測試執行 SQL Server Management Studio - 右鍵點擊頂行並選擇 Activity Monitor - 在此向下滾動到 Resource Waits - 什麼是頂級等待類別和等待時間？3. 執行最佳實踐指南中引用的 FusionIO 提供的腳本，深入了解這些等待事件以詳細了解系統等待的位置。現在採取措施解決該瓶頸 - 例如，如果“日誌記錄”是最重要的事件，請按照指南優化日誌，然後考慮將其移動到可以支持更快寫入吞吐量的設備。繼續測試、辨識和解決過程 - 當您的 CPU 接近完全利用時，這將是最高性能。