У меня довольно много серверов, развернутых по всему миру. Они работают под управлением Windows 2003 x64 с SQL Server 2005 x64 с 6 ГБ ОЗУ. Коробки не имеют лучшей (или даже приемлемой) конфигурации, потому что парень, заказавший их много лет назад, действительно не знал, что он делал.
Ящикам довольно постоянно не хватает памяти, в конечном итоге они используют файл подкачки, и все замедляется. Обычно плата за фиксацию составляет 5,8 ГБ, а затем, когда кому-то нужно сделать что-то интенсивное (например, запустить отчет), эта цифра зашкаливает.
Я пытался получить силы, которые заказывали бы больше памяти, но я получаю массовое сопротивление (например, сделать программное обеспечение более производительным, слишком дорого стоит для всех этих серверов или доказать, что в коробке недостаточно памяти и т. Д. ..).
Есть ли рекомендации (или формула) для определения количества оперативной памяти, необходимой для коробки, которую я могу предоставить неспециалистам, чтобы мы, наконец, могли заказать больше памяти?
Самый простой способ узнать, нужно ли вам больше ОЗУ, - это составить график счетчика производительности страницы. Этот счетчик показывает, как долго, по мнению SQL Server, данные будут храниться в пуле буферов, прежде чем потребуется освободить место для других данных. Вы хотите, чтобы это число было как можно больше. Если установлено 6 гигабайт оперативной памяти (у вас должно быть установлено максимальное значение SQL, вероятно, на 4 гигабайта), вы, вероятно, будете хранить данные в памяти максимум на несколько минут, когда кто-то запустит большой отчет, вы увидите это число. до нескольких секунд. Чем больше у вас ОЗУ, тем дольше данные могут храниться в памяти и тем меньше потребуется выполнять чтение с дисков.
Например, системы, с которыми я работаю в настоящее время, имеют 256 ГБ ОЗУ, и мы храним данные в памяти примерно 12000 секунд или около того.
Пожалуйста, не просите поразить целевое число, вам просто нужно, чтобы оно было как можно большим. Не зная НАМНОГО больше о ваших системах, я не могу назвать точную цифру, по которой можно стрелять.
Трудно сказать, потому что это полностью зависит от вашего использования и приложения. Вы исчерпываете сервер базы данных ... насколько велика база данных? Какая у вас статистика транзакций?
Реальные ограничения в вашем сценарии очевидны. Вы какое-то время работаете на 6 гигах без проблем, потом меняет местами и бьется. Таким образом, 6 гигов мало.
Если производительности достаточно, чтобы повлиять на бизнес, то ваше начальство должно слышать достаточно жалоб, чтобы улучшить память. Выясните, сколько стоит ваше время, а затем выясните, сколько будет стоить «настройка» сервера и устранение неполадок при настройке, когда добавленная к серверу память вполне может решить проблему за счет стоимости памяти и менее получаса время простоя.
Вы не будете знать точный объем памяти, который вам нужен, пока не развернете его в реальной жизни и не начнете работать оттуда.
Тем не менее, вы можете убедиться, что ваше приложение действительно является узким местом. Запустите монитор производительности Windows, чтобы увидеть статистику ввода-вывода вашего диска и пропускную способность сети. Посмотрите, какой у вас уровень фрагментации (Google здесь хороший друг). Вы также можете попробовать проверить код на предмет очевидных проблем, когда запрос оказывается чрезвычайно неэффективным (Снова Google).
Но опять же, все зависит от того, насколько сильно это влияет на бизнес. Стоит ли больше вкладываться в настройку, или достаточно сначала использовать оборудование, а затем попробовать настроить его?
Хмммм. Что ж, 6 гигов - это приличный объем памяти даже для большой установки MSSQL. Возможно, вы действительно захотите посмотреть и убедиться, что ваш код действительно эффективен. Транзакция в 6 гигабайт - это немного необычно ... Я работал над общегосударственными системами начисления заработной платы, которые не превысили гигабайт по обработке данных на конец 1099 года ... довольно часто? Я не знаю. С какими данными вы работаете?
При этом вы можете поместить столько ОЗУ, сколько захотите, в 64-битную коробку, а оперативная память очень дешевая, так что с таким же успехом можно положить туда столько, сколько возможно ... На самом деле не может быть слишком много ОЗУ на сервер базы данных.
Изменить: сейчас это дико устарело. У меня есть MSSQL боксы с 256 гигами ОЗУ.
Прежде чем вы решите купить дополнительную память (или любой другой компонент), я бы порекомендовал провести анализ производительности на сервере. Вы можете сделать это самостоятельно с помощью perfmon или взглянуть на сторонние инструменты. Вам следует проанализировать производительность как ОС, так и SQL-сервера. ИМХО, слишком часто мы готовы использовать оборудование для решения проблемы до того, как будет проведен надлежащий анализ. Насколько вам известно, на данный момент это может быть проблема с запросом, хранимой процедурой, планом выполнения, дисковым вводом-выводом, загрузкой ЦП и т. Д. И т. Д. Нехватка памяти часто может быть признаком другого узкого места в системе.
как сказал Satanicpuppy, не бывает слишком много оперативной памяти, но 6 ГБ должно быть в порядке, возможно, вам стоит переосмыслить то, что делает ваш сервер, я не думаю, что у вас есть «аппаратная» проблема, вам следует сосредоточьтесь на программировании SQL ...
Когда дело доходит до серверов баз данных, нет такого понятия, как «достаточно» памяти. Конечно, это зависит от того, что они на самом деле делают и запускают, но если это постоянно используемая база данных, содержащая много данных и выполняющая сложные запросы, 6 ГБ может быть явно недостаточно.
Я бы начал с обновления одного проблемного сервера до 32 или 64 ГБ и посмотрел, поможет ли это. Если нет, обратитесь к настройке базы данных, устранению неполадок и отладке приложений - все это, если только идиот не разработал базу данных, стоит намного больше, чем несколько палочек серверной памяти (и даже если идиот спроектировал эту вещь, получив даже очевидный дизайн ошибки, исправленные с сохранением поддержки, могут оказаться довольно сложной задачей).
Тем не менее, как сказал кто-то другой, это может быть что-то еще, сдерживающее его (помимо проблем с дизайном программного обеспечения), например, отсутствие производительности дискового или сетевого ввода-вывода - наем профессионального администратора баз данных, чтобы просто пройти базовый мониторинг производительности SQL для день может оказаться полезным.
Вам следует подумать о создании большего количества индексов. Я думаю, что в целом большинство людей недооценивают свою базу данных.
Это все еще воздушный код, я еще не тестировал его полностью, но он должен направить вас в правильном направлении.
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