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