Может ли сервер иметь "слишком много" оперативной памяти? Есть ли оптимальный уровень оперативной памяти или лучше всегда лучше?
Недавно наш администратор сервера сказал мне, что на новых серверах, которые мы заказали с 140 ГБ ОЗУ, было "слишком много" оперативной памяти, и что серверы начали страдать с более чем 80 ГБ, так как это было "оптимальным объемом". Дует ли он, или действительно проблема в производительности с большим количеством оперативной памяти, чем определенный уровень? Я мог видеть аргумент - больше для ОС, чтобы управлять, и т. Д. - но это законно, или дополнительная передышка больше, чем восполняет управление?
Я не спрашиваю "буду ли я все это использовать" (это кластер SQL Server с десятками экземпляров, так что я подозреваю, что это произойдет, но это не относится к моему вопросу), а просто о том, может ли слишком много вызвать проблемы. Я всегда предполагал, что чем больше, тем лучше, но, может быть, этому есть предел.
6 ответов
Есть несколько порогов для "слишком много", хотя это особые случаи.
В 32-битной среде PAE - это то, что позволяет вам получить доступ к памяти через линию 4 ГБ. Теоретический максимум для 32-разрядных машин составляет 64 ГБ ОЗУ, что отражает дополнительные 4 бита, которые PAE дает адреса памяти. 64 ГБ меньше, чем 80 ГБ.
Оттуда мы получаем проблемы, связанные с процессором. 64-разрядные процессоры в настоящее время используют от 40 до 48 бит для адресации памяти, что дает максимальный предел памяти от 1 до 256 ТБ. В обе стороны более 80Гб.
Если у него нет каких-либо четких причин, по которым SQL Server не может обрабатывать столько памяти, базовая ОС и оборудование могут сделать это без проблем.
Он курил дым - если бы он сказал 4 ГБ, а вы использовали 32-битные операционные системы, тогда у него могла бы быть половина аргумента, но нет, 80 ГБ - это просто число, которое он вытащил из воздуха.
Очевидно, что есть некоторые проблемы, если память не "покупается разумно", например, большие модули DIMM обычно стоят более чем вдвое дороже, чем версии половинного размера (т.е. 16 ГБ DIMMS более чем вдвое больше 8 ГБ DIMMS), и вы можете замедлить работу машины довольно далеко, не используя правильный номер / размер / расположение памяти, но все равно это будет очень быстро. Кроме того, конечно, чем больше у вас памяти, тем больше у вас порчи, но я уверен, что вы будете довольны этой системой за то, что вы просите об этом.
Я извиняюсь, но большинство из этих ответов неверны. На самом деле есть момент, когда больше ОЗУ будет работать медленнее. Для серверов HP с 18 слотами, таких как G7, заполнение всех 18 слотов приведет к тому, что память будет работать с 800 вместо 1333. Некоторые спецификации см. Здесь:
http://www8.hp.com/h20195/v2/GetHTML.aspx?docname=c04286665
(Нажмите на память, конечно.)
Типичная конфигурация памяти с 12 заполненными слотами будет 48G (все 4 с), 72G (8 с и 4 с), 96G (все 8 с) и т. Д.... когда вы говорите "140G", я предполагаю, что вы действительно имеете в виду 144G, что, скорее всего, будет 8G во всех 18 слотах. Это на самом деле замедлит вас.
Из того, что я сделал, выяснилось, что более медленная скорость памяти не влияет на многие приложения, но известно, что она влияет на приложения баз данных. В этом случае вы говорите, что это для кластера SQL, так что да, для этого, слишком много оперативной памяти может замедлить вас.
Возможно, администратор сервера, с которым вы говорили, знал об этом из практического опыта, не зная точных технических причин.
Надеюсь, это поможет,
-Jody-
Я нашел по крайней мере один сценарий, в котором вы можете иметь слишком много оперативной памяти. По общему признанию, это ограничение программного обеспечения, а не аппаратное ограничение.
Java-приложения (например, ElasticSearch) страдают при использовании более 32 ГБ оперативной памяти из-за смещения сжатых объектов.
Дополнительная информация:
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/heap-sizing.html
Возьмите это до крайности и скажите, что у вас есть петабайты памяти: система (процессор) не будет работать больше, чтобы управлять отображениями памяти. Операционная система должна быть достаточно умной, чтобы использовать эту память для кэширования диска, и при этом иметь достаточно ресурсов для управления пространством приложения (памятью и кодом). Отображение памяти в ОЗУ в сравнении с виртуальным пространством будет занимать такое же количество циклов ЦП.
В конечном счете, единственное, что страдает от слишком большого количества памяти, - это потраченная впустую энергия.
Предполагая, что ЦП действительно может использовать ОЗУ (это не одно из особых порогов, о которых упоминал sysadmin1138), увеличение объема ОЗУ не может повлиять на производительность.
Однако, поскольку у вас ограниченный бюджет, действительно может быть некоторый "оптимальный" объем ОЗУ - если вы тратите больше денег на ОЗУ, то у вас меньше денег на ЦП и жесткий диск (и) и ввод-вывод. Если узким местом является что-то иное, чем ОЗУ, то добавление большего объема ОЗУ не влияет на производительность (хотя и не снижает производительность), а стоит денег, которые вместо этого можно было бы использовать для устранения узкого места.
(Я пренебрегаю стоимостью электроэнергии для питания серверов и стоимостью электроэнергии для охлаждения серверов - эти затраты могут оказать большое влияние на "оптимизацию" выбора оборудования в центре обработки данных).
Просто добавляем этот небольшой фрагмент информации в цикл
На время запуска / загрузки всегда влияет дополнительный ОЗУ - его нужно подсчитывать, и на одном из моих серверов полная перезагрузка или запуск занимает 30 минут даже при быстрой загрузке, просто чтобы посчитать дополнительный ОЗУ (384 ГБ на этом сервере) и это еще до начала загрузки. Надеюсь, вам не придется часто перезагружать сервер, но я решил, что упомяну об этом, так как никто другой этого не делал.
Я согласен со всем вышеперечисленным в целом, и в большинстве случаев лучше с учетом исключений.
Последняя мысль - всегда помните цитату Билла Гейтса о том, что никогда не нужно больше 640 КБ памяти.