Выделено памяти под 8кб кэш
Обновлено: 05.07.2024
Это нормально, что ОС кэширует данные в оперативку. Она всегда может её очистить если не будет хватать для игры и т.д. Как правильно заметили лучше проверить диск.
Я тоже так думал, но тут как-то проскакивало видео, показывающее что есть статтеры в играх при заполненной памяти. Как я понимаю, очистка кэша не мгновенная операция, и если в обычных приложениях это не заметно, то в играх - очень даже. Плюс ОС чистит только необходимое количество памяти, поэтому при следующем запросе снова будет задержка.
.
ЗЫ. В линуксе, кстати, ситуация не лучше - в реалтаймовых приложениях, вроде телефонии, начинается полный пиздец, если вся память ушла под кэш.
Если бы была причина в заполнении памяти, то проблема была бы у 95% геймеров. Какой смысл иметь 16+ гб оперативки, если в неё не кэшировать инфу для ускорения работы. Скорость очистки кэша никак не влияет на игры.
Куда больше вероятность, что проблема связана с HDD где стоят игры.
Скорость очистки кэша никак не влияет на игры.
Освобождение системной памяти не самая дешёвая операция. И в играх, когда время кадра измеряется миллисекундами, это вызывает ощутимую задержку. Посмотрите видео, там всё весьма наглядно показано (единственное что, я бы не стал ставить автоматическую очистку).
(единственное что, я бы не стал ставить автоматическую очистку)
Почему? В видосе гайд именно на авто отчистку.
Очистка кэша нужна только в играх. В остальное время от неё только вред будет.
Комментарий удален по просьбе пользователя
очистка кеша помогла улучшить ситуацию в батле. Но не полностью
Хотя не, не помогло
Комментарий удален по просьбе пользователя
Ага, а мои тапки умнее Гейтса. Хватит тупо обожествлять багованную систему, написанную индусами. Если ты интересовался этой проблемой, то знал бы что в сети полно гайдов решающих проблему статтеров через очистку ОЗУ от кэша.
Комментарий удален по просьбе пользователя
Он отчасти прав, отчасти нет.
Есть некоторые тайтлы, которые зажирают всю оперативу к хренам и не дают её выгружать -> получаем статтеры. Отсюда всякие очистители получили популярность
Комментарий удален по просьбе пользователя ред.
В ac: origins с последним патчем такая проблема. И решилась она установкой в планировщике задач очистки памяти раз в 5 минут. Решение этой проблемы я нашел на руоверах в шапке темы процессоров на сокет ам4. И это помогло. После этого я этой проблемы не встречал.
Проблемы с кэшем в любой операционке, на расчитанной на реалтайм.
в чем тогда может быть проблема стетров?
В одном видео утверждается что очистка кэша помогает со статерами и фризами
Комп новый, хз в чем дело
Игра стоит на ССД, частота ОЗУ 3200
Комментарий удален по просьбе пользователя
Процессор Intel Core i7-10700F OEM
Материнская плата MSI Z490-A PRO
Видеокарта MSI GeForce RTX 2080 Ti VENTUS GP
Блок питания Cougar GX 800W
Оперативная память A-Data XPG SPECTRIX D41 RGB 32 ГБ
1000 ГБ SSD M.2 накопитель A-Data XPG SX8200 Pro
Кулер для процессора Arctic Cooling Freezer 34 eSports
Корпус DEEPCOOL MATREXX 55 MESH ADD-RGB 4F
Проц не тротлится в стресс-тестах
Статеры в сингле даже больше, чем в онлайне
Комментарий удален по просьбе пользователя
да куда там 4к, на 1080p играю
Комментарий удален по просьбе пользователя
в стресс тестах аиды везде температуры нормальные были
Комментарий удален по просьбе пользователя
стоит, темпы ГП и ЦП в норме
Комментарий удален по просьбе пользователя ред.
Комментарий удален по просьбе пользователя ред.
В мафии. Там такой явной проблемы нет
Комментарий удален по просьбе пользователя ред.
Фризит даже первая батла без лучей которая
Комментарий удален по просьбе пользователя
Отключение игрового режима Винды улучшило ситуацию. По крайней мере на одной карте
Комментарий удален по просьбе пользователя ред.
да и так летает. Только со статерами проблема
Комментарий удален по просьбе пользователя
качаю метро и рдр2, на них чекну
Комментарий удален по просьбе пользователя
в метро тоже статтеры есть. Например в самом начале игры есть статтер заметный когда опускается камера, а второй когда Артем спускается в метро и открывает первую дверь слева.
И они оба были и при сбросе кеша и при отключении режима игры Винды
Т. Е в одних и тех же местах
Комментарий удален по просьбе пользователя
крч глянул бенчмарки метро. И у других эти 2 фриза в аналогичном месте.
Видимо не так уж она хороша оптимизирована
Комментарий удален по просьбе пользователя
Вполне нормально, чем больше памяти, тем больше ее использует система.
А ты хочешь, чтобы она для красоты просто так пустая стояла?
Ты что! Иначе как же понтоваться 500-700 метрами в лине?) Ведь так круто, когда из 32 кубоа ось юзает нисколько)))
И не одного дельного совета, я в шоке от народа :)
Держи, кэшированную память нужно чистить, там в видео будет программка. Фризы из-за этого и есть в той же батле и колде.
Просто винда берет и тупо сжирает в кэш весь свободный ОЗУ, а кэш находится в лучшем случае на ССД, а худшем - жестком диске, который в сотни раз медленнее ОЗУ, поэтому и случаются фризы, поскольку игра запрашивает свободные ячейки памяти, а берутся они не из быстрой ОЗУ, а с кэша.
Ты же вообще не понимаешь, о чём пишешь, да?
Только решение проблемы озвученной в видео - реально работает. И проверено на практике.
Но вам лишь бы поплявузгать.
Комментарий удален по просьбе пользователя ред.
У меня 16 гб очень быстрой ддр4 в двухканале. Жаловаться мне не на что, кроме дебильной работы виндовс с озу, в результате чего пришлось делать этот костыль.
Комментарий удален по просьбе пользователя
Тупая шутка учитывая, что моя система собрана на ам4 для игр. Осталось пошутить что я сижу на резиновом члене - и дно будет нащупано.
Комментарий удален по просьбе пользователя
Только практика показала обратное. А то как их идеальные обновы сбивают настройки в системе - отдельная песня. Так что говорить о какой либо идеальности системы - моветон.
Комментарий удален по просьбе пользователя
Сейчас бы по мнению одного юзера делать статистику.
Некоторые средневековые методы лечения тоже вполне работали без понимания причин болезни. Но впоследствии былли вытеснены более эффективными, когда началось понимание. Так что так себе аргумент.
Это ты не понимаешь, в чем суть проблемы, да?
Ну что ж.
1) Открой Resource Monitor
2) Посмотри на размер Cached-данных
3) Открой расположение файла pagefile.sys и swapfile.sys
4) Сравни размер этих файлов и размер кэшированных данных.
5) Пойми, что это вообще не связанные параметры и Cached категорически не то же самое, что
винда берет и тупо сжирает в кэш весь свободный ОЗУ, а кэш находится в лучшем случае на ССД, а худшем - жестком диске, который в сотни раз медленнее ОЗУ
потому что это несвязный бред человека, который вообще не понимает, что такое кэширование в общем случае и путает его со свопом.
А ещё у меня, например, свободной RAM отображается вообще меньше 50 мегабайт, но ни к каким фризам и статтерам это не приводит. Потому что надо вначале понимать, как работает управление памятью в ОС, а уже потом пытаться что-то утверждать по этой теме. ред.
С проблемой переполненной памяти сталкиваются многие владельцы устройств на платформе Android.
Вроде пользовательских файлов сохранено немного, но накопитель все равно забит. Причин такой проблемы существует несколько — рассмотрите каждую из них.
Очистка кэша телефона
Первым делом, нужно почистить кэш на Android-смартфоне. Существует несколько способов чистки. Начнем с базовых настроек:
Также кэш-память на Android чистится через специальные приложения (которые в последнее время сильно испортились). Вот способ очистки на примере утилиты CCleaner (программа доступна в Google Play). После ее установки выполните следующий алгоритм действий:
Если остались вопросы, обязательно изучите более подробную статью об очистке кэша. Отметим, что один из самых действенных методов очистки кэш-памяти — раздел Wipe cache partition в меню Recovery.
Очистка ненужных файлов
Большие объемы нежелательных данных чаще всего скапливаются в папках загрузки или мессенджеров, а также в скрытой директиве .thumbnails. Рекомендуем провести тщательный анализ файловой системы. Для этой операции подойдет анализотор дисков DiskUsage, который также загружается из Google Play.
Удаления файлов из скрытой папки .thumbnails
Директива .thumbnails находится в папке DCIM — в галерее, где хранятся фотографии и видеоролики. В .thumbnails сохраняются эскизы медиафайлов, чтобы в дальнейшем смартфон мог быстрее подгружать плитки-миниатюры. Со временем накапливается несколько гигабайт эскизов, особенно если владелец устройства любитель делать снимки или снимать видео.
Например, на одном из смартфонов редакции хранится 500 фотографий. Размер папки с миниатюрами .thumbnails составляет 1 ГБ. Это пространство можно легко освободить.
Так как директива .thumbnails по умолчанию скрыта, через галерею зайти в нее не получится. Для диагностики и удаления эскизов рекомендуется скачать приложение Total Comander. Далее нужно выполнить следующие действия:
Единственный недостаток в такой операции — теперь миниатюры будут подгружаться чуть медленнее. После очистки папки .thumbnails устройство снова начнет создавать новые эскизы. Чтобы это предотвратить, потребуется блокировка создание эскизов.
Как заблокировать создание эскизов?
Чтобы не удалять содержание папки .thumbnails постоянно, выполните следующие действия:
- Удалите папку .thumbnails и подключите смартфон к ПК.
- На компьютере создайте пустой текстовый файл и укажите для него имя .thumbnails (убедитесь, что название папки прописано точно).
- Далее этот файл переносится на телефон в папку DCIM.
Теперь сохранение эскизов прекратится, так как система не сможет создать новую директиву .thumbnails, поскольку в гаджете уже существует папка с аналогичным названием. Если по какой-то причине этот метод не сработал, проделайте те же действия, но вместо .thumbnails, укажите пустому текстовому файлу имя .nomedia.
Карта памяти
Еще важно правильно выбрать карту памяти — учесть класс и скорость, а также другие характеристики. Чтобы не возникло накладок, внимательно изучите наши статьи.
Нужно отметить, что в смартфонах на свежих версиях Android есть возможность объединения внутреннее хранилище с картой памяти. В таких случаях смартфон сам предложит произвести соединение после установки карты.
Сброс настроек
Самым радикальным методом решения всех системных проблем является полное форматирование или сброс гаджета до заводских настроек. Этот метод рекомендуется использовать в случаях, когда простые способы решения проблемы не принесли желаемого результата.
Для возвращения смартфона к заводским настройкам выполните следующие действия:
Итоги
Проблемы с памятью бывают разными, как и их решения. Начните диагностику системы с выполнения самых простых действий и удаления ненужных игр, приложений, фотографий, видео и других файлов. Не забудьте добавить карту памяти, очистить кэш и папку .thumbnails. Если это не поможет, пробуйте более радикальные меры.
Можно увидеть, что кэшировано много оперативной памяти в диспетчере задач Windows 10. Пользователям не совсем понятно что это за память. И как большое её количество может повлиять на производительность. Думаю понятно, чем больше ОЗУ тем меньше проблем.
Эта статья расскажет, что такое кэшированная память и почему её очень много в Windows 10. Во время эксперимента файл подкачки был отключён на всех дисках. Многие процессы, службы, библиотеки и программы, при включении компьютера, уже попадают в оперативную память.
Что значит кэшировано памяти
Этот объём памяти (включает зарезервированную и изменённую память), в которой содержаться кэшированные данные и код, предназначены для мгновенного доступа и использования процессами, драйверами и операционной системой.
Например, в диспетчере задач показывает кэшировано 6.0 Гб. В строке Структура памяти смотрим Зарезервировано (5832 Мб). Это и есть память, содержащая кэшированные данные и код, которые прямо сейчас не используются.
В первую очередь система использует свободную память. При нехватке памяти, кэшированная будет переводиться в свободную. Размер кэша уменьшается и менее нужные (давно используемые) данные очищаются.
Монитор ресурсов имеет более подробное описание. Это зарезервированная память, в которой содержаться кэшированные данные, и которая недоступна для использования. При необходимости память освобождается.
Важно! Операционная система установлена на твердотельный SSD накопитель. Сразу исключаем версии с использованием виртуальной памяти Windows 10. Файл подкачки полностью отключён на всех дисках. И все нужные данные кэшируются непосредственно в ОЗУ.
Как очистить кэшированную оперативную память
Удалите неиспользуемые приложения
Все неиспользуемые приложения, особенно те, которые добавляются в автозагрузку, попадают в память. В системе множество программ, которые пользователи не используют, кэшируются, занимают ОЗУ. Вспомните только не убираемую автозагрузку uTorrent в Windows 10.
Запретите использование данных для открытия приложений после перезапуска или обновления. В новой версии параметр назыв. Автоматически сохранять мои перезапускаемые приложения при выходе из системы и перезапускать их после входа.
Много писали о тонкой настройке автозапуска программ Windows 10. Перейдите в расположение Параметры > Приложения > Автозагрузка. И выключите запуск всех ненужных программ перетягиванием ползунков.
Отключение ненужных служб
В системе с каждым обновлением становиться всё больше и больше служб. Хотя для обычного пользователя далеко не все они нужны. Смотрите, как отключить на примере службы криптографии. Более подробно: оптимизация и ускорение Windows 10 для слабых ноутбуков.
Откройте управление службами выполнив команду services.msc в окне Win+R. Теперь достаточно изменить тип запуска ненужной службы на Отключено. Внимательно читайте описание службы, которую Вы отключаете и смотрите её зависимости.
Очистка оперативной памяти
Самый простой способ очистки оперативной памяти — это перезагрузка компьютера. Все данные, которые кэшируются непосредственно в ОЗУ будут очищены. Включение компьютера повторно покажет ситуацию с количеством занятой памяти.
Можно воспользоваться различным софтом для очистки оперативной памяти. В ближайшем будущем такая функциональность будет непосредственно в ОС. Смотрите подробней: как очистить оперативную память на Windows 10.
Во всех центральных процессорах любого компьютера, будь то дешёвый ноутбук или сервер за миллионы долларов, есть устройство под названием «кэш». И с очень большой вероятностью он обладает несколькими уровнями.
Наверно, он важен, иначе зачем бы его устанавливать? Но что же делает кэш, и для чего ему разные уровни? И что означает «12-канальный ассоциативный кэш» (12-way set associative)?
Что такое кэш?
TL;DR: это небольшая, но очень быстрая память, расположенная в непосредственной близости от логических блоков центрального процессора.
Однако мы, разумеется, можем узнать о кэше гораздо больше…
Давайте начнём с воображаемой волшебной системы хранения: она бесконечно быстра, может одновременно обрабатывать бесконечное количество операций передачи данных и всегда обеспечивает надёжное и безопасное хранение данных. Конечно же, ничего подобного и близко не существует, однако если бы это было так, то структура процессора была бы гораздо проще.
Процессорам бы тогда требовались только логические блоки для сложения, умножения и т.п, а также система управления передачей данных, ведь наша теоретическая система хранения способна мгновенно передавать и получать все необходимые числа; ни одному из логических блоков не приходится простаивать в ожидании передачи данных.
Но, как мы знаем, такой волшебной технологии хранения не существует. Вместо неё у нас есть жёсткие диски или твердотельные накопители, и даже самые лучшие из них далеки от возможностей обработки, необходимых для современного процессора.
Великий Т'Фон хранения данных
Причина этого заключается в том, что современные процессоры невероятно быстры — им требуется всего один тактовый цикл для сложения двух 64-битных целочисленных значений; если процессор работает с частотой 4 ГГЦ, то это составляет всего 0,00000000025 секунды, или четверть наносекунды.
В то же время, вращающемуся жёсткому диску требуются тысячи наносекунд только для нахождения данных на дисках, не говоря уже об их передаче, а твердотельным накопителям — десятки или сотни наносекунд.
Очевидно, что такие приводы невозможно встроить внутрь процессоров, поэтому между ними будет присутствовать физическое разделение. Поэтому ещё добавляется время на перемещение данных, что усугубляет ситуацию.
Увы, но это Великий А'Туин хранения данных
Именно поэтому нам нужна ещё одна система хранения данных, расположенная между процессором и основным накопителем. Она должна быть быстрее накопителя, способна одновременно управлять множеством операций передачи данных и находиться намного ближе к процессору.
Ну, у нас уже есть такая система, и она называется ОЗУ (RAM); она присутствует в каждом компьютере и выполняет именно эту задачу.
Почти все такие хранилища имеют тип DRAM (dynamic random access memory); они способны передавать данные гораздо быстрее, чем любой накопитель.
Однако, несмотря на свою огромную скорость, DRAM не способна хранить такие объёмы данных.
Одни из самых крупных чипов памяти DDR4, разработанных Micron, хранят 32 Гбит, или 4 ГБ данных; самые крупные жёсткие диски хранят в 4 000 раз больше.
Итак, хоть мы и повысили скорость нашей сети данных, нам потребуются дополнительные системы (аппаратные и программные), чтобы разобраться, какие данные должны храниться в ограниченном объёме DRAM, готовые к обработке процессором.
DRAM могут изготавливаться в корпусе чипа (это называется встроенной (embedded) DRAM). Однако процессоры довольно малы, поэтому в них не удастся поместить много памяти.
10 МБ DRAM слева от графического процессора Xbox 360. Источник: CPU Grave Yard
Подавляющее большинство DRAM расположено в непосредственной близости от процессора, подключено к материнской плате и всегда является самым близким к процессору компонентом. Тем не менее, эта память всё равно недостаточно быстра…
DRAM требуется примерно 100 наносекунд для нахождения данных, но, по крайней мере, она способна передавать миллиарды битов в секунду. Похоже, нам нужна ещё одна ступень памяти, которую можно разместить между блоками процессора и DRAM.
На сцене появляется оставшаяся ступень: SRAM (static random access memory). DRAM использует микроскопические конденсаторы для хранения данных в виде электрического заряда, а SRAM для той же задачи применяет транзисторы, которые работают с той же скоростью, что и логические блоки процессора (примерно в 10 раз быстрее, чем DRAM).
Разумеется, у SRAM есть недостаток, и он опять-таки связан с пространством.
Память на основе транзисторов занимает гораздо больше места, чем DRAM: в том же размере, что чип DDR4 на 4 ГБ, можно получить меньше 100 МБ SRAM. Но поскольку она производится по тому же технологическому процессу, что и CPU, память SRAM можно встроить прямо внутрь процессора, максимально близко к логическим блокам.
С каждой дополнительной ступенью мы увеличивали скорость перемещаемых данных ценой хранимого объёма. Мы можем продолжить и добавлять новые ступени,, которые будут быстрее, но меньше.
И так мы добрались до более строгого определения понятия кэша: это набор блоков SRAM, расположенных внутри процессора; они обеспечивают максимальную занятость процессора благодаря передаче и сохранению данных с очень высокими скоростями. Вас устраивает такое определение? Отлично, потому что дальше всё будет намного сложнее!
Кэш: многоуровневая парковка
На приведённом выше изображении процессор (CPU) обозначен прямоугольником с пунктирной границей. Слева расположены ALU (arithmetic logic units, арифметико-логические устройства); это структуры, выполняющие математические операции. Хотя строго говоря, они не являются кэшем, ближайший к ALU уровень памяти — это регистры (они упорядочены в регистровый файл).
Каждый из них хранит одно число, например, 64-битное целое число; само значение может быть элементом каких-нибудь данных, кодом определённой инструкции или адресом памяти каких-то других данных.
Регистровый файл в десктопных процессорах довольно мал, например, в каждом из ядер Intel Core i9-9900K есть по два банка таких файлов, а тот, который предназначен для целых чисел, содержит всего 180 64-битных целых чисел. Другой регистровый файл для векторов (небольших массивов чисел) содержит 168 256-битных элементов. То есть общий регистровый файл каждого ядра чуть меньше 7 КБ. Для сравнения: регистровый файл потоковых мультипроцессоров (так в GPU называются аналоги ядер CPU) Nvidia GeForce RTX 2080 Ti имеет размер 256 КБ.
Регистры, как и кэш, являются SRAM, но их скорость не превышает скорость обслуживаемых ими ALU; они передают данные за один тактовый цикл. Но они не предназначены для хранения больших объёмов данных (только одного элемента), поэтому рядом с ними всегда есть более крупные блоки памяти: это кэш первого уровня (Level 1).
Одно ядро процессора Intel Skylake. Источник: Wikichip
На изображении выше представлен увеличенный снимок одного из ядер десктопного процессора Intel Skylake.
ALU и регистровые файлы расположены слева и обведены зелёной рамкой. В верхней части фотографии белым обозначен кэш данных первого уровня (Level 1 Data cache). Он не содержит много информации, всего 32 КБ, но как и регистры, он расположен очень близко к логическим блокам и работает на одной скорости с ними.
Ещё одним белым прямоугольником справа показан кэш инструкций первого уровня (Level 1 Instruction cache), тоже имеющий размер 32 КБ. Как понятно из названия, в нём хранятся различные команды, готовые к разбиению на более мелкие микрооперации (обычно обозначаемые μops), которые должны выполнять ALU. Для них тоже существует кэш, который можно классифицировать как Level 0, потому что он меньше (содержит всего 1 500 операций) и ближе, чем кэши L1.
Вы можете задаться вопросом: почему эти блоки SRAM настолько малы? Почему они не имеют размер в мегабайт? Вместе кэши данных и инструкций занимают почти такую же площадь на чипе, что основные логические блоки, поэтому их увеличение приведёт к повышению общей площади кристалла.
Но основная причина их размера в несколько килобайт заключается в том, что при увеличении ёмкости памяти повышается время, необходимое для поиска и получения данных. Кэшу L1 нужно быть очень быстрым, поэтому необходимо достичь компромисса между размером и скоростью — в лучшем случае для получения данных из этого кэша требуется около 5 тактовых циклов (для значений с плавающей запятой больше).
Кэш L2 процессора Skylake: 256 КБ SRAM
Но если бы это был единственный кэш внутри процессора, то его производительность наткнулась бы на неожиданное препятствие. Именно поэтому в ядра встраивается еще один уровень памяти: кэш Level 2. Это обобщённый блок хранения, содержащий инструкции и данные.
Он всегда больше, чем Level 1: в процессорах AMD Zen 2 он занимает до 512 КБ, чтобы кэши нижнего уровня обеспечивались достаточным объёмом данных. Однако большой размер требует жертв — для поиска и передачи данных из этого кэша требуется примерно в два раза больше времени по сравнению с Level 1.
Во времена первого Intel Pentium кэш Level 2 был отдельным чипом, или устанавливаемым на отдельной небольшой плате (как ОЗУ DIMM), или встроенным в основную материнскую плату. Постепенно он перебрался в корпус самого процессора, и, наконец, полностью интегрировался в кристалл чипа; это произошло в эпоху таких процессоров, как Pentium III и AMD K6-III.
За этим достижением вскоре последовал ещё один уровень кэша, необходимый для поддержки более низких уровней, и появился он как раз вовремя — в эпоху расцвета многоядерных чипов.
Чип Intel Kaby Lake. Источник: Wikichip
На этом изображении чипа Intel Kaby Lake в левой части показаны четыре ядра (интегрированный GPU занимает почти половину кристалла и находится справа). Каждое ядро имеет свой «личный» набор кэшей Level 1 и 2 (выделены белыми и жёлтым прямоугольниками), но у них также есть и третий комплект блоков SRAM.
Кэш третьего уровня (Level 3), хоть и расположен непосредственно рядом с одним ядром, является полностью общим для всех остальных — каждое ядро свободно может получать доступ к содержимому кэша L3 другого ядра. Он намного больше (от 2 до 32 МБ), но и намного медленнее, в среднем более 30 циклов, особенно когда ядру нужно использовать данные, находящиеся в блоке кэша, расположенного на большом расстоянии.
Ниже показано одно ядро архитектуры AMD Zen 2: кэши Level 1 данных и инструкций по 32 КБ (в белых прямоугольниках), кэш Level 2 на 512 КБ (в жёлтых прямоугольниках) и огромный блок кэша L3 на 4 МБ (в красном прямоугольнике).
Увеличенный снимок одного ядра процессора AMD Zen 2. Источник: Fritzchens Fritz
Но постойте: как 32 КБ могут занимать больше физического пространства чем 512 КБ? Если Level 1 хранит так мало данных, почему он непропорционально велик по сравнению с кэшами L2 и L3?
Не только числа
Кэш повышает производительность, ускоряя передачу данных в логические блоки и храня поблизости копию часто используемых инструкций и данных. Хранящаяся в кэше информация разделена на две части: сами данные и место, где они изначально располагаются в системной памяти/накопителе — такой адрес называется тег кэша (cache tag).
Когда процессор выполняет операцию, которой нужно считать или записать данные из/в память, то он начинает с проверки тегов в кэше Level 1. Если нужные данные там есть (произошло кэш-попадание (cache hit)), то доступ к этим данным выполняется почти сразу же. Промах кэша (cache miss) возникает, если требуемый тег не найден на самом нижнем уровне кэша.
В кэше L1 создаётся новый тег, а за дело берётся остальная часть архитектуры процессора выполняющая поиск в других уровнях кэша (при необходимости вплоть до основного накопителя) данных для этого тега. Но чтобы освободить пространство в кэше L1 под этот новый тег, что-то обязательно нужно перебросить в L2.
Это приводит к почти постоянному перемешиванию данных, выполняемому всего за несколько тактовых циклов. Единственный способ добиться этого — создание сложной структуры вокруг SRAM для обработки управления данными. Иными словами, если бы ядро процессора состояло всего из одного ALU, то кэш L1 был бы гораздо проще, но поскольку их десятки (и многие из них жонглируют двумя потоками инструкций), то для перемещения данных кэшу требуется множество соединений.
Для изучения информации кэша в процессоре вашего компьютера можно использовать бесплатные программы, например CPU-Z. Но что означает вся эта информация? Важным элементом является метка set associative (множественно-ассоциативный) — она указывает на правила, применяемые для копирования блоков данных из системной памяти в кэш.
Представленная выше информация кэша относится к Intel Core i7-9700K. Каждый из его кэшей Level 1 разделён на 64 небольших блока, называемые sets, и каждый из этих блоков ещё разбит на строки кэша (cache lines) (размером 64 байта). «Set associative» означает, что блок данных из системы привязывается к строкам кэша в одном конкретном сете, и не может свободно привязываться к какому-то другому месту.
Инклюзивный кэш L1+L2, victim cache L3, политики write-back, есть даже ECC. Источник: Fritzchens Fritz
Ещё один аспект сложности кэша связан с тем, как хранятся данные между разными уровнями. Правила задаются в inclusion policy (политике инклюзивности). Например, процессоры Intel Core имеют полностью инклюзивные кэши L1+L3. Это означает, что одни данные в Level 1, например, могут присутствовать в Level 3. Может показаться, что это пустая трата ценного пространства кэша, однако преимущество заключается в том, что если процессор совершает промах при поиске тега в нижнем уровне, ему не потребуется обыскивать верхний уровень для нахождения данных.
В тех же самых процессорах кэш L2 неинклюзивен: все хранящиеся там данные не копируются ни на какой другой уровень. Это экономит место, но приводит к тому, что системе памяти чипа нужно искать ненайденный тег в L3 (который всегда намного больше). Victim caches (кэши-жертвы) имеют похожий принцип, но они используются для хранения информации, переносимой с более низких уровней. Например, процессоры AMD Zen 2 используют victim cache L3, который просто хранит данные из L2.
Существуют и другие политики для кэша, например, при которых данные записываются и в кэш, и основную системную память. Они называются политиками записи (write policies); большинство современных процессоров использует кэши write-back — это означает, что когда данные записываются на уровень кэшей, происходит задержка перед записью их копии в системную память. Чаще всего эта пауза длится в течение того времени, пока данные остаются в кэше — ОЗУ получает эту информацию только при «выталкивании» из кэша.
Графический процессор Nvidia GA100, имеющий 20 МБ кэша L1 и 40 МБ кэша L2
Для проектировщиков процессоров выбор объёма, типа и политики кэшей является вопросом уравновешивания стремления к повышению мощности процессора с увеличением его сложности и занимаемым чипом пространством. Если бы можно было создать 1000-канальные ассоциативные кэши Level 1 на 20 МБ такими, чтобы они при этом не занимали площадь Манхэттена (и не потребляли столько же энергии), то у нас у всех бы были компьютеры с такими чипами!
Самый нижний уровень кэшей в современных процессорах за последнее десятилетие практически не изменился. Однако кэш Level 3 продолжает расти в размерах. Если бы десять лет назад у вас было 999 долларов на Intel i7-980X, то вы могли бы получить кэш размером 12 МБ. Сегодня за половину этой суммы можно приобрести 64 МБ.
Подведём итог: кэш — это абсолютно необходимое и потрясающее устройство. Мы не рассматривали другие типы кэшей в CPU и GPU (например, буферы ассоциативной трансляции или кэши текстур), но поскольку все они имеют такую же простую структуру и расположение уровней, разобраться в них будет несложно.
Был ли у вас компьютер с кэшем L2 на материнской плате? Как насчёт слотовых Pentium II и Celeron (например, 300a) на дочерних платах? Помните свой первый процессор с общим L3?
На правах рекламы
Наша компания предлагает в аренду серверы с процессорами от Intel и AMD. В последнем случае — это эпичные серверы! VDS с AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.
Заметил, что пока я был на работе, oom_killer прикончил Firefox на фоне общей нехватки памяти. Картина примерно следующая:
Остановил приложения с активным I/O, сделал sync && echo 3 > /proc/sys/vm/drop_caches , кеши почти не уменьшились, тормоза UI заметны на глаз. Вопрос, в общем-то, очевиден: кто виноват и что делать?Возможно, эти данные чем-то помогут:
- /proc/vmstat
- /proc/meminfo
- /proc/sys/fs/dentry-state
- Debian Stable (linux-image-3.13-0.bpo.1-amd64 из бэкпортов)
- Аптайм 20 дней, постоянная I/O активность около 10МБ/сек на чтение
- Выдержка из dmesg о работе oom_killer-a
Я думаю, что проще всего будет добавить свопа.
При 16 ГБ свободной памяти? Сомнительно.
При невозможности выделить 8К.
Тебе не кажется, что если кто-то внезапно отожрал 16 ГБ рамы, то стоит разобраться, кто это был и почему он себя так повел? А добавление свопа - это симптоматическое лечение, которое, скорее всего, не будет работать.
Своп был. Тогда вместо тормозов от нехватки памяти были тормоза из-за активного перемещения кеша в своп и обратно
на фоне общей нехватки памяти. Картина примерно следующая:
Не вижу нехватки памяти.
как и в этом случае
roman77 ★★★★★ ( 02.06.14 20:10:57 )Последнее исправление: roman77 02.06.14 20:12:24 (всего исправлений: 1)
Тебе не кажется, что если кто-то внезапно отожрал 16 ГБ рамы, то стоит разобраться, кто это был и почему он себя так повел?
Мне кажется, что в логах есть вот это:
И если в таких условиях при fork невозможно выделить 8КБайт, дело, скорее всего, в фрагментации. Использование свопа - способ ее обойти.
А разобраться, конечно, стоит. Только вряд ли мы сумеем это сделать.
перемещения кеша в своп и обратно
Эм. Зачем дублировать данные из кеша на диск?
Своп был. Тогда вместо тормозов от нехватки памяти были тормоза из-за активного перемещения кеша в своп и обратно
(пожимая плечами) Выбирай, что для тебя лучше: OOM или свопинг.
большая часть памяти занята кешами
перемещения кеша в своп и обратно
Причин для запуска oom_killer я не вижу, рамы у тебя очень много. Возможно, имел место принудительный запуск (что маловероятно, но все же). Проверь, что это за скрипт covertart.sh, во время работы которого произошел oom_killer.
Посмотри, кто у тебя активнее всех потребляет CPU (top) и диск (iotop).
Откуда ты знаешь, что был запрос на выделение 8КБ? Подскажи, где это написано.
Я не знаю, зачем ядро это делает. Возможно, оно вместо того, чтобы вытеснить кеши из памяти и занять ее чем-нибудь полезным, вытесняло полезные данные на диск, а кеши не трогало. Но тормоза были, своп активно использовался до момента заполнения, а потом включался тот же oom_killer. Никакое приложение в момент его работы не ело память, более 10ГБ было всегда занято кешами.
Гладко было на бумаге. Недоступны для программ эти 13ГБ и даже через drop_caches не освобождаются, в этом вся суть треда
А скрипт coverart.sh безобидный, там нечему память есть - ему просто не повезло :)
(пожимая плечами) Выбирай, что для тебя лучше: OOM или свопинг.
Мне не нужен ни oom, ни своппинг - у меня 13ГБ свободной памяти - я хочу, чтобы она была доступна приложениям, а не лежала мертвым грузкешем
А проверь, на всякий случай, нет ли у тебя какого-нибудь ramfs, забитого под завязку. Вроде /tmp и тому подобных. Что говорят cat /proc/mounts и df -h ?
Несколько примонтированных tmpfs есть, но там было суммарно мегабайт 50 - я сразу проверил :)
Откуда ты знаешь, что был запрос на выделение 8КБ?
оrder=1 - это 2 страницы, 8К.
я хочу, чтобы она была доступна приложениям, а не лежала мертвым грузкешем
Покрути swappiness. Но своп тебе всё равно нужен, чтобы обойти фрагментацию.
Крутил swappiness, она дает только отсрочку oom_killer-a. При активном случайном чтении 2ТБ данных дисковые кеши неуклонно растут - надо их как-то перевоспитать, чтобы они своевременно освобождали оперативку, когда та нужна приложениям, иначе никакого свопа не напасешься.
Крутил swappiness, она дает только отсрочку oom_killer-a
Ты крутил swappiness без свопа, или у тебя даже со свопом срабатывает OOM killer?
tailgunner ★★★★★ ( 02.06.14 21:08:12 )Последнее исправление: tailgunner 02.06.14 21:09:38 (всего исправлений: 1)
Даже со свопом. Только ждать приходится дольше и мучительнее - пока своп заполнится под завязку, все дико тормозит, но если набраться терпения, можно дождаться oom_killer
tmpfs, повторюсь, есть, но пустые
Если своп за некоторое время заполняется, вывод очевиден - что-то течет.
Спасибо, кэп! А если 16 гиг рамы за некоторое время заполняются, то вывод не очевиден?
А если 16 гиг рамы за некоторое время заполняются, то вывод не очевиден?
Нет. И посмотри уже на dmesg - там доходчиво.
посмотри уже на dmesg - там доходчиво.
А теперь скажи мне, убогому, где искать эти 13 ГБ, и при помощи какой магии включение свопа решит проблему, а не просто оттянет ее до тех пор, пока своп не забьется?
Еще одна сумасшедшая идея: прогони sudo lsof на tmpfs. Твои симптомы воспроизводятся с удаленными, но все еще открытыми, файлами. Может какой процесс чего открыл, удалил, да забыл закрыть?
Прогнал, среди открытых только существующие файлы.
Про shmem уже сказали выше.
А теперь скажи мне, убогому, где искать эти 13 ГБ
Окей, но это последний раз. Вот искомые 13ГБ.:
и при помощи какой магии включение свопа решит проблему
Если проблема связана с фрагментацией, то свопинг может ее уменьшить.
tpmfs ограничь метров на 200
видимо бага ядра
потыкай другую версию ядра
Ок, кеш большой из-за активного чтения с диска. Почему он своевременно не освобождается, когда память нужна приложениям?
tmpfs не заполнена. Проблема наблюдается на всех ядрах, прошедших бэкпорты дебиана за последние полгода
Вот искомые 13ГБ
невозможность выделить 8К
проблема связана с фрагментацией
1) Фрагментация чего? Дай ссылку, где про это почитать.
2) Есть какие-то веские основания полагать, что проблема именно в этом? Занято всего порядка 20% памяти. Это должна быть какая-то очень адовая фрагменатция, чтобы в остальных 80% не нашелся цельный блок из двух страниц.
Почему он своевременно не освобождается, когда память нужна приложениям?
Да. Какие еще я мог сделать выводы?
а ты попробуй
занеси в fstab size=200m и reboot
Фрагментация, как я; ошибка ядра или заполнение tmpfs, как ubuntuawp.
+1 Проблема в больших файлах в tmpfs.
Я переписывал 1Гб файл с флэшки в tmpfs, кэш возрос, а в tmpfs показывало что, файл занимает несколько Мб. Я сначала думал, что файл не прочитался, но когда записал на жесткий диск, размер оказался нормальным.
Shmem как раз говорит об этом.
Параметры tmpfs крутить тут.
О какой такой фрагментации ты все время говоришь? Дай уже наконец ссылку, где можно об этом почитать. И какие у тебя есть основания предполагать фрагментацию при 80% свободной памяти?
Проверили же уже, ничего не нашли.
ТС пробовал разные версии ядра. Если ошибка давняя и легко воспроизводится, то почему ее еще не починили? А если ошибка проявляется только в определенных условиях, хочется понять, в каких именно.
Мне все еще на дает покоя идея про tmpfs. Попробуй их отмонтировать по одной (в single user mode, если потребуется). Может внезапно обнаружится, что одна из них все-таки держала всю память? А если нет, то по крайней мере, можно будет окончательно снять подозрения с tmpfs/ramfs и начать копать в другом направлении.
Проверили же уже, ничего не нашли.
Пусть скажет как проверял.
Свои tmpfs (за исключением стандартных от дистрибутива) я так и проверял.
Сегодня утром почти случайно удалось освободить эти 13ГБ shmem без перезагрузки: когда, убив по одному все сколько-нибудь активные приложения (после каждого делая sync и drop_caches), я сдался и собрался было перезагрузиться, я вышел из иксов и наудачу сделал те же sync + drop_caches. Счетчик shmem обнулился.
Последним шагом были остановлены X, fluxbox, conky (3 инстанции), xxkb, urxvtd, xscreensaver и два маленьких самописных скрипта. Сейчас иксы запущены снова, буду ждать накопления мусора в shmem и убивать этих по одному. Наибольшие подозрения у меня вызывает xscreensaver (он 18 часов в сутки крутит слайдшоу из фотографий), следующий на очереди urxvtd.
Как только узнаю что-то новое - отпишусь здесь.
И никто не вспомнил про zram.
кстати сколько он провисел запущенным? у меня под генту оно потихонечку текло..
а проблемма воспроизводится на раз-два или нужны специфические условия?
ZuBB ★★★★★ ( 03.06.14 23:11:39 )Последнее исправление: ZuBB 03.06.14 23:12:31 (всего исправлений: 1)
Проблема воспроизводится при обычном использовании, но медленно - через две недели обычно на глаз ничего еще не заметно - а там, глядишь, и новое ядро выпускают :)
Urxvtd был запущен те же 20 дней, что и компьютер.
У меня тоже на дебиане оно течет, при любой попытке обращения к миллионам мелких файлов в ext4. Пытался бороться, потом забил.
У меня тоже на дебиане оно течет, при любой попытке обращения к миллионам мелких файлов в ext4
Читайте также: