PostgreSQL Replication之第五章 設定同步複製（2）

標籤：

5.2 理解實際影響和效能

在本章中，我們已經討論了實際影響以及效能影響。但是，有什麼好的理論性的例子嗎？讓我們做一個簡單的基準測試，看看複製是怎麼做的。我們做這樣的測試來為您顯示各種耐久性的層級不只是一個次要的話題，對效能來說它們是關鍵的。

讓我們假設一個簡單的測試：在下面的情境中，我們已經串連到兩個同樣強大的機器(3 GHz, 8 GB RAM) 超過1 Gbit 的網路。兩台機器彼此相鄰。為了示範同步複製的影響，我們使用 shared_buffers 和所有其他記憶體參數的預設設定，僅僅把 fsync 設定為 off來確保磁碟等待影響幾乎降低到0。

該測試很簡單：我們使用一個只有一個整型欄位的表和包括只有一個INSERT語句的10000筆事務：

INSERT INTO t_test VALUES (1);

我們可以嘗試這個完全的同步複製(synchronous_ commit = on):

real 0m6.043s

user 0m0.131s

sys 0m0.169s

正如您所看到的，測試用了大約六秒就可以完成。現在使用 synchronous_commit = local (這實際上意味著非同步複製)來重複該測試:

real 0m0.909s

user 0m0.101s

sys 0m0.142s

在這個簡單的測試中，您可以看到速度提升了六倍。當然這是一個暴力的例子，這並不能完全地反映現實情況(這不是目標)。要理解什麼是重要的，同步複製和非同步複製並不是幾個百分點的區別。這更加強調了我們的觀點：只要真正地需要同步地複製，如果您真的需要使用同步複製，確保您的同步事務數量絕對地小。

另外，請確保您的網路能夠滿足工作需求。通過帶有高延遲的網路連接同步地複製資料肯定不知不覺地會破壞您的系統效能。請記住，沒有辦法通過昂貴的硬體解決這個問題。實際上，加倍您的伺服器的時脈速度對您來說並沒有用，因為真正的限制總是來自網路延遲，只來自網路延遲。

[只有一個串連的效能損失肯定比許多串連的情況下大。請記住，可以在並行方面做工作，網路延遲並沒有使用我們更多的I/O或CPU頻寬，所以，我們可以通過啟動更多的並發工作來降低慢事務的影響。]

使用同步複製時，您怎麼能確保效能不會有太大的損失？基本上，有幾個已被證明的有協助的重要的建議：

• 使用較長的事務: 記住,，系統必須確保提交的資料在兩台伺服器上是可用的；我們並不關心事務的中間過程，因為您的事務之外的任何人都不會看到資料。較長的事務會大幅地減少網路通訊。

• 運行並行任務: 如果您有多個事務同時運行，它一定會對效能有利。原因是，遠程伺服器將返回XLOG內部的位置被認為是安全的進程(重新整理或接收)。此方法確保了多事務可能會在同一時間得到批准。

PostgreSQL Replication之第五章 設定同步複製（2）