Сколько оперативной памяти на самом деле нужно серверу?

У меня есть довольно много серверов, развернутых по всему миру. Они работают под управлением Windows 2003 x64 с SQL Server 2005 x64 с 6 ГБ оперативной памяти. Коробки не имеют лучшей (или даже приемлемой) конфигурации, потому что парень, который заказал их много лет назад, на самом деле не знал, что делает.

Ящикам довольно постоянно не хватает памяти, в итоге используется файл подкачки, и все замедляется. Как правило, размер комиссии за коммит составляет 5,8 ГБ, а затем, когда кому-то нужно что-то сделать интенсивно (например, запустить отчет), это число проходит через крышу.

Я пытался получить возможности, которые на порядок больше памяти, но я получаю массивное противодействие (например, сделать программное обеспечение более производительным, стоит слишком дорого для всех этих серверов или доказать, что на устройстве недостаточно памяти и т. Д.). ..).

Существуют ли руководящие принципы (или формула) для определения объема оперативной памяти, которую блок может предоставить нетехническим специалистам, чтобы мы могли, наконец, заказать больше памяти?

На самом деле нет никакого способа легко сказать, потому что это полностью зависит от вашего использования и приложения. Вы максимально используете сервер базы данных ... насколько велика база данных? Какова ваша статистика транзакций?

Реальные ограничения очевидны в вашем сценарии. Вы бежите некоторое время на 6 концертах без проблем, затем он меняет местами. Это 6 концертов недостаточно.

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

Вы не будете знать точный объем памяти, который вам нужен, до тех пор, пока вы фактически не развернетесь в своем реальном использовании и не будете работать оттуда.

Тем не менее, вы можете убедиться, что ваше приложение действительно является узким местом. Запустите монитор производительности Windows, чтобы увидеть статистику дискового ввода-вывода и пропускную способность сети. Посмотрите, какой у вас уровень фрагментации ( Google здесь хороший друг ). Вы можете попробовать выполнить аудит кода и для очевидных проблем, когда запрос в значительной степени неэффективен ( снова Google ).

Но опять-таки все зависит от того, насколько сильно это влияет на бизнес. Стоит ли больше вкладывать в настройку или это достаточно плохо, чтобы сначала бросить на него аппаратное обеспечение, а затем попробовать его настроить?

Самый простой способ узнать, нужно ли вам больше оперативной памяти, - это составить график счетчика производительности Page Life Expectancy. Этот счетчик сообщает, как долго SQL Server считает, что данные будут храниться в пуле буферов, прежде чем ему потребуется место для других данных. Вы хотите, чтобы это число было как можно выше. Если установлено 6 ГБ ОЗУ (для вас должно быть установлено максимальное значение SQL, вероятно, 4 ГБ), вы, вероятно, будете хранить данные в памяти не более нескольких минут, когда кто-то запускает большой отчет, вы увидите этот номерной бак. до нескольких секунд. Чем больше у вас ОЗУ, тем дольше данные могут храниться в памяти, и тем меньше потребуется чтения с дисков.

Например, системы, с которыми я сейчас работаю, имеют 256 ГБ ОЗУ, и мы храним данные в памяти около 12000 секунд или около того.

Пожалуйста, не спрашивайте номер цели, вы хотите, чтобы номер был как можно выше. Не зная много о ваших системах, я не могу дать хорошее число, чтобы стрелять.

Хммм. Ну, 6 гигабайт - это неплохое количество оперативной памяти, даже для большой установки MSSQL. Возможно, вы захотите посмотреть и убедиться, что ваш код действительно эффективен. 6-гигабитная транзакция немного необычна ... Я работал над системами начисления заработной платы по всему штату, которые не превышали гиг на обработку 1099 года в конце года ... И чтобы одна часто работала ? Я не знаю. С какими данными вы работаете?

При этом вы можете загружать столько памяти, сколько захотите, в 64-битную коробку, а оперативная память очень дешевая, так что вы можете поместить туда столько памяти, сколько сможете ... Не может быть слишком много оперативной памяти сервер базы данных.

Изменить: сейчас это сильно устарело. У меня есть коробки MSSQL с 256 гигабайтами оперативной памяти.

Перед тем, как начать покупать больше памяти (или любого другого компонента), я бы порекомендовал провести анализ производительности на сервере. Вы можете сделать это самостоятельно с помощью perfmon или использовать сторонние инструменты. Вы должны проанализировать производительность как ОС, так и SQL-сервера. ИМХО, слишком часто мы готовы бросить аппаратное обеспечение в проблему до того, как будет проведен надлежащий анализ. Насколько вам известно, на данный момент это может быть проблема с запросом, хранимой процедурой, планом выполнения, дисковым вводом-выводом, использованием ЦП и т. Д. И т. Д. Давление памяти часто может быть признаком другого узкого места в системе.

как сказал «Satanicpuppy», не существует такой вещи, как слишком много ОЗУ, но 6 ГБ должно быть в порядке, может быть, вам следует подумать о том, что делает ваш сервер, я не думаю, что у вас есть «аппаратная» проблема, вы должны сосредоточиться на программировании SQL ...

Когда дело доходит до серверов баз данных, нет такой вещи, как «достаточно» памяти. Конечно, это зависит от того, что они на самом деле делают и работают, но если это постоянно используемая база данных, содержащая много данных и выполняющая сложные запросы - 6 ГБ могут быть совершенно неадекватными.

Я бы начал с обновления одного проблемного сервера как минимум до 32 или 64 ГБ и посмотрел, поможет ли он. Если нет, обратитесь к настройке базы данных, устранению неполадок приложений и отладке - и все это, если только идиот не разработал базу данных, будет стоить намного больше, чем несколько кусков памяти серверного уровня (и даже если идиот спроектировал эту вещь, получая даже очевидный дизайн ошибки, исправленные с сохранением поддержки, могут оказаться довольно сложной задачей).

Тем не менее, как сказал кто-то другой - это может быть что-то еще, сдерживающее его (помимо проблем разработки программного обеспечения), например, отсутствие производительности дискового или сетевого ввода-вывода - найм профессионала DBA, чтобы просто пройти базовый мониторинг производительности 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