サーバーに実際に必要なRAMはどれくらいですか？

世界中にかなりの数のサーバーが展開されています。6 GBのRAMを搭載したSQL Server 2005 x64を搭載したWindows 2003 x64を実行しています。数年前にそれらを注文した男は、彼が何をしていたかを本当に知らなかったので、箱は最高の（または許容できる）構成を持っていません。

ボックスはかなり一貫してメモリ不足になり、ページングファイルを使用してしまい、すべてが遅くなります。通常、コミット料は5.8GBであり、誰かが集中的な作業（レポートの実行など）を行う必要がある場合、その数は屋根を通り過ぎます。

私はより多くのメモリを注文する力を得ようとしましたが、私は大きな反対を得ています（たとえば、ソフトウェアのパフォーマンスを向上させる、これらすべてのサーバーのコストが高すぎる、またはボックスに十分なメモリがないことを証明するなど） ..）。

最終的により多くのメモリを注文できるように、技術者以外に提示できるボックスに必要なRAMの量に関するガイドライン（または公式）はありますか？

使い方やアプリケーションに完全に依存しているため、簡単に判断する方法はありません。データベースサーバーを最大限に使用しています...データベースの大きさは？あなたの取引統計は何ですか？

実際の制限は、シナリオでは明らかです。問題なく6ギグでしばらく実行していると、スワッピングとスラッシングが発生するため、6ギグでは不十分です。

パフォーマンスがビジネスに影響を与えるほど十分であれば、上層部は十分な苦情を聞いて、メモリを増やすのが賢明であるべきです。時間のコストを把握し、サーバーに追加されたメモリがメモリのコストと30分未満のコストの問題を非常にうまく解決できる場合、サーバーの「チューニング」とチューニングのトラブルシューティングにかかる​​コストを把握します。ダウンタイム。

実際に使用して実際に展開し、そこから作業するまで、必要なメモリの正確な量はわかりません。

そうは言っても、アプリケーションが本当にボトルネックであることを確認したい場合があります。Windowsパフォーマンスモニターを実行して、ディスクI / O統計とネットワークスループットを確認します。断片化レベルも確認してください（Googleはここで良い友達です）。クエリが非常に非効率的である場合は、明らかな問題についてもコードを監査してみてください（Googleが再び）。

しかし、これもまた、これがビジネスにどれほど深刻な影響を与えているかにかかっています。チューニングに投資する価値はありますか、それとも最初にハードウェアを投げてからチューニングしてみるのは十分ですか？

RAMがさらに必要かどうかを確認する簡単な方法は、Page Life Expectancy perfmonカウンターをグラフ化することです。このカウンターは、SQL Serverが他のデータ用のスペースを確保する前にデータがバッファープールに保持されると考える時間を示します。この数値はできるだけ大きくしたいです。6ギガバイトのRAMがインストールされていると（おそらく4ギグでSQLを最大に設定する必要があります）、おそらく誰かが大きなレポートを実行すると、この番号タンクが表示されます。数秒まで。RAMが多いほど、メモリに保持できるデータが長くなり、ディスクからの読み取りが少なくて済みます。

たとえば、現在使用しているシステムには256ギガバイトのRAMがあり、約12000秒ほどメモリにデータを保持します。

ヒットするターゲット番号を要求しないでください。できるだけ高い番号にしたいだけです。あなたのシステムについてより多くのことを知らない限り、私は良い数字を与えることはできません。

うーん。まあ、大規模なMSSQLインストールでも、6ギグはかなりの量のRAMです。あなたは実際にあなたのコードが本当に効率的であることを見て、確かめたいと思うかもしれません。6ギグトランザクションは少し珍しいです...私は今年の末1099処理のギグのトップませんでした...そして、もう一つが実行されているために州全体の給与システムで働いてきたことが多いですか？知りません。どのようなデータを使用していますか？

そうは言っても、64ビットのボックスには好きなだけRAMを詰めることができ、RAMは安価です。データベースサーバー。

編集：これは現在、かなり時代遅れです。256ギガバイトのRAMを搭載したMSSQLボックスがあります。

メモリ（または他のコンポーネント）の追加購入に飛びつく前に、サーバーでパフォーマンス分析を実行することをお勧めします。これは、perfmonを使用して自分で行うことも、サードパーティのツールを使用して確認することもできます。OSとSQLサーバーの両方のパフォーマンスを分析する必要があります。私見では、適切な分析が行われる前にハードウェアを問題に投げる準備ができていることがあまりにも多いです。この時点で知っているすべての人にとって、クエリ、ストアドプロシージャ、実行計画、ディスクI / O、CPU使用率などに問題がある可能性があります。メモリのプレッシャーは、多くの場合、システムの別のボトルネックの症状です。

「悪魔の子犬」が言ったように、RAMが多すぎるというようなことはありませんが、6GBでも大丈夫です。サーバーの動作を再考する必要があります。「ハードウェア」の問題はないと思います。 SQLプログラミングに焦点を当てる...

データベースサーバーに関して言えば、「十分な」メモリというものはありません。確かに、実際に何を実行するかに依存しますが、大量のデータを含み、複雑なクエリを実行する常時使用されるデータベースである場合、6 GBは簡単に不十分です。

まず、面倒なサーバーを少なくとも32 GBまたは64 GBにアップグレードして、それが役立つかどうかを確認します。そうでない場合は、データベースのチューニング、アプリケーションのトラブルシューティング、およびデバッグに移ります-すべて、ばかがデータベースを設計しない限り、サーバーグレードのメモリを数スティック使用するよりもはるかにコストがかかります保持されたサポートで修正されたエラーは、非常に困難な場合があります）。

とはいえ、他の誰かが述べたように、ディスクまたはネットワークI / Oパフォーマンスの不足など、ソフトウェア設計の問題は別として、それを妨げる何かがあります-DBAプロを雇って、一日が役に立つかもしれません。

より多くのインデックスを構築する必要があります。一般的に、ほとんどの人は自分のデータベースのインデックス付けを下回っていると思います。

これはまだエアコードであり、私はまだ完全にはテストしていませんが、正しい方向に導くはずです

http://accessadp.com/2011/08/22/missing-indexes-great-script-for-determining-roi/

Select ‘create index IX_’ +
 sys.objects.name +
 isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) +
 isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ +
 sys.objects.name +
 ‘(‘ +
 coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) +
 ‘) ‘ +
 isnull(‘ include (‘ + included_columns + ‘)’, ”)
 as CreateIndexSql,
 (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score,
 sys.schemas.schema_id,
 sys.schemas.name AS schema_name,
 sys.objects.object_id,
 sys.objects.name AS object_name,
 sys.objects.type,
 partitions.Rows, partitions.SizeMB,
 sys.dm_db_missing_index_details.equality_columns,
 sys.dm_db_missing_index_details.inequality_columns,
 sys.dm_db_missing_index_details.included_columns,
 sys.dm_db_missing_index_group_stats.unique_compiles,
 sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans,
 sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact,
 sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan,
 sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans,
 sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact,
 sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan
 FROM
 sys.objects
 JOIN (
 SELECT
 object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows,
 CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB
 FROM sys.dm_db_partition_stats
 WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table
 GROUP BY object_id
 ) AS partitions ON sys.objects.object_id=partitions.object_id
 JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id
 JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id
 JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle
 JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle
 WHERE
 sys.dm_db_missing_index_details.database_id=DB_ID()
 AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100