Назад | Перейти на главную страницу

SQL Server, похоже, занимает 40 ГБ ОЗУ, но продолжает читать диск… Почему?

Поэтому я выделил для SQL Server 40 ГБ ОЗУ.

Я вижу, что после первого запуска запроса к базе данных этот предел памяти в 40 ГБ будет быстро заполнен во время первого запуска, однако, когда я сделаю точно такой же запрос, это не повлияет на производительность, SQL все равно будет читать с жесткого диска, а не из ОЗУ.

Вся база данных составляет 42 ГБ (55 миллионов строк, 18 столбцов, 1 таблица, средний результат после запроса ~ 80 строк (с использованием TOP и сортировки для выбора следующих 80 строк)), максимальный размер выделенной памяти составляет 40 ГБ.

SQL Server 2008 R2, Windows 2008 R2 DataCenter ...

Пример запроса: выберите * из DB..Table, где столбец A> 333 и столбец B> 3333, а столбец C, например, "% test%", упорядочить по имени пользователя.

Как заставить SQL Server использовать данные, хранящиеся в RAM ???

Может быть, лучше создать RAM диск 42GB и просто переместить туда всю базу данных ???

В настоящее время я использую 15k 4x 450 ГБ SAS в RAID 0 (недостаточно производительности в RAID10, плюс я делаю резервные копии каждые 6 часов), но кажется, что что-то не так с одним из дисков (~ 150 МБ / с (обычно 520 МБ / с)), поэтому в настоящее время я ожидание доставки 4x SSD, которые я хочу использовать в RAID 0 и, надеюсь, достичь не менее 1,2 ГБ / с (1x SSD достигает с этой базой данных ~ 570 МБ / с).

Как я могу использовать эту оперативную память, поскольку кажется, что SQL Server просто тратит ее без каких-либо преимуществ для производительности ...

Эта база данных не получает много запросов, но каждый запрос довольно большой с большим количеством «где».

ЦП - 2x Xeon E5645 и не является узким местом (почти всегда использование 10-15% во время выполнения запросов)

Это таблица результатов, рассчитанная и созданная из двух других таблиц (каждая более 1 ТБ данных), и ожидаемый рост составляет ~ 20 ГБ в день до ~ 300 миллионов строк, к сожалению, я не могу добиться комфортной производительности :(