網路是資料庫基礎架構的主要部分。但是，通常效能基準測試是在本地計算機上完成的，客戶端和伺服器並置在一起。這樣做是為了簡化結構並排除乙個以上的變數(網路部分)，但是我們也忽略了網路對效能的影響。對於像 mysql group replication 這樣的產品集群來說，網路更為重要。在這篇文章中，我將介紹網路設定。這些都是簡單而微不足道的，但卻是讓我們更了解複雜網路設定效果的基石。
安裝我將使用兩台裸機伺服器，通過專用的 10gb 網路連線。我將通過使用 ethtool-s eth1 speed1000duplex full autoneg off 命令更改網路介面速度來模擬 1gb 網路。
我將執行乙個簡單的基準：sysbench oltp_read_only --mysql-ssl=on --mysql-host=172.16.0.1 --tables=20 --table-size=10000000 --mysql-user=sbtest --mysql-password=sbtest --threads=$i --time=300 --report-interval=1 --rand-type=pareto
執行時執行緒數從 1 到 2048 不等。所有資料都適合記憶體 -innodb_buffer_pool_size 足夠大。因此工作負載在記憶體中占用大量 cpu：沒有 io 開銷。作業系統：ubuntu 16.04
n1 基準-網路頻寬在第乙個實驗中，我將比較 1gb 網路和 10gb 網路。顯然，1gb 網路效能是這裡的瓶頸，如果我們遷移到 10gb 網路，我們可以顯著改善我們的結果。要檢視 1gb 網路是瓶頸，我們可以檢查 pmm(percona 的資料庫監控管理開源工具) 中的網路流量圖表：
我們可以看到我們的吞吐量達到了 116 mib/s(或 928 mb/s)，這非常接近網路頻寬。但是，如果我們的網路基礎設施僅限於 1gb，我們可以做些什麼？
n2 基準-協議壓縮mysql 協議中有乙個功能，您可以看到客戶端和伺服器之間的網路交換壓縮：--mysql-compression=on。讓我們看看它將如何影響我們的結果。
這是乙個有趣的結果。當我們使用所有可用的網路頻寬時，協議壓縮實際上有助於改善結果。
但是 10gb 網路不是這種情況。壓縮/解壓縮所需的 cpu 資源是乙個限制因素，通過壓縮，吞吐量實際上只達到我們沒有壓縮的一半。現在讓我們談談協議加密，以及如何使用 ssl 影響我們的結果。
n3基準-網路加密
對於 1gb 網路，ssl 加密顯示了一些損失 - 單執行緒約為 10％ - 但是否則我們再次達到頻寬限制。我們還看到了大量執行緒的可擴充套件性，這在 10gb 網路案例中更為明顯。使用 10gb 時，ssl 協議在 32 個執行緒後不會擴充套件。實際上，它似乎是 mysql 目前使用的 openssl 1.0 中的可伸縮性問題。在我們的實驗中，我們看到 openssl 1.1.1 提供了更好的可伸縮性，但是您需要從鏈結到 openssl 1.1.1 的源**中獲得特殊的 mysql 構建才能實現這一點。我沒有在這裡展示它們，因為我們沒有生產二進位制檔案。
結論1. 網路效能和利用率將影響一般應用程式吞吐量。2. 檢查您是否達到了網路頻寬限制。3. 如果受到網路頻寬的限制，協議壓縮可以改善結果，但如果不是，則可能會使事情變得更糟。
設定MySQL使用大記憶體頁面
一般情況下使用的記憶體為每頁4k，使用 huge page 的話預設是每頁 2m。如果設定mysql使用 huge page 至少有兩個好處，乙個是可以減少 translation lookaside buffer tlb 失誤以提高效能，另乙個是利用 huge page不會swap的特性保證mys...
記憶體頻寬計算
記憶體頻寬計算公式 頻寬 記憶體核心頻率 記憶體匯流排位數 倍增係數。先容我從ddr的技術說起，ddr採用時鐘脈衝上公升 下降沿各傳一次資料，1個時鐘訊號可以傳輸2倍於sdram的資料，所以又稱為雙倍速率sdram。它的倍增係數就是2。ddr2仍然採用時鐘脈衝上公升 下降支各傳一次資料的技術 不是傳...
測試伺服器最大記憶體頻寬的實驗
intel nehalem架構處理器內建了記憶體控制器，處理器之間通過qpi互聯，是典型的numa系統。numa系統的特點是每乙個節點都有自己的記憶體控制器，儘管每個節點都能訪問所有節點上的記憶體，但是代價不一樣，訪問本地記憶體的速度比訪問遠端節點的速度要快。使用intel nehalem架構的處理...