MySQLの不合理なMaxIdleConnsにより接続が短くなる

1 背景

最近、Shimo Document のオンラインビジネスでパフォーマンスの問題が発生しました。突然のトラフィック状況により、1 つのビジネスのパフォーマンスが急激に低下しました。このサービスはデータベースに依存しており、データベースからデータをバッチで取得します。一連のトラブルシューティングを行った結果、サービスからデータベースへの接続数が MaxIdleConns を頻繁に超過していることがわかりました。パフォーマンスの問題はデータベースの構成に起因しているのではないかと疑い、データベースコードを分析し、関連する実験を実施しました。

2 構成の解釈

maxIdleCount int // ゼロは defaultMaxIdleConns を意味します。負数は 0 を意味します
maxOpen int // <= 0 は無制限を意味します
maxLifetime time.Duration // 接続を再利用できる最大時間
maxIdleTime time.Duration // 接続が閉じられるまでアイドル状態が維持される最大時間

上記の 4 つの構成が Go MySQL クライアントの最も重要な構成であることがわかります。

maxIdleCount アイドル接続の最大数。デフォルトでは設定されておらず、最大アイドル接続数は 2 です。

maxOpen 最大接続数。デフォルトでは設定されていないため、最大接続数は制限されません。

maxLifetime 最大接続存続期間

maxIdleTime アイドル接続の最大存続期間

3 ソースコード分析

私たちのシナリオでは、クライアントによって MySQL に確立される接続の数が、アイドル接続の最大数よりも大きくなることがよくあります。これによりどのような問題が発生しますか?下の図のソースコードを見てみましょう。

アイドル接続の最大数がクライアントとデータベース間で確立された接続数より少ない場合、false が返され、接続クローズカウンターの最大数が 1 増加することがわかります。

上の図では、接続が閉じられていることがわかります (MySQL ソースコードは、閉じる前にバッファ時間を残しません)。 Go MySQL クライアントのこの操作により、トラフィックのバーストが発生したときに、リクエスト量が大きくなりすぎて、アイドル接続の最大数の負荷を超えてしまいます。この場合、新しい接続が接続プールに入れられると、容赦なく閉じられ、短い接続になり、サービスのパフォーマンスがさらに低下します。

4つの実験

4.1 オンライン同時通話数がMaxIdConnsを超える状況をシミュレートする

テストコード、上記のロジックをテストするために、次のシナリオを想定します。最大接続数は 100 に設定され、アイドル接続の最大数は 1 に設定され、データベースを要求する同時 goroutine の数は 10 です。 MySQL 統計の maxIdleClosed の統計を見ると、次の図に示すように、接続が絶えず閉じられていることがわかります。