2

入力のストリームを読み込んでデータベースに書き込むプログラムがあります。ユーザー入力はありません。

このプログラムは現在、開発サーバーと本番サーバーの両方で並行して実行されており、入力と同じデータを使用して、異なる出力サーバーに書き込みます。

開発サーバーでは、すべてが正常です。一度に約30のプールされた接続が開いていて、正常に実行されます（これは高く聞こえるかもしれませんが、入力ごとにいくつかの連続した短いクエリを実行し、大量のデータがあります）。本番サーバーでは、常に100接続で最大になり、プールで使用可能な接続が不足していることを示す例外がスローされることがあります。

この不一致を引き起こしている可能性のあるSQLServer設定の種類はありますか？他の唯一の違いは、実稼働サーバーがさまざまなソースから追​​加の負荷を受けていることです。

プール内の接続数を増やすこともできますが（どれだけがそれを満たすかはわかりませんが）、これを引き起こしている原因を理解したいと思います。

4

3 に答える 3

2

答えは、 SqlDataReaders で CommandBehaviour.CloseConnection を設定する方法が間違っていたということでした (ビットごとの組み合わせを正しく使用していませんでした)。結局、私は接続を漏らしていました。

于 2009-03-04T16:13:58.103 に答える
1

通常、接続プールのしきい値に達したという例外を受け取った場合、コードは接続を適切に閉じたり破棄したりしていません。

私の理論では、本番環境でデータベースの例外が発生し、開発者ではなく、このために接続が開いたままになっています。

データベース作業は、接続とコマンドを外部で宣言し、内部で初期化するTry/Catchで常に実行する必要があります。try / catch内で接続を閉じることに依存してはならず、finallyブロックで常にclose/disposeします。

try
{
    m_Connection = this.getConnection();
    m_Command = this.getCommand();
    m_Command.CommandTimeout = m_ConnectionTimeout;
    m_Command.CommandText = sql;
    m_Command.Connection = m_Connection;
    m_Command.CommandType = CommandType.Text;

    m_Connection.Open();

    return m_Command.ExecuteNonQuery();
}
finally
{
    if (m_Connection != null && m_Connection.State != ConnectionState.Closed)
    {
        m_Connection.Close();
        m_Connection.Dispose();
    }

    if (m_Command != null)
        m_Command.Dispose();
}

1つのアプリケーションがデータベースへの100の接続を実際に消費するべきではありません。接続が正しく閉じられているかどうかを確認します。少なくとも、DBと通信している場所にログを記録して、そこで例外が発生していないかどうかを確認してください。

于 2009-02-19T15:54:27.547 に答える
0

SQL サーバーは接続プールを行わないため、接続プールは ado.net の問題です。メモリから、ado.net の接続プールの最大サイズは 100 であるため、最大値内に収まっています。アプリケーションで試すことができるいくつかのことは、接続文字列で最小プール サイズと最大プール サイズを使用して接続プーリングをハード設定することです。

詳細については、こちらとこちらをご覧ください。

于 2009-02-19T15:17:25.350 に答える