Я ищу мнения и ресурсы о том, насколько производительность сервера увеличится с добавлением дополнительной оперативной памяти. Какие факторы играют роль? Можно ли провести общий расчет?
Это полностью субъективно ...
Если вы наблюдаете снижение производительности, вам нужно определить, где находится узкое место, и действовать дальше. Может помочь использование монитора производительности Windows. Случайное использование оборудования для решения проблемы может вообще не помочь (хотя обычно память не вредит).
В общем, вы получите лучшую производительность из базы данных, если рабочий набор данных полностью умещается в ОЗУ. Рабочий набор - это подмножество ваших данных, которое регулярно считывается запросами (обновление и вставка всегда попадают в базу данных, поэтому больше оперативной памяти не обязательно ускоряет их). Итак, сначала вам нужно определить, сколько памяти вам действительно нужно для кеширования всех соответствующих данных. Затем вам нужно найти лучший способ предоставить эту оперативную память SQL-серверу.
Насколько мне известно, нет никаких расчетов, которые предсказывали бы увеличение производительности на основе заданного увеличения объема памяти. Отношения между ними не являются линейными, и, как отмечают другие, всегда присутствуют другие факторы. Однако если предположить, что у вас нет серьезного узкого места в другом месте, добавление ОЗУ почти всегда помогает.
Еще одно замечание: если вы работаете в 32-разрядных версиях Windows и / или SQL Server, вы ограничены объемом оперативной памяти от 2 до 4 ГБ в зависимости от конфигурации обоих серверов. Если вы обновите обе до 64-битных версий вы можете использовать более 4 ГБ ОЗУ для повышения производительности.
Как предложил Барт, вам необходимо изолировать и определить основные узкие места на сервере и устранить их для достижения оптимальной производительности. Поскольку вы уже используете SQL Server 2005, вы можете использовать статистику ожидания на сервере. Вот запрос из диагностических запросов Гленна. Вот ссылка. http://glennberrysqlperformance.spaces.live.com/blog/cns!45041418ECCAA960!1340.entry
-- Isolate top waits for server instance since last restart or statistics clear WITH Waits AS (SELECT wait_type, wait_time_ms / 1000. AS wait_time_s, 100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct, ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn FROM sys.dm_os_wait_stats WHERE wait_type NOT IN( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP')) -- filter out additional irrelevant waits SELECT W1.wait_type, CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s, CAST(W1.pct AS DECIMAL(12, 2)) AS pct, CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct FROM Waits AS W1 INNER JOIN Waits AS W2 ON W2.rnПри этом, как правило, SQL Server в основном ограничен памятью, вводом-выводом и процессором и в основном в этом порядке. Вам нужно посмотреть значение ожидаемой продолжительности жизни страницы с помощью DMV сервера perfmon / sql. SQL Server процветает, если у него больше памяти. Но обратите внимание, что я против использования оборудования для решения проблемы, когда лучше всего работать в областях TSQL. Скорее всего, вам нужно посмотреть на запросы, которые выполняют большую часть операций ввода-вывода (они, вероятно, будут перегружать буферный пул), создать значимые индексы, отбросить неиспользуемые индексы, поработать с отсутствующими индексами или оптимизировать sql. Оптимизация sql - это то место, где люди обычно терпят неудачу из-за отсутствия навыков.