Лё 3.14нцет. Более чем в 2 раза...

Создана она для того, что бы вывести США в топ 1 по искусственному интеллекту в мире. А ИИ нужна память. ОЧЕНЬ МНОГО памяти. При поддержке Samsung и SK Hynix они заключили соглашение на поставку до 900 000 чипов DRAM ежемесячно. Что бы понимали масштабы - они скупают около 40% от ВСЕГО мирового производства!

И если лето и осень мы прожили на старых запасах со складов, то теперь они закончились.

Подорожало все, даже древние DDR3.

DDR4 же теперь обойдется около 5000р за 8 гигов (старая цена 2200р)

DDR5 за 8 гигабайт будет ближе к 7600р. +. Причем, навороченные комплекты с радиаторами и подсветкой из старых запасов, будут по цене стандартных модулей

Ну а 16 гигов приличной памяти в DDR4 начнется от 9000р (старая цена около 3900р)

За 64 гигабайта одной планков в DDR5 ДНС просит колоссальные 47 000р!

На маркетплейсах цены аналогичные:

Спрос привел к огромному количеству пали. Если вам попался товар на 1000-1500р ниже средней цены, можете даже не надеяться - это не удача, а обычная подделка. Ну и ноунейм производителей появилось множество. Брать такое сомнительно, все на ваш страх и риск.

Короче говоря, все, что будет ещё только сделано в 2026 году уже продано: Samsung распродали память еще до того, как она даже вышла в продажу! Компания Micron продала всё вперед до 2026 года. Phison уже полностью расписала свои производственные мощности на следующий год, так что новые партии накопителей будут готовы только к 2027 году.
CМИ сообщают что некоторые каналы продаж теперь требуют от клиентов приобретать материнские платы вместе с модулями DRAM в соотношении один к одному, иначе они рискуют полностью лишиться возможности приобретения ОЗУ! Дошло до того, что из-за растущего дефицита производители ОЗУ пытаются выкупить свою же память у ритейлеров.

Так же есть проблема с тем, что память используется и в SSD.

Классика в 2.5" (чаще всего используется для апгрейда старых ПК и ноутов) с 3400р на 5000р

Вот такие дела...

Конечно нет, мы проходили наводнение в Тайланде в 2011 уничтожившее производство хардов,
скачки доллара, майнинговый дефицит видеокарт, корону, СВО, "уход брендов" и i5 по 50000р. (как это было можно вспомнить тут)

Так что не суетимся, отложим апгрейд памяти или покупку нового ПК на полгодика, ничего страшного не произойдет. В конечном итоге все всегда выравнивается. А пока еще можно успеть ухватить видики по вкусным ценам, для примера:

Бюджетный гейминг пока еще бюджетный: 5050 на 8 гигов можно отхватить вообще за 23 500р., минимальная карта для игр - 3050 RTX на 6 гигов обойдется в разумные 17000р. Самое время брать, ведь впереди:

Успеть закупиться нужно будет до начала августа. Потом все будет дороже.

*Цены могут меняться от региона и бренда, для примера брал самый среднестатистический и проверенный годами Kingston что бы не перегружать пост большим количеством картинок, общая ситуация понятна.

Спасибо всем, кто осилил дочитать до конца и подписался на разборы цен, телеги у меня нет и не планируется, всем выгодных покупок и приятного курса ;)

Пруфы 1 Пруфы 2 Про ЭДО

Виртуальные адреса незаметно для приложения сопоставляются с физической памятью за счёт совместной работы железа (MMU, Memory Management Unit) и софта (таблицы страниц, Page Tables). Информация об этих сопоставлениях ещё и кэшируется в самом железе — в TLB (Translation Lookaside Buffer), чтобы дальше быстро находить нужные физические адреса.

Страница — это просто группа подряд идущих линейных адресов в физической памяти. На x86 размер страницы — 4 КБ.

Абстракция виртуальной памяти даёт несколько плюсов:

• Программисту не нужно понимать архитектуру физической памяти на платформе. VM скрывает детали и позволяет писать код, не завязываясь на конкретное железо.

• Процесс всегда видит линейный непрерывный диапазон байт в своём адресном пространстве — даже если физическая память под ним фрагментирована.

Например: когда приложение просит 10 МБ памяти, ядро Linux просто резервирует 10 МБ непрерывного виртуального адресного диапазона. А вот физические страницы, куда этот диапазон будет отображён, могут лежать где угодно. Единственное, что гарантированно идёт подряд в физической памяти — это размер одной страницы (4 КБ).

• Быстрый старт из-за частичной загрузки. Demand paging подгружает инструкции только в момент, когда они реально понадобились.

• Общий доступ к памяти. Одна копия библиотеки или программы в физической памяти может быть отображена сразу в несколько процессов. Это экономит физическую память.

Команда pmap -X <pid> помогает посмотреть, какие области памяти процесса общие с другими, а какие — приватные.

• Несколько программ, потребляющих в сумме больше физической памяти, могут спокойно работать одновременно. Ядро втихаря выталкивает давно неиспользуемые страницы на диск (swap).

• Каждый процесс живёт в своём отдельном виртуальном адресном пространстве и не может вмешиваться в память других процессов.

Два процесса могут использовать одинаковые виртуальные адреса, но эти адреса будут отображены в разные места физической памяти. А вот процессы, которые подключаются к одному сегменту общей памяти (SHM), получат виртуальные адреса, указывающие на одни и те же физические страницы.

Виртуальное адресное пространство процесса состоит из сегментов разных типов: Text, Data, Heap, Stack, сегменты общей памяти (SHM) и области, созданные через mmap. Адресное пространство процесса — это диапазон виртуальных адресов, который ядро «выдаёт» процессу как его среду исполнения.

Каждый сегмент — это линейный диапазон виртуальных адресов с началом и концом, за которым стоит какой-то источник данных (backing store): файловая система или swap.

Ошибка страницы обрабатывается так: ядро поднимает физическую страницу, заполняя её данными из backing store. Когда памяти начинает не хватать, данные из физических страниц, используемых как кеш, сбрасываются обратно в свой backing store. Сегмент Text у процесса опирается на исполняемый файл в файловой системе. А вот стек, куча, страницы COW (Copy-on-Write) и shared memory — это анонимные (Anon) страницы, их хранилище — swap (дисковый раздел или файл).

Если swap не сконфигурирован, анонимные страницы невозможно выгрузить — им просто некуда уходить. В итоге они оказываются «прибиты» к физической памяти, потому что перенести данные с этих страниц во время нехватки памяти некуда.

Когда процесс вызывает malloc() или sbrk(), ядро создаёт новый сегмент кучи в адресном пространстве процесса и резервирует диапазон виртуальных адресов, по которому он теперь может легально ходить. Любое обращение к адресу за пределами этих границ приведёт к segmentation fault — и процесс отправится в небытие. Выделение физической памяти при этом отложено: она будет выделена только когда процесс реально обратится к этим виртуальным адресам.

Пример: приложение сделает malloc() на 50 ГБ, но реально коснётся (то есть вызовет page fault) только 10 МБ. Тогда физической памяти уйдёт всего 10 МБ.

Посмотреть виртуальное/физическое потребление памяти можно через “ps”, “pidstat” или “top”. Столбец SIZE показывает размер виртуального сегмента, а RSS — объём выделенной физической памяти.

Физические страницы, которые используются для сегмента Text или для файлового кеша (page cache), можно освобождать быстро — данные всегда можно снова получить из backing store (файловой системы). А вот для освобождения анонимных страниц сначала нужно записать их содержимое в swap, и только потом страница может быть освобождена.

Политика выделения памяти в Linux

Выделение памяти процессам регулируется политикой распределения памяти в Linux. В системе есть три режима, и выбираются они с помощью настройки vm.overcommit_memory.

1.Эвристический overcommit (vm.overcommit_memory=0)

Это режим по умолчанию. Ядро позволяет процессам «переборщить» с запросами памяти в разумных пределах — как решат внутренние эвристики. Они учитывают свободную память, свободный swap, а также память, которую можно быстро освободить, ужав файловый кеш или slab-кеши ядра.

