0

次のように C# コードから SSIS パッケージを実行しています。

ErrorHandler errorHandler = new ErrorHandler();
Application app = new Application();
DTSExecResult res;
Package pkg = app.LoadPackage(packagePath, null);
res = pkg.Execute(null, null, errorHandler, null, null);

2 つの質問があります。

  1. このパッケージを実行する「エンジン」は何ですか? SQL Server がそれを実行しますか、それともより小さな SSIS エンジンだけが必要です。

  2. この c# コード (コンソール アプリケーション) を長時間実行すると、徐々にメモリを消費します。実行中のパッケージのメモリ使用量を制限するにはどうすればよいですか?

*この動作は SQL Server の動作に似ている、つまりメモリを占有し、もちろん定義されたメモリ制限内で決して解放しないという考えが頭に浮かびました。したがって、パッケージを実行する「エンジン」は、徐々にいっぱいになる特定のメモリ制限で設定されている可能性があります。

4

1 に答える 1

2

これは妥当な推定ですが、正確ではありません。

  1. パッケージを実行する「エンジン」は、C# アプリケーションで参照したライブラリです。これは、エージェント SSIS ジョブ ステップを使用するときに (SQL 2008R2 以下で) SSIS パッケージを実行するユーティリティである DTExec にあるのと同じコードです。(SSIS2012 は、実行可能ファイルではなく、サービス内の同じコードでそれらを実行します。) SQL Server データベース サービスをインストールする必要はありません。コードを実行しているマシンには、完全な SQL Server ライセンスが必要です。必要な SQL インストールの部分は、SSIS の「共有」コンポーネントだけです。
  2. 私自身も同様の問題を経験しており、まだ本当の答えにたどり着いていないため、これについては良い答えがありません。タスク マネージャーを見ると、プライベート ワーキング セット (プロセスが実際に使用しているメモリの量) が常に妥当な値に保たれていることがわかります。無理に大きくなるのが「コミットサイズ」です。コミット サイズには、プロセスが実際には使用していないが、Windows が割り当てたメモリが含まれます。私の場合、かなり長い間パッケージを実行した後 (多くのファイルを処理するためのループがあります)、プライベート ワーキング セットが 2GB で安定するのを見ることができますが、コミット サイズが大きくなり、パッケージが失敗するまで 4GB を超えて大きくなることがわかります。メモリを取得できないためです。私のプロセス用に十分なメモリが予約されているという私の理解を考えると、それがなぜなのかわかりません。実際に慣れていません。プロセスがメモリを内部的に断片化したと（根拠なしで）推測することしかできません。メモリブロックの周りに散在する空きスペースが小さすぎて1つの要求を満たすことができないように、その4GBの中で2GBを「広げて」使用する必要があります。そのメモリを「最適化」するためのSSIS API呼び出しについては知りません:)

私が提案できるのは、パッケージを作成してそれ自体を制限することです。私の場合、ループを使用して「最大 20 ループ」を実装できます。この場合、処理するファイルがまだある場合でも、パッケージは 20 ループ後に単純に終了します。戻り値またはデータベース テーブルは、さらに処理が残っていることを示している可能性があります。C# アプリ内で、pkg.Execute への呼び出しをループすることができ、GC の試行が含まれている可能性があります。取得したメモリを解放したり、連続して再割り当てしたりするプロセスをトリガーするのにそれで十分かどうかはわかりませんが、それが私が試したいことです。

于 2012-09-08T16:33:27.287 に答える