Команды разработчиков ERP-систем и баз данных часто обвиняют процессор, систему хранения данных или “медленный SQL”, в то время как реальное узкое место проще: рабочий набор уже не помещается в памяти. В этой статье объясняется, почему SAP HANA, SQL Server, Oracle Database In-Memory и другие корпоративные системы зависят от большого объема памяти.
Быстрые процессоры врут.
Я наблюдал, как команды по закупкам утверждают новые процессоры, более быстрые NVMe-накопители и очередную порцию “настройки производительности”, в то время как команда по работе с базами данных спокойно признает, что активные данные, буферный пул, хранилище колонок или рабочая нагрузка ERP-постинга просто не могут больше оставаться в оперативной памяти, что означает, что сервер не вычисляет медленно, а ждет дорого. Почему это до сих пор остается загадкой?
Вот суровая правда: рабочие нагрузки с интенсивным использованием памяти наказывать за догадки. Не мягко. Не со временем. А сразу же.
Рабочие нагрузки ERP и баз данных не ведут себя как веб-уровень без статических данных. Они хранят историю. Они содержат цепочки транзакций. Они несут в себе индексы, блокировки, столбцовые структуры, давление отмены/повтора, кэшированные планы выполнения, запросы к отчетам, пакетные задания и всплески в конце месяца, которые проносятся с неуловимостью грузовика сквозь стеклянную стену.
Компания SAP прямо говорит о спокойной части в своем Руководство по определению размеров SAP HANA: Определение размеров SAP HANA в основном зависит от объема основной памяти, а сжатие варьируется настолько, что для определения размеров следует использовать инструменты или отчеты SAP, а не фантастическую математику.
Именно поэтому я не спрашиваю сначала “Сколько оперативной памяти у этого сервера?”.
спрашиваю я: Что должно оставаться в памяти, когда бизнес находится под давлением?
Большинство продавцов продают скорость, потому что ее легко напечатать в расценках.
Вместимость - это еще хуже. Она заставляет задавать неудобные вопросы: Насколько велик горячий набор данных? Сколько свободного места остается после резервирования ОС, резервирования памяти базы данных, накладных расходов HA, накладных расходов ВМ и роста? Используем ли мы ECC RDIMM или LRDIMM? Сбалансированы ли все каналы памяти? Не смешиваем ли мы ряды, как дилетанты?
Но вот мое мнение, сложившееся после многих лет покупки инфраструктуры: если рабочая нагрузка ERP или базы данных работает с пейджингом, кэшем или постоянно вытесняет горячие страницы, то еще один уровень процессора часто является просто декоративным металлом.
В документации Microsoft по SQL Server говорится, что внезапное падение показателя Page Life Expectancy может свидетельствовать о сильной перегрузке буферного пула, что означает, что рабочая нагрузка не может в полной мере воспользоваться данными, уже находящимися в памяти. Это не абстракция. Это база данных, которая машет тревожным флажком. Мониторинг памяти Microsoft SQL Server позволяет увидеть это через метрики буферного пула и поведение при попадании в кэш.
Поэтому, когда кто-то спрашивает: “Почему базам данных нужно так много оперативной памяти?”, я отвечаю прямо: потому что диски - это место, куда базы данных отправляются, чтобы извиниться за плохой размер.
Пропускная способность памяти имеет значение, когда процессор быстро обрабатывает большие объемы данных.
Объем памяти имеет значение, когда рабочий набор вообще должен помещаться в оперативной памяти.
Это не одна и та же проблема. Платформа DDR5 с большим количеством каналов может перемещать данные быстрее, но если на сервере установлено всего 512 ГБ, а реальный рабочий набор достигает 900 ГБ во время закрытия квартала, пропускная способность вас не спасет. Вам не хватает пропускной способности. Полностью.
| Тип рабочей нагрузки | Что съедает память | Сигнал мощности | Плохая привычка покупать |
|---|---|---|---|
| SAP HANA ERP / S/4HANA | Таблицы столбцов, дельта-хранилища, структуры сжатия, расчетные представления, пиковые рабочие периоды | Пиковая память во время тестирования в конце месяца, года или миграции | Покупка “средней загрузки” вместо пиковой безопасной мощности |
| SQL Server OLTP | Буферный пул, кэш планов, гранты на память, давление на tempdb, чтение с большим количеством индексов | Падение продолжительности жизни страниц, большое количество физических чтений, низкая стабильность кэша | Добавление процессора до исправления давления в буферном пуле |
| Oracle Database In-Memory | Хранилище столбцов IM, аналитические объекты, выбор дублирования RAC, горячие разделы | INMEMORY_SIZE, население объектов, поведение холодных/горячих сегментов | Отношение к опции In-Memory как к волшебству вместо определения размера хранилища колонок |
| Смешанная ERP + отчетность | Таблицы транзакций, экстракты отчетов, запросы к хранилищу, пакетные задания | Всплески во время обновления BI, расчета заработной платы, MRP, выставления счетов, закрытия счетов | Определение размера для дневных пользователей и игнорирование пакетных окон |
| Виртуализированные базы данных | Гостевая память, резерв гипервизора, локальность NUMA, риск вздутия | Соперничество хостов, дисбаланс NUMA, непредсказуемые задержки | Перерасход памяти из-за того, что электронная таблица выглядит эффективной |
Oracle по-своему так же прямолинеен. Сайт Документация Oracle Database In-Memory По словам разработчиков, In-Memory Column Store является ключевой функцией для аналитики в реальном времени и смешанных рабочих нагрузок, а для того, чтобы запросы получали пользу, необходимо определить размер хранилища столбцов IM.
Обратите внимание на узор.
SAP говорит о размере памяти. Microsoft показывает, когда отток кэша вредит. Oracle говорит, что хранилище колонок должно быть определенного размера. Тем не менее покупатели все еще одержимы идеей о SKU процессоров, которые позволят уместить рабочий набор размером 600 ГБ в 384 ГБ.
Не будет.
Рабочие нагрузки ERP - это политические системы, замаскированные под базы данных.
Финансы хотят быстрого закрытия. Операциям нужен MRP. Продажи хотят доступности к обещаниям. Комплаенс требует отчетов. Руководителям нужны информационные панели. Никто не хочет слышать, что “сервер базы данных” на самом деле хранит бизнес-модель в энергозависимой памяти.
Рабочие нагрузки ERP требуют большого объема памяти, поскольку данные ERP являются реляционными, историческими, взаимосвязанными и чувствительными к времени. Один прогон проводок или цикл планирования может затрагивать инвентаризацию, ценообразование, данные о поставщиках, остатки клиентов, логику налогообложения, таблицы валют, аудиторские записи и состояния рабочего процесса. Это не маленький аккуратный запрос. Это спор со всей компанией.
В SAP HANA это еще более очевидно, поскольку она является базой данных in-memory. AWS советует, чтобы при миграции SAP HANA команды определяли размер системы на основе пиковая загрузка памяти, И даже рекомендует проводить измерения в периоды высокой нагрузки, например, в конце года или во время крупных распродаж. Руководство по определению размеров AWS SAP HANA полезно, потому что оно говорит то, чего избегают многие внутренние команды: выделенная память менее полезна, чем измеренный пиковый спрос.
Именно здесь я обычно вижу ошибку в закупках.
Они покупают мощности для обычного вторника. В ненормальную пятницу бизнес терпит крах.
Для серверных рабочих нагрузок с большим объемом памяти я бы предпочел, чтобы команды начинали с проверенной платформы и плана модулей: проверенные ECC RDIMM, LRDIMM там, где этого требует плотность, чистые правила популяции и точное соответствие деталей. ServerDimm's оптовый поставщик оперативной памяти сервера Страница подходит для этого направления закупок, поскольку она построена на поиске поставщиков DDR3, DDR4, DDR5, ECC, RDIMM и LRDIMM для предприятий и центров обработки данных. Для проектов обновления я бы сопоставил старые системы Xeon Scalable или EPYC с Серверная память DDR4 и новые платформы высокой плотности против Серверная память DDR5 прежде чем говорить о цене.
Цена имеет значение. Неправильная память стоит дороже.
Память - это не просто емкость. Это риск.
Я видел, как команды относятся к ECC как к магическому религиозному объекту. “Здесь есть ECC, значит, все в порядке”. Нет. ECC снижает риск. Он не стирает реальность парка, стареющие модули, некачественные модули DIMM, проблемы с прошивкой, плохую валидацию, плохое обращение или небрежную замену.
Полевое исследование Google, Ошибки DRAM в дикой природе, В ходе исследования было обнаружено от 25 000 до 70 000 ошибок на миллиард часов работы устройств на Мбит и более 8% модулей DIMM, пострадавших от ошибок в год. Это не анекдот из Reddit. Это данные производственного масштаба.
Документ Carnegie Mellon/Facebook, Пересмотр ошибок памяти в крупномасштабных производственных центрах обработки данных, В исследовании, проведенном компанией Facebook за 14 месяцев и миллиарды дней работы устройств, говорится о том, что именно с такими данными следует ознакомиться покупателям, прежде чем притворяться, что риск для памяти теоретический.
А перебои в работе - недешевый театр. Uptime Institute's Анализ ежегодных отключений до 2024 года сообщили, что 54% опрошенных респондентов заявили, что их последний значительный, серьезный или тяжелый выход из строя стоил более $100 000, а 16% заявили, что он стоил более $1 миллиона.
Это меняет ход разговора о покупке.
Разница в $40 на DIMM выглядит разумно до тех пор, пока вышедший из строя узел ERP не окажется на складе “совместимых” модулей, которые никто не протестировал должным образом. Вот почему мне нравится помещать статью о проверке непосредственно в путь покупателя: проверка используемой памяти сервера принадлежит к тем же категориям, что и стоимость, гарантия и время выполнения заказа.
Я не доверяю типовым калькуляторам оперативной памяти для рабочих нагрузок ERP и баз данных.
Я доверяю измеренным пикам, окнам рабочей нагрузки, правилам поставщиков и уродливым электронным таблицам, в которых точно указаны серверы, сокеты, слоты DIMM, каналы памяти, ранги, скорости, версии BIOS, операционные системы, версии баз данных и предположения о росте.
Вот последовательность определения размеров, которую я бы использовал, прежде чем утверждать объем памяти для узла ERP или базы данных:
Среднее использование памяти - это то, как команды обманывают сами себя.
Для SAP HANA мне нужны пиковые объемы памяти в конце месяца, при закрытии квартала, в конце года, во время пробных миграций и при увеличении объема отчетности. Для SQL Server мне нужно поведение буферного пула, физическое чтение, гранты на память и снижение продолжительности жизни страниц. Для Oracle Database In-Memory мне нужны заполненные объекты, размер хранилища столбцов IM и поведение горячих/холодных сегментов.
Если рабочий набор не подходит, купите емкость.
Если она подходит, но при сканировании происходит голодание конвейеров процессора, значит, большее значение имеют пропускная способность, каналы памяти, размещение NUMA и архитектура процессора. Многие команды объединяют все эти проблемы в одну расплывчатую проблему “производительность оперативной памяти”, а затем покупают неправильное решение.
Потому что это возможно.
На многосокетных серверах локальность памяти может превратить чистый дизайн базы данных в налог на латентность. Я хочу, чтобы модули DIMM были симметрично распределены по каналам и сокетам. Я хочу, чтобы план памяти базы данных соответствовал физической платформе. И я хочу, чтобы команды виртуализации перестали притворяться, что “назначенная оперативная память” и “быстрая локальная память” - это всегда одно и то же.
Запасной бассейн - это не ящик для хлама.
Для живых ERP-систем, баз данных и аналитических систем реальная стратегия резервирования означает наличие утвержденных модулей, точных спецификаций, проверенных запасов, правил карантина и дисциплины пополнения запасов. Руководство ServerDimm о том, как Создайте резервный пул памяти сервера здесь уместно, потому что планирование мощностей без планирования замены - это только половина политики.
Я бы не стал начинать с предпочтения бренда.
Я бы начал с правды о платформе.
Для рабочих нагрузок баз данных лучшая серверная память - это память, соответствующая поддерживаемому поколению сервера, типу DIMM, расположению рядов, правилам скорости, плану заполнения каналов, целевой емкости и требованиям к проверке. Обычно это означает ECC RDIMM для многих основных узлов баз данных и LRDIMM, когда плотность на сокет имеет большее значение, чем простота.
Вот контрольный список неудобного покупателя:
| Точка принятия решения | Что я хочу увидеть | Почему это важно |
|---|---|---|
| Генерация DDR | DDR4-2933/3200 или DDR5-4800/5600 в соответствии с поддержкой платформы | Неправильное поколение физически и электрически несовместимо |
| Тип DIMM | ECC RDIMM или LRDIMM, а не расплывчатая “серверная оперативная память”.” | Время работы базы данных зависит от правильности обработки ошибок и поддерживаемой топологии |
| План мощностей | 25-40% запас хода за пределами измеренного пика для серьезных систем ERP/баз данных | При росте, увеличении объемов, отказоустойчивости и создании отчетов редко спрашивают разрешения |
| Баланс каналов | Симметричное распределение по каналам памяти процессора | Избегайте штрафов за пропускную способность и задержку |
| Ранг и скорость | Подтверждено в соответствии с правилами памяти OEM | Смешанные ряды могут разгонять или ограничивать поддерживаемые конфигурации |
| Доказательства поставщиков | Протоколы испытаний, точные номера деталей, гарантия, дисциплина упаковки | “Вытянутая работа” - это не политика подтверждения. |
| Запасная стратегия | Аварийный запас отделен от расширенного запаса | Предотвращает плановое обновление от кражи запасов для восстановления после сбоев |
При активном поиске поставщиков я бы подтолкнул покупателей к составлению предложений, которые требуют конкретики: модель сервера, поколение процессора, карта установленной памяти, целевая емкость, предпочтительные бренды, количество и сроки развертывания. Именно такие данные ServerDimm запрашивает в своем запрос котировок памяти сервера.
Плохая цитата гласит: “64 ГБ серверной оперативной памяти DDR4”.”
Хорошая цитата: “64GB DDR4-3200 ECC RDIMM, 2Rx4, одобрено платформой для Dell PowerEdge R750, согласованный набор, протестировано, необходимое количество 192 модуля, доставка во Франкфурт, гарантия подтверждена”.”
Видите разницу?
Один из них - магазин. Другой - инженер с заказом на поставку.
Рабочие нагрузки с интенсивным использованием памяти - это приложения, производительность и стабильность которых в первую очередь зависят от наличия достаточного количества оперативной памяти для хранения активных наборов данных, индексов, кэша, состояния транзакций и рабочих объектов, что позволяет системе избежать постоянного чтения с диска, подкачки, вытеснения, штрафов NUMA или переполнения кэша во время критически важной для бизнеса обработки.
Говоря простым языком, эти рабочие нагрузки замедляются, когда необходимые им данные не могут находиться рядом с процессором. ERP-системы, SAP HANA, SQL Server, Oracle Database In-Memory, Redis, аналитические платформы и крупные кластеры виртуализации - все они вписываются в эту схему, когда активный набор данных превышает объем установленной памяти.
Базы данных нуждаются в таком большом объеме оперативной памяти, потому что в ней хранятся часто используемые страницы данных, индексы, планы выполнения, хранилища столбцов, структуры транзакций и временные рабочие данные, что позволяет запросам и бизнес-процессам избегать повторных чтений с диска, которые увеличивают задержки, повышают нагрузку ввода-вывода и дестабилизируют производительность при пиковых нагрузках.
Вот почему объем памяти для рабочих нагрузок базы данных - это не просто аппаратная деталь. От него зависит, насколько предсказуемо будет вести себя система во время начисления зарплаты, выставления счетов, закрытия счетов, составления отчетов и резких скачков транзакций, связанных с работой с клиентами.
Требования к памяти SAP HANA зависят от размера исходной базы данных, характера сжатия, типа рабочей нагрузки, пиковой загрузки, модели развертывания и результатов расчетов SAP, поэтому при расчете необходимо использовать SAP Quick Sizer, отчеты SAP о расчете, SAP Notes или измеренное пиковое использование, а не общие предположения о количестве оперативной памяти на терабайт.
Ленивый ответ: “HANA сжимает данные, поэтому вам нужно меньше оперативной памяти”. Профессиональный ответ: “Измерьте и определите размер реальной рабочей нагрузки”. Сжатие может быть разным. Поведение рабочей нагрузки может быть разным. Бизнес-пики различны.
Объем памяти важнее, чем ее пропускная способность, когда активный набор данных рабочей нагрузки не помещается в оперативной памяти, поскольку никакая дополнительная пропускная способность не сможет предотвратить подкачку, вытеснение кэша, чтение с диска или сбои вне памяти, если в системе не хватает установленной памяти для реального рабочего набора.
Пропускная способность памяти становится более важной после достижения достаточной емкости. Именно тогда начинают доминировать количество каналов, скорость DDR5, локальность NUMA и архитектура памяти процессора. Сначала емкость. Затем пропускная способность.
Лучшая серверная память для рабочих нагрузок баз данных - это проверенная ECC RDIMM или LRDIMM, соответствующая серверной платформе, поколению процессоров, правилам размещения DIMM, ограничениям скорости, расположению рядов, целевой емкости и надежности базы данных, с достаточным запасом для пикового использования, отказоустойчивости и будущего роста.
Для многих серверов ECC RDIMM подходит по умолчанию. Для систем с очень высокой емкостью может потребоваться LRDIMM. Неправильный ответ - покупать только по маркировке емкости.
Не просите “больше памяти”.”
Попросите разработать план памяти с учетом рабочей нагрузки.
Проведите аудит пикового использования, подтвердите ограничения платформы, определите требования к DDR4 или DDR5, задокументируйте поддержку RDIMM и LRDIMM, сбалансируйте каналы памяти, зарезервируйте резерв для роста и держите наготове проверенные резервные запасы, прежде чем следующий инцидент с ERP или базой данных превратится в финансовую проблему.
Отправьте точную модель сервера, текущее расположение модулей DIMM, целевую емкость, тип рабочей нагрузки, количество и регион доставки через ServerDimm страница с массовым использованием памяти сервера и заставлять собеседника быть конкретным с первого письма. Именно так серьезные команды покупают память для нагрузок, требующих больших объемов памяти.
ServerDimm поставляет новую и бывшую в употреблении фирменную серверную память для дистрибьюторов, OEM-покупателей, реселлеров и команд центров обработки данных. Мы поддерживаем поиск источников памяти DDR4 и DDR5 благодаря проверенным запасам, проверке совместимости и оперативному предоставлению предложений.
Copyright © 2026 Shenzhen Lux Telecommunication Technology Co.,Ltd. Все права защищены
