有很多很好的教程討論 Go 的sql.DB類型以及如何使用它來執(zhí)行 SQL 數據庫查詢和語句。但它們中的大多數都掩蓋了SetMaxOpenConns()、SetMaxIdleConns()和SetConnMaxLifetime()方法——您可以使用它們來配置 的行為sql.DB并改變其性能。

在這篇文章中，我想準確解釋這些設置的作用，并展示它們可能產生的（積極和消極）影響。

打開和空閑連接
我將從一些背景開始。

對象sql.DB是許多數據庫連接的池，其中包含“使用中”和“空閑”連接。當您使用連接執(zhí)行數據庫任務（例如執(zhí)行 SQL 語句或查詢行）時，連接將被標記為正在使用。任務完成后，連接將標記為空閑。

當您指示sql.DB執(zhí)行數據庫任務時，它將首先檢查池中是否有任何空閑連接可用。如果有一個可用，那么 Go 將重用此現有連接，并將其標記為在任務期間正在使用。如果當你需要一個連接時池中沒有空閑連接，那么 Go 將創(chuàng)建一個額外的新附加連接。

SetMaxOpenConns 方法

默認情況下，同時打開的連接數（使用中+空閑）沒有限制。SetMaxOpenConns()但你可以通過這樣的方法實現你自己的限制：

// Initialise a new connection pool
db, err := sql.Open("postgres", "postgres://user:pass@localhost/db")
if err != nil {
    log.Fatal(err)
}
// Set the maximum number of concurrently open connections (in-use + idle)
// to 5. Setting this to less than or equal to 0 will mean there is no 
// maximum limit (which is also the default setting).
db.SetMaxOpenConns(5)

在此示例代碼中，池現在最大限制為 5 個并發(fā)打開的連接。如果所有 5 個連接都已標記為正在使用，并且需要另一個新連接，則應用程序將被迫等待，直到 5 個連接之一被釋放并變?yōu)榭臻e。

為了說明更改的影響，MaxOpenConns我運行了基準測試，將最大打開連接設置為 1、2、5、10 和無限制。該基準測試在 PostgreSQL 數據庫上執(zhí)行并行語句，您可以在這個要點INSERT中找到代碼。結果如下：

BenchmarkMaxOpenConns1-8                 500       3129633 ns/op         478 B/op         10 allocs/op
BenchmarkMaxOpenConns2-8                1000       2181641 ns/op         470 B/op         10 allocs/op
BenchmarkMaxOpenConns5-8                2000        859654 ns/op         493 B/op         10 allocs/op
BenchmarkMaxOpenConns10-8               2000        545394 ns/op         510 B/op         10 allocs/op
BenchmarkMaxOpenConnsUnlimited-8        2000        531030 ns/op         479 B/op          9 allocs/op
PASS

編輯：要明確的是，此基準測試的目的不是模擬應用程序的“現實生活”行為。它只是為了幫助說明sql.DB幕后的行為方式以及更改MaxOpenConns對該行為的影響。

INSERT對于此基準測試，我們可以看到允許的打開連接越多，在數據庫上執(zhí)行操作所需的時間就越少（1 個打開連接的 3129633 ns/op 與無限制連接的 531030 ns/op 相比，大約快 6 倍）。這是因為允許的打開連接越多，可以并發(fā)執(zhí)行的數據庫查詢就越多。

SetMaxIdleConns 方法

默認情況下，sql.DB連接池中最多保留2個空閑連接。您可以通過SetMaxIdleConns()如下方法更改此設置：

// Initialise a new connection pool
db, err := sql.Open("postgres", "postgres://user:pass@localhost/db")
if err != nil {
    log.Fatal(err)
}
// Set the maximum number of concurrently idle connections to 5. Setting this
// to less than or equal to 0 will mean that no idle connections are retained.
db.SetMaxIdleConns(5)

從理論上講，允許池中存在更多數量的空閑連接將提高性能，因為它使得需要從頭開始建立新連接的可能性降低，從而有助于節(jié)省資源。

讓我們看一下相同的基準測試，最大空閑連接數設置為none、1、2、5和10（并且打開的連接數不受限制）：

BenchmarkMaxIdleConnsNone-8          300       4567245 ns/op       58174 B/op        625 allocs/op
BenchmarkMaxIdleConns1-8            2000        568765 ns/op        2596 B/op         32 allocs/op
BenchmarkMaxIdleConns2-8            2000        529359 ns/op         596 B/op         11 allocs/op
BenchmarkMaxIdleConns5-8            2000        506207 ns/op         451 B/op          9 allocs/op
BenchmarkMaxIdleConns10-8           2000        501639 ns/op         450 B/op          9 allocs/op
PASS

當MaxIdleConns設置為 none 時，必須為每個連接從頭開始創(chuàng)建一個新連接，INSERT從基準測試中我們可以看到平均運行時間和內存使用量相對較高。

僅允許保留和重用 1 個空閑連接，這對這個特定的基準測試產生了巨大的影響——它使平均運行時間減少了約 8 倍，內存使用量減少了約 20 倍。繼續(xù)增加空閑連接池的大小可以使性能變得更好，盡管改進不太明顯。

那么你應該維護一個大的空閑連接池嗎？答案是這取決于應用程序。

重要的是要認識到，保持空閑連接處于活動狀態(tài)是有代價的 - 它會占用本來可用于應用程序和數據庫的內存。

如果連接空閑時間太長，它也可能變得不可用。例如，MySQL 的wait_timeout設置將自動關閉 8 小時內未使用的所有連接（默認情況下）。

當這種情況發(fā)生時，sql.DB優(yōu)雅地處理它。壞連接在放棄之前會自動重試兩次，此時 Go 將從池中刪除該連接并創(chuàng)建一個新連接。因此，設置得MaxIdleConns太高實際上可能會導致連接變得不可用，并且比擁有較小的空閑連接池（使用更頻繁的連接更少）時使用更多的資源。因此，實際上，如果您可能很快會再次使用連接，那么您實際上只想保持連接空閑。

最后要指出的一件事是MaxIdleConns應該始終小于或等于MaxOpenConns。Go 會強制執(zhí)行此操作，并在必要時自動減少MaxIdleConns。

SetConnMaxLifetime 方法

現在讓我們看一下SetConnMaxLifetime()設置連接可以重用的最大時間長度的方法。如果您的 SQL 數據庫還實現了最長連接生存期，或者例如您希望在負載均衡器后面輕松地交換數據庫，那么這會很有用。

你像這樣使用它：

// Initialise a new connection pool
db, err := sql.Open("postgres", "postgres://user:pass@localhost/db")
if err != nil {
    log.Fatal(err)
}
// Set the maximum lifetime of a connection to 1 hour. Setting it to 0
// means that there is no maximum lifetime and the connection is reused
// forever (which is the default behavior).
db.SetConnMaxLifetime(time.Hour)

在此示例中，我們的所有連接將在首次創(chuàng)建 1 小時后“過期”，并且過期后無法重復使用。但請注意：

這并不能保證連接將在池中存在整整一個小時；連接很可能由于某種原因變得不可用并在此之前自動關閉。
連接在創(chuàng)建后仍然可以使用一小時以上 - 只是在那之后無法開始重用。
這不是空閑超時。連接將在首次創(chuàng)建后 1 小時到期，而不是在最后一次空閑后 1 小時。
每秒自動運行一次清理操作，以從池中刪除“過期”連接。
從理論上講，連接越短，ConnMaxLifetime連接過期的頻率就越高，因此，需要從頭開始創(chuàng)建連接的頻率就越高。

ConnMaxLifetime為了說明這一點，我運行了設置為 100ms、200ms、500ms、1000ms 和無限制（永久重復使用）的基準測試，默認設置為無限制打開連接和 2 個空閑連接。這些時間段顯然比您在大多數應用程序中使用的時間段短得多，但它們有助于很好地說明行為。

BenchmarkConnMaxLifetime100-8               2000        637902 ns/op        2770 B/op         34 allocs/op
BenchmarkConnMaxLifetime200-8               2000        576053 ns/op        1612 B/op         21 allocs/op
BenchmarkConnMaxLifetime500-8               2000        558297 ns/op         913 B/op         14 allocs/op
BenchmarkConnMaxLifetime1000-8              2000        543601 ns/op         740 B/op         12 allocs/op
BenchmarkConnMaxLifetimeUnlimited-8         3000        532789 ns/op         412 B/op          9 allocs/op
PASS

在這些特定的基準測試中，我們可以看到，與無限生命周期相比，100 毫秒生命周期的內存使用量增加了 3 倍多，并且每個生命周期的平均運行時間也INSERT稍長。

如果您ConnMaxLifetime在代碼中進行了設置，請務必記住連接過期（并隨后重新創(chuàng)建）的頻率。例如，如果您總共有 100 個連接，連接時間ConnMaxLifetime為 1 分鐘，那么您的應用程序每秒可能會終止并重新創(chuàng)建多達 1.67 個連接（平均）。您不希望這個頻率太高，以至于最終會阻礙性能，而不是幫助它。

超出連接限制

最后，如果不提及超過數據庫連接數量的硬限制會發(fā)生什么，那么本文就不完整。

作為說明，我將更改我的postgresql.conf文件，因此總共只允許 5 個連接（默認值為 100）…

max_connections = 5

然后以無限的開放連接重新運行基準測試…

BenchmarkMaxOpenConnsUnlimited-8    --- FAIL: BenchmarkMaxOpenConnsUnlimited-8
    main_test.go:14: pq: sorry, too many clients already
    main_test.go:14: pq: sorry, too many clients already
    main_test.go:14: pq: sorry, too many clients already
FAIL

一旦達到 5 個連接的硬限制，我的數據庫驅動程序 ( pq ) 就會立即返回一條sorry, too many clients already錯誤消息，而不是完成INSERT.

為了防止出現此錯誤，我們需要將打開連接的最大總數（使用中 + 空閑）設置sql.DB為低于 5。如下所示：

// Initialise a new connection pool
db, err := sql.Open("postgres", "postgres://user:pass@localhost/db")
if err != nil {
    log.Fatal(err)
}
// Set the number of open connections (in-use + idle) to a maximum total of 3.
db.SetMaxOpenConns(3)

sql.DB現在，任何時刻最多只能創(chuàng)建 3 個連接，并且基準測試運行時應該不會出現任何錯誤。

但這樣做有一個很大的警告：當達到打開連接限制并且所有連接都在使用中時，應用程序需要執(zhí)行的任何新數據庫任務都將被迫等待，直到連接空閑并標記為空閑。例如，在 Web 應用程序的上下文中，用戶的 HTTP 請求可能會“掛起”，甚至可能在等待數據庫任務運行時超時。

為了緩解這種情況，您應該在進行數據庫調用時始終傳遞一個context.Context具有固定、快速、超時的對象，使用啟用上下文的方法，例如ExecContext(). 可以在此處的要點中看到一個示例。

總之

根據經驗，您應該明確設置一個MaxOpenConns值。這應該大大低于數據庫和基礎設施對連接數量的硬性限制。
一般來說，MaxOpenConns和MaxIdleConns值越高，性能越好。但回報是遞減的，您應該意識到，擁有太大的空閑連接池（連接未被重用并最終變壞）實際上會導致性能下降。
為了減輕上述第 2 點的風險，您可能需要設置相對較短的ConnMaxLifetime. 但您不希望這個時間太短，導致連接被頻繁地不必要地終止和重新創(chuàng)建。
MaxIdleConns應始終小于或等于MaxOpenConns。
對于中小型 Web 應用程序，我通常使用以下設置作為起點，然后根據實際吞吐量水平的負載測試結果進行優(yōu)化。

db.SetMaxOpenConns(25)
db.SetMaxIdleConns(25)
db.SetConnMaxLifetime(5*time.Minute)

到此這篇關于golang中配置 sql.DB獲得更好的性能的文章就介紹到這了,更多相關golang配置 sql.DB內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論