Плюсы: учёт довольно мягкий; полезно для программ, которые обычно запрашивают больше памяти, чем реально используют. Пока хватает свободной памяти или swap, процесс продолжает работать.

Минусы: ядро не резервирует за процессом физическую память заранее. Пока процесс не потрогает (не обратится к) каждую страницу, никакой гарантии выделения нет.

(знаю, что нынче сравнения в формате плюсы/минусы в статье приравниваются к генерации нейросети, но пока это всё еще лучший вариант описания, так что...)

2.Всегда overcommit (vm.overcommit_memory=1)

С этим режимом процесс может запросить сколько угодно памяти, и запрос всегда будет успешным.

Плюсы: никаких ограничений — можно делать огромные выделения, даже если физической памяти и swap мало.

Минусы: те же, что и в эвристическом режиме. Приложение может сделать malloc() на терабайты при наличии нескольких гигабайт RAM. Пока оно не тронет все страницы, проблем нет — но как только тронет, может включиться OOM Killer.

3.Строгий overcommit (vm.overcommit_memory=2)

В этом режиме ядро запрещает overcommit и резервирует не только виртуальный диапазон, но и физическую память. Нет overcommit — нет и OOM Killer.

При Strict Overcommit ядро отслеживает, сколько физической памяти уже зарезервировано или закоммичено.

Поскольку Strict Overcommit не учитывает свободную память или swap, ориентироваться на free или vmstat бессмысленно. Чтобы понять, сколько памяти можно ещё выделить, смотрят в /proc/meminfo на поля CommitLimit и Committed_AS.

Текущую границу выделения считают так: CommitLimit − Committed_AS.

Настройка vm.overcommit_ratio задаёт предел overcommit’а для этого режима. Предел считается так: PhysicalMemory × overcommit_ratio + swap.

Значение можно поднять, увеличив vm.overcommit_ratio (по умолчанию — 50% от RAM).

Плюсы: OOM Killer не сработает. Лучше, чтобы приложение упало сразу при старте, чем посреди боевой нагрузки от OOM Killer. Solaris работает только так. Strict overcommit не использует free memory/swap для расчёта лимита.

Минусы: overcommit отсутствует полностью. Зарезервированная, но не используемая память простаивает — другие приложения её потрогать не могут. Новый процесс может не получить память, даже если система показывает много свободной RAM — потому что она уже «обещана» другим процессам.

Мониторинг свободной памяти становится хитрее. Многие приложения под Linux не умеют корректно обрабатывать ошибки выделения памяти — это может привести к повреждению данных и странным, трудно отлавливаемым сбоям.

Примечание: и в эвристическом, и в строгом режиме ядро резервирует часть памяти для root. В эвристике — 1/32 от свободной RAM. В строгом — 1/32 от процента реальной памяти, который вы задали. Это зашито в ядро и не настраивается. Например, на системе с 64 ГБ будет зарезервировано 2 ГБ для root.

OOM Killer

Когда система упирается в жёсткую нехватку памяти — файловый кеш уже ужат до минимума, все возможные страницы возвращены — но спрос на память не падает, рано или поздно заканчивается всё, что можно выделить. Чтобы не оставить систему полностью без возможности работать, ядро начинает выбирать процессы, которые можно убить, чтобы освободить память. Этот крайний шаг и называется OOM Killer.

Критерии выбора «жертвы» иногда приводят к тому, что убивается самый важный процесс. Есть несколько способов снизить риски:

• Выключить OOM Killer, переключив систему на строгий overcommit:

sudo sysctl vm.overcommit_memory=2 sudo sysctl vm.overcommit_ratio=80

• Исключить критический процесс из рассмотрения OOM Killer. Но даже это иногда не спасает: ядру всё равно нужно кого-то убить, чтобы освободить память. В некоторых ситуациях остаётся только автоматическая перезагрузка, чтобы восстановить работу системы.

sudo sysctl vm.panic_on_oom=1 sudo sysctl kernel.panic="number_of_seconds_to_wait_before_reboot"

Преимущества файлового кеша

Linux использует свободную память, которую сейчас не заняли приложения, для кеширования страниц и блоков файловой системы.

Память, занятую файловым кешем, Linux считает свободной — она доступна приложениям, как только им понадобится. Утилита free показывает эту память как свободную.

Наличие файлового кеша заметно ускоряет работу приложений с диском:

• Чтение: когда приложение читает данные из файла, ядро делает физический IO и подтягивает блоки с диска. Прочитанные данные помещаются в файловый кеш, чтобы в следующий раз не ходить на диск. Повторное чтение того же блока — это уже логический IO (чтение из кеша), что резко снижает задержки. Кроме того, файловые системы выполняют упреждающее чтение (read-ahead): если замечают последовательный доступ, подгружают соседние блоки заранее, предполагая, что приложению они скоро понадобятся.

• Запись: когда приложение пишет данные в файл, ядро кладёт их в page cache и сразу подтверждает запись (buffered write). Данные в кеше могут многократно обновляться (write cancelling), прежде чем ядро решит, что пора сбросить грязные страницы на диск.

Грязные страницы файлового кеша сбрасываются потоками flusher (раньше звали pdflush). Сброс происходит периодически, когда доля грязных буферов превышает пороговое значение — оно регулируется параметрами виртуальной памяти.

Файловый кеш улучшает производительность IO, скрывая задержки хранилища.

Преимущества HugeTLB и HugePages

Функция HugeTLB в Linux позволяет приложениям использовать большие страницы — 2 МБ или 1 ГБ вместо стандартных 4 КБ. TLB (Translation Lookaside Buffer) — это аппаратный кеш, который хранит отображения «виртуальный → физический» адрес. Когда нужной записи там нет (TLB miss), приходится идти в таблицы страниц в памяти, а это дорогая операция.

TLB-хиты становятся всё важнее из-за растущего разрыва между скорости CPU и памяти, а также из-за увеличения объёмов памяти. Частые TLB miss могут ощутимо просадить производительность.

TLB — ограниченный ресурс на чипе, и ядро Linux старается использовать его максимально эффективно. Каждый элемент TLB может быть настроен на работу со страницами разных размеров: 4 КБ, 2 МБ или 1 ГБ.

Если те же слоты TLB использовать под страницы покрупнее, можно покрывать куда большие области физической памяти:

• 4 KB pages: 64×4 KB + 1024×4 KB ≈ 4 MB

• 2 MB pages: 32×2 MB + 1024×2 MB ≈ 2 GB

• 1 GB pages: 4 GB

Плюсы:

• Большие страницы уменьшают количество TLB miss, потому что один TLB-слот покрывает больше адресного пространства.

• Требуется меньше записей в таблицах страниц, и уровней таблиц меньше. Это сокращает задержки на обход таблиц (2 уровня вместо 4) и уменьшает память, расходуемую на сами таблицы.

• Large Pages фиксируются в памяти и не участвуют в выгрузке при нехватке RAM.

• Снижается частота page fault: один fault может заполнить сразу 2 МБ или 1 ГБ, а не жалкие 4 КБ. Приложение «прогревается» заметно быстрее.

• Если у приложения есть локальность данных, HugeTLB даст выигрыш. Но если оно читает байт там, байт здесь, или прыгает по огромной хеш-таблице, то обычные 4 КБ-страницы могут быть выгоднее.

• Улучшается работа механизма prefetch: крупные страницы устраняют необходимость перезапуска чтения на границах 4K.

Минусы:

• Большие страницы требуют предварительного резервирования. Администратор должен заранее выставить количество страниц: vm.nr_hugepages=<число>

(У Transparent Huge Pages предварительного шага нет.)

• Приложение должно уметь работать с HugePages.

Например, JVM нужно запускать с флагом -XX:+UseLargePages, иначе большие страницы просто лежат без дела.

Посмотреть использование: cat /proc/meminfo | grep -E 'HugePages_|Hugepagesize'

• Для HugePages нужны непрерывные физические участки памяти — 2 МБ или 1 ГБ. На системе, которая работает долго, большая часть RAM может быть уже разрезана на 4К страницы, и запрос на HugePage будет просто нечем удовлетворить.