RAMの推奨事項とSQLDBのサイズ
約40GBの中規模のSQLデータベースがあり、サーバー2008 r2x64を備えた新しいボックスに移動しようとしています。
高価な請負業者がやって来て、DB全体がRAMだと思いますが、何かが足りないので、72GBのRAMが必要だと言いました。
SQLインスタンスで使用するRAMの量が多いことを示唆する「経験則計算」があるかどうか疑問に思いました。
EDIT： DBには、予約システムの実行に使用される、一度に最大150人のユーザーがアクセスします。非常に厄介な古いDBスキーマ、多くのテーブルの恐ろしい量の列、半無意味なインデックスの膨大な配列。 .netがいくつかのsprocにアクセスするだけでなく、rawsqlやVisualDataFlexが使用するものを使用してクエリを実行することによってアクセスされます。
ありがとう
nat
良い経験則はありません。
追加のRAMの有用性は、データベースの設計方法とクエリパターンまたはユーザーに大きく依存します。極端な例として、合計で1 TBのデータがあり、適切なインデックスが作成され、特定の1行の後にのみ1000人の同時ユーザーがいる場合（pkey_id = 42の場合はdbo.BigTableから*を選択）、非常に少ないRAMでうまくいきます。より多くのRAMの影響は、ディスクストレージサブシステムの速度にも依存する可能性があります。超高速ストレージ（good SAN、good DASDまたはSSD）がある場合、サーバーがデータを読み取る必要があるときにラグに気付かない場合があります。
理想的には、データベースにあるすべてのデータが必要です必要になる可能性が高い日中にRAMにキャッシュされます。これは、「ホットデータ」または「ホットページ」と呼ばれることもあります（SQL Serverでは、データは「ページ」と呼ばれる単位で編成されます）。ホットデータの例としては、今日または昨日行われた注文があります。これは、それらの注文を出荷する労働者が必要とします。コールドデータの例としては、2年前に取得された注文がありますが、CSRが古い注文を検索できるように、システムにはまだ存在しています。
合計40GBのデータを備えた適切に設計されたOLTPシステムでは（合計40 GBのデータファイルとは対照的に）、ホットデータが10 GB、5GBになる可能性があります。 、1GB以下。昔は、64GBのRAMと8GB（またはそれ以下）の購入の違いは天文学的なものであり、RAMの量を正しく購入することは多くの費用をかける価値がありました。時間の。
OS、ウイルススキャナー、RDPセッションなどの「オーバーヘッド」には、常に少し余分なRAMが必要です。また、データベースの増大も考慮に入れる必要があります。
もう1つ覚えておくべきことは、RAMは「チャンク」であるということです。 48GBと49GBのどちらかを決めることはできません。おそらく、48GBから64GBにステップアップする必要があります。チャンクのサイズは、現在販売されているRAMテクノロジーと、メモリのチャネル数によって異なります。古いサーバーではメモリが1つ変更され、その後サーバーは2つに変更され、現在ではほとんどの強力なサーバーに3つのメモリチャネルがあります。したがって、スティックを1つだけ追加するのではなく、一度に2つ3つ追加する必要があります。
あなたが言うように、不十分に設計され、不十分に索引付けされたデータベースがある場合、SQLは、より適切に設計されたデータベースでは必要としない大量のデータを読み取ることになります。そのデータがすべてRAMにあるからといって、すべてが読み取られないわけではありません。これは、データがディスクストレージにある場合よりも、RAM内のすべてのデータをより速く読み取ることを意味します。それは必ずしもすべての問題を解決するわけではありません。 RAMからのデータの読み取りは高速ですが、それでも有限の時間がかかり、パフォーマンスの問題を引き起こす可能性のあるブロッキングやデッドロックの問題が発生する可能性があります。
もう1つのことは、昨年のデータを利用するシステムで大規模なレポートを実行する場合に、より多くのRAMが役立つことです。人々はOLTPシステムを常にレポートシステムのように扱います。これは、特に無計画なSQLクエリでは、まれに発生することではありません。
開発者とテスターに時間（とお金）を費やしてデータベース設計を改善し、これに必要なフロントエンドに変更を加えることができます。
Hp.comへの非常に短い旅行は、96GBのRAMを備えた（非常に）簡素化されたサーバーを約9,000米ドルで入手できることを示しています。
（サーバー内の他の部分を考慮しないと、GBあたり100米ドル未満です。電源やプロセッサなどの部品。私のような古い人々は、RAMがメガバイトあたり5,000米ドルだったことを覚えています。 M付き）
開発とテストの時間に9,000米ドルをどれだけ早く費やすことができますか？ （私の地域の企業レートでは、1か月に1人の人がいることはほとんどありません。）データベース内のすべてを修正するのに十分な時間ですか？変更されたコードのバグがすり抜けた場合はどうなりますか？
RAMを追加するためのサーバーの停止には、1時間かかる場合があり、ほぼすべての人が作業を行うことができます。まったく新しいサーバーへの移行には、準備作業に数日、ダウンタイムが1時間かかる場合があり、経験のある人（おそらく、DBA）が必要になります。
RAMを追加しても、バグが発生する可能性はほとんどありません。新しいサーバーに移行しても、見つけにくい問題が発生する可能性はほとんどありません。 （一般的に、機能するか、明らかに壊れています。通常、「おっと、間違ったパスワード」または「おっと、リンクされたサーバーをコピーするのを忘れた」であり、「ねえ、この計算が突然正しく機能しなくなる」ことはありません。）
したがって、すべてをRAMに保持し、40 GBのデータベースがあると仮定すると、オーバーヘッドのためのスペースが必要になります。私は48GBかそこらのサーバーを考えているでしょう。さらに、成長の余地が必要です。ここから25％の成長、つまり12 GBで、最大60GBになるとしましょう。次のレベルアップ（私が実際に購入できる）は64GBです。コンサルタントがトリプルチャネルサーバーを推奨している場合、次のレベルは72GBになる可能性があります。したがって、彼の提案は必ずしも風変わりなものではありません。たぶん、あなたはそれほど多くのコア/ソケットを必要としないでしょう、そしてそれはあなたをデュアルチャネルサーバー（とにかく安いでしょう）に戻すかもしれません、そしてあなたは少し少ないRAMを買うことができます。
TLDR：
要するに、私がめったにいないことですが、RAMは安く、時間もかかります。データベースを修正するためのお金、時間、または傾向がない場合、またはアプリケーションにバグを追加するリスクを冒したくない場合は、問題にRAMをスローすることは疑問の余地がありません。もう1つの良い方法は、ディスクストレージシステムの応答性を改善することです（IOW、スピンドルの追加、RPMの追加、またはSSDの使用）。
コンサルタントが、システムを書き直すために1年と10万ドルを費やしてほしくないのはなぜかと尋ねます。