現在、SSIS2008とSQL2008を実行するサーバーがあります。サーバーのパフォーマンスを向上させ、SSISの実行時にサーバーのパフォーマンスを安定させたいと考えています。
サーバー上で1時間に1回実行されるSSISパッケージがあり、サーバーの速度が約3分間低下します。この3分間で、一部のサイトは、テーブルの負荷とロックのために完全に応答を停止する可能性があります。このプロセスは、在庫レベルと価格を最新の状態に保つために1時間に1回実行する必要があるため、このプロセスは不可欠です。
私の質問は、サーバーでさらにRAMをスローすると問題が解決するのでしょうか、それとも別のCPUを入れて、同じ点でSQLの別のライセンスを使用する必要があるのでしょうか?
現在、次の仕様です。QuadCore Xeon 2.8 x 1 8gb Ram Windows datacenter 2008 32bit 2 x 7,500 rpm500gbドライブ
提案された仕様QuadCore Xeon 2.9 x 1 24gb RamWindows標準200864ビット2x 15,000 rpm 300gbsasドライブ
これにより信頼性が大幅に向上すると思いますか?
編集
ボトルネックの可能性を調査した結果、SSISのインポートを開始すると、約2億b/minを読み取り、終了すると10億b/minを超えるようになります。プロセッサの使用率は約20%で、RAMは53%ですか?SSISを少し変更して、より多くの項目を並行して実行しましたが、少しは役に立ちますが、問題は解決していませんか?アイデア?
注意すべき点として、ログファイルとデータファイルは別々のディスクにあります。ログは私のEパーティションにあり、データは別のSAS SANドライブです。SAS SANはリソースを割り当てますが、データセンターにある共有SANです。2つに合わせる方がよいでしょうかSASは、共有リソースを使用するのではなく、サーバーにドライブしますか?
パフォーマンスの監視を行い、実際のボトルネックを特定して対処することは、おそらくアイデアです。 RAMとCPUはどちらもサーバーにとって等しく「重要」であり、何が問題になるかを確認するために大量のリソースをサーバーに投入するよりも、この種の問題に科学的に対処する方が適切です。
「サーバーでさらにRAMをスローするか、問題を分類するか、別のCPUを搭載する必要がありますか」と言うと、答えはこれら2つのことのいずれでもありません。答えは常に「何が原因で速度が低下しているのか、システムのパフォーマンスを測定して調べているかによって異なります」。同様に、ボトルネックとなるのはストレージである可能性があります。
ほとんどの場合、RAM。今日のサーバーではCPUに縛られることはめったにありません。そのため、仮想化は非常にうまく機能しますが、大量のRAMが必要になります。