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