この記事は、Go が高パフォーマンスの sql.DB を構成する方法を紹介する golang チュートリアル コラムによって提供されています。必要としている友人の役に立てば幸いです。 Go の
sql.DB 型と、それを使用して SQL データベース クエリを実行する方法に関するチュートリアルが多数あります。ただし、そのほとんどでは、sql の構成に使用できる
SetMaxOpenConns()、
SetMaxIdleConns()、および
SetConnMaxLifetime() メソッドについては説明されていません。 .DB
の動作とそのパフォーマンスを変更します。 この記事では、これらの設定が何を行うのかを詳しく説明し、それらの設定がもたらす可能性のある (プラスとマイナスの) 影響について説明します。
sql.DB オブジェクトはデータベース接続プールであり、「使用中」接続と「アイドル」接続が含まれます。アクティブな接続は、SQL ステートメントや行クエリの実行などのデータベース タスクを実行するために接続を使用していることを意味します。タスクが完了すると、接続は解放されます。
データベース タスクを実行するために sql.DB を作成すると、接続プール内に使用可能なアイドル接続があるかどうかが最初にチェックされます。利用可能な接続がある場合、Go は既存の接続を再利用し、タスクの実行中に使用中としてマークします。プールに空き接続がなく、接続が必要な場合、Go は新しい接続を作成します。
デフォルトでは、同時に開く接続の数は無制限です (アイドル状態を含む)。ただし、次のように
SetMaxOpenConns() メソッドを使用してカスタム制限を実装できます。<pre class="brush:php;toolbar:false">// 初始化一个新的连接池
db, err := sql.Open("postgres", "postgres://user:pass@localhost/db")
if err != nil {
log.Fatal(err)
}
// 设置当前最大开放连接数(包括空闲和正在使用的)为5。
// 如果设置为0代表连接数没有限制,默认是没有限制数量的。
db.SetMaxOpenConns(5)</pre>
このコード例では、接続プールには 5 つの同時オープン接続があります。 5 つの接続すべてがすでに使用中としてマークされており、別の新しい接続が必要な場合、アプリケーションは 5 つの接続の 1 つが解放されて空きになるまで待機することになります。
の変更による影響を説明するために、オープン接続の最大数を 1、2、5、10、および無制限に設定してベンチマークを実行しました。このベンチマークは、PostgreSQL
データベース上で並列 INSERT
ステートメントを実行します。コードはここにあります。テスト結果:
BenchmarkMaxOpenConns2-8 100 0 2181641 ns/op 470 B/op 10 allocs/opINSERT## の実行にかかる時間が増加することがわかります。 # データベース上の操作 少ない方 (開いている接続の数が 1 の場合、実行速度は 3129633ns/op ですが、無制限の接続の場合: 531030ns/op - 約 6 倍高速です)。これは、開くことを許可する接続の数が増えるほど、同時に実行できるデータベース クエリの数が増えるためです。BenchmarkMaxOpenConns5-8 2000 859654 ns/op 493 B/op 10 allocs/op
このベンチマークでは、開くことを許可される接続が増えるほど、
BenchmarkMaxOpenConns10-8 2000 5453 94 ns/op 510 B/op 10 allocs/op
BenchmarkMaxOpenConnsUnlimited-8 2000 531030 ns/op 479 B /op 9 allocs/op
PASS
SetMaxIdleConns メソッド
デフォルトでは、sql.DB では、接続プールに最大 2 つのアイドル接続を保持できます。以下に示すように、SetMaxIdleConns() メソッドを使用して変更できます。
// 初始化一个新的连接池 db, err := sql.Open("postgres", "postgres://user:pass@localhost/db") if err != nil { log.Fatal(err) } // 设置最大空闲连接数为5。 将此值设置为小于或等于0将意味着不保留空闲连接。 db.SetMaxIdleConns(5)
理論的には、プール内でより多くのアイドル接続を許可すると、新しい接続が少なくなるため、パフォーマンスが向上します。ゼロから構築できるため、データベースのパフォーマンスの向上に役立ちます。
最大アイドル接続数をなし、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/opBenchmarkMaxIdleConns2-8 2 000 529359 ns/op 596 B/op 11 allocs/opBenchmarkMaxIdleConns5-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
时,必须为每个INSERT
从头创建一个新的连接,我们可以从基准测试中看到,平均运行时和内存使用量相对较高。
只允许保留和重用一个空闲连接对基准测试影响特别明显——它将平均运行时间减少了大约8倍,内存使用量减少了大约20倍。继续增加空闲连接池的大小会使性能变得更好,尽管改进并不明显。
那么,您应该维护一个大的空闲连接池吗?答案取决于应用程序。重要的是要意识到保持空闲连接是有代价的—它占用了可以用于应用程序和数据库的内存。
还有一种可能是,如果一个连接空闲时间太长,那么它可能会变得不可用。例如,MySQL的wait_timeout
设置将自动关闭任何8小时(默认)内未使用的连接。
当发生这种情况时,sql.DB
会优雅地处理它。坏连接将自动重试两次,然后放弃,此时Go将该连接从连接池中删除,并创建一个新的连接。因此,将MaxIdleConns
设置得太大可能会导致连接变得不可用,与空闲连接池更小(使用更频繁的连接更少)相比,会占有更多的资源。所以,如果你很可能很快就会再次使用,你只需保持一个空闲的连接。
最后要指出的是,MaxIdleConns
应该总是小于或等于MaxOpenConns
.
。Go强制执行此操作,并在必要时自动减少MaxIdleConns
。
SetConnMaxLifetime方法
现在让我们看看SetConnMaxLifetime()
方法,它设置连接可重用的最大时间长度。如果您的SQL数据库也实现了最大连接生命周期,或者—例如—您希望方便地在负载均衡器后交换数据库,那么这将非常有用。
你可以这样使用它:
// 初始化一个新的连接池 db, err := sql.Open("postgres", "postgres://user:pass@localhost/db") if err != nil { log.Fatal(err) } // 将连接的最大生存期设置为1小时。将其设置为0意味着没有最大生存期,连接将永远可重用(这是默认行为) db.SetConnMaxLifetime(time.Hour)
在这个例子中,所有的连接都将在创建后1小时“过期”,并且在过期后无法重用。但注意:
从理论上讲,ConnMaxLifetime
越短,连接过期的频率就越高——因此,需要从头创建连接的频率就越高。为了说明这一点,我运行了将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
在这些特定的基准测试中,我们可以看到,与无限生存期相比,在100ms生存期时内存使用量增加了3倍以上,而且每个INSERT
的平均运行时也稍微长一些。
如果您在代码中设置了ConnMaxLifetime
,那么一定要记住连接将过期(随后重新创建)的频率。例如,如果您总共有100个连接,而ConnMaxLifetime
为1分钟,那么您的应用程序可能每秒钟杀死和重新创建1.67个连接(平均值)。您不希望这个频率太大,最终会阻碍性能,而不是提高性能。
连接数量超出
最后,如果不说明超过数据库连接数量的硬限制将会发生什么,那么本文就不完整了。 为了说明这一点,我将修改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)立即返回一个太多客户端连接的错误消息,而无法完成INSERT
。为了防止这个错误,我们需要将sql.DB中打开连接的最大总数(正在使用的+空闲的)设置为低于5。像这样:
// 初始化一个新的连接池 db, err := sql.Open("postgres", "postgres://user:pass@localhost/db") if err != nil { log.Fatal(err)} // 将打开的连接数(正在使用的连接+空闲的连接)设置为最大总数3。 db.SetMaxOpenConns (3)
现在,sql.DB在任何时候最多只能创建3个连接,基准测试运行时应该不会出现任何错误。但是这样做需要注意:当达到开放连接数限制,并且所有连接都在使用时,应用程序需要执行的任何新的数据库任务都将被迫等待,直到连接标记为空闲。例如,在web应用程序的上下文中,用户的HTTP请求看起来会“挂起”,甚至在等待数据库任务运行时可能会超时。
为了减轻这种情况,你应该始终在一个上下文中传递。在调用数据库时,启用上下文的方法(如ExecContext()
),使用固定的、快速的超时上下文对象。
总结
1、根据经验,应该显式设置MaxOpenConns
值。这应该小于数据库和基础设施对连接数量的硬性限制。
2、一般来说,更高的MaxOpenConns
和MaxIdleConns
值将带来更好的性能。但你应该注意到效果是递减的,连接池空闲连接太多(连接没有被重用,最终会变坏)实际上会导致性能下降。
3、为了降低上面第2点带来的风险,您可能需要设置一个相对较短的ConnMaxLifetime
。但你也不希望它太短,导致连接被杀死或不必要地频繁重建。
4、MaxIdleConns
应该总是小于或等于MaxOpenConns
。
对于中小型web应用程序,我通常使用以下设置作为起点,然后根据实际吞吐量水平的负载测试结果进行优化。
db.SetMaxOpenConns(25)db.SetMaxIdleConns(25)db.SetConnMaxLifetime(5*time.Minute)
到此这篇关于golang配制高性能sql.DB的使用的文章就介绍到这了
以上がGo で高パフォーマンスの sql.DB を構成する方法を詳しく説明した記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。