Выделенная память что это

Не доверяйте информации о памяти в Диспетчере задач

tl;dr: Диспетчер задач скрывает информацию о подкачке (paged memory) и виртуальном пространстве процесса. Лучше используйте Process Explorer из комплекта Sysinternals.

Выделение памяти в Windows

При запуске нового процесса ОС присваивает этому процессу непрерывное адресное пространство. В 32-разрядных системах это пространство может составить 4 ГБ, обычно 2 ГБ для ядра, а остальное для процесса. В этой статье проигнорируем использование памяти ядром. В 64-разрядных системах зарезервированная процессом память может вырасти до колоссальных 64 ТБ. Что этот процесс будет делать с несколькими терабайтами памяти, когда у нас на самом деле жалкие 8 ГБ? Сначала нужно понять, что такое зарезервированная и переданная память.

Зарезервированная и переданная память

Не все части этого огромного адресного пространства равны. Некоторые части адресного пространства процесса фактически поддерживаются либо физической оперативной памятью, либо диском (см. ниже). Зарезервированная память считается переданной (Committed), если ОС предлагает вам эту память при попытке её использовать. Остальная часть адресного пространства, а это подавляющее большинство, остаётся доступным для резервирования. То есть не всегда ОС может предложить вам этот блок памяти для использования: она может сделать копию на диске (файл подкачки), например, а может и не сделать. В C++ резервирование памяти осуществляется вызовом VirtualAlloc. Так что переданная память является аппаратно ограниченным ресурсом в ОС. Давайте посмотрим.

Файл подкачки ОС

Файл подкачки — замечательная идея. В принципе, ОС понимает, что некоторые части памяти особо не используются вашим приложением. Зачем тратить на него реальную физическую память? Вместо этого процесс в ядре записывает этот неиспользуемый фрагмент на диск. Пока к нему не обратятся снова, только тогда он вернётся в память.

Для более подробного объяснения, как работает память в Windows, рекомендую лекцию «Тайны управления памятью» Марка Руссиновича.

Отслеживание памяти

Здесь много за чем нужно следить и анализировать. К кому обратиться? Конечно, к Диспетчеру задач!

Память в RAM обычно называют рабочим набором (Working Set), в то время как всю выделенную память обычно именуют Private Bytes. Библиотеки DLL вносят путаницу в определения, поэтому пока их проигнорируем. Иначе говоря:

Private Bytes [выделенная память] = рабочий набор + файл подкачки

По умолчанию Диспетчер задач показывает для любого процесса именно рабочий набор:

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

Эффективные метрики памяти

К счастью, есть много других ресурсов для отслеживания ресурсов. На каждой машине под Windows установлен PerfMon (Системный монитор), который выдаёт очень подробную информацию о каждом процессе и системе в целом:

Интересно, что Системный монитор умеет фактически исследовать и сравнивать метрики на двух или более компьютерах в сети. Это очень мощный инструмент, но Диспетчер задач, очевидно, удобнее для пользователей. В качестве промежуточного решения рекомендую Process Explorer:

Бум! Visual Studio, чего это ты до сих пор в 32-битном режиме (обратите внимание на его Virtual Size)? Пиковое использование памяти на моём компьютере на уровне 89% от максимума, ещё терпимо. Это пригодится позже.

Дополнение: многие указали на другие удобные инструменты, в том числе VMMap и RAMMap.

Отладка по информации о памяти

К счастью, это не какие-то ненужные мелочи ОС. Актуальная информация о потреблении памяти многократно помогала мне в отладке разных проблем.

Самое главное, это найти нетронутые части выделенной памяти. Данные о подкачке тоже важны: эта память передана, но используется редко или вообще не используется.

Даже если память будет иногда использоваться, важно понимать, что это дорогой ресурс, так что идти по такому пути ни в коем случае нельзя. Здесь появятся и утечки памяти.

По этим причинам я ранее слышал предложение полностью удалить файл подкачки и приравнять выделенную память рабочему набору. Однако это обоюдоострая идея. Тогда ОС не в состоянии сбросить память в случае неправильной работы приложений, которые иногда впустую резервируют память.

Источник

Что значит выделено и кэшировано памяти

Поговорим немного о памяти, а точнее об оперативной памяти. Наиболее часто мы слышим такие понятия как выделено и кэшировано. В чем смысл этих понятий? Давайте постараемся ответить на этот вопрос.

Дело в том, что в каждом компьютере установлена оперативная память. Она бывает разных размеров, но по факту вы получаете память которая выделена. К примеру у вас в системе установлено 6 Гб оперативной памяти, что значит, что выделено 6 Гб, под ваш компьютер. Разумеется, ка только вы включили компьютер и он загрузился, свободной памяти остается куда меньше, чем изначально. Все потому, что многие процессы, службы, библиотеки и программы, при включении компьютера, грузятся в оперативную память.

Теперь давайте разберемся, что значит кэшированная память.

Дело в том, что вы можете создать файл подкачки на вашем жестком диске. Когда оперативная память вашего компьютера будет полностью загружена, то файл подкачки будет использоваться как некая замена оперативной памяти. Другими словами, выделенное место на жестком диске, будет имитировать оперативную память. Работать конечно все будет куда медленнее нежели с нормальной оперативной памятью, однако это своего рода плата, за возможность хоть как-то работать в критические моменты.

Таким образом, мы разобрались, что значит выделенная память и кэшированная память. Надеемся, статья была вам полезна и вы нашли ответы на свои вопросы.

Источник

Выделение памяти под встроенную видеокарту: как увеличить видеопамять у интегрированных IntelHD, Intel Iris Xe и AMD Ryzen Vega (UMA Frame Buffer Size)

Доброго времени!

В последнее время снискали большую популярность интегрированные (их еще называют встроенными ) видеокарты IntelHD, Intel Iris Xe, и AMD Ryzen Vega. Последних версий уже с лихвой хватает для многих не слишком требовательных игр (что, конечно, радует — т.к. получается хорошая такая экономия на покупке внешней видеокарты)!

Однако, есть один нюанс : видеопамять для этих карт выделяется из ОЗУ (RAM). По умолчанию эта операция «выделения» происходит автоматически (без вашего участия), что не во всех случаях оптимально (например, вы можете столкнуться с ошибками во время запуска игр. ).

Разумеется, было бы не плохо вручную отрегулировать выделение памяти под интегрированную карту (в большинстве случаев стоит вопрос ее увеличения ).

И так, перейдем ближе к теме.

Можно ли разогнать встроенные видеокарты Intel HD и AMD Radeon? За счет чего поднять их производительность

Как увеличить видеопамять: по шагам

ШАГ 1: зачем это нужно

Вообще, если у вас все корректно работает, нет притормаживаний, ничего не зависает и не вылетает с ошибками — то вам, скорее всего, это и не нужно.

Однако, есть ситуации, когда без этого никак:

3DMark Sky Driver (8GB Ram, dual) — производительность в зависимости от выделенной памяти для интегрированной видеокарты AMD Ryzen Vega 11 (Ryzen 5 2400G)

Примечание!

👉 Если у вас количество ОЗУ 8 ГБ (и более) — то большинство современных материнских плат по умолчанию устанавливают для встроенной видеокарты номинальные 1024 МБ (которых пока достаточно для норм. работы).

👉 Не могу не отметить, что если у вас на борту меньше 6 ГБ ОЗУ — то выставлять для интегрированной карты больше 1 ГБ памяти крайне не рекомендуется! Это отрицательно сказывается на общей производительности ПК/ноутбука.

ШАГ 2: как узнать текущий объем видеопамяти

👉 Вариант 1

Это универсальный вариант, работающий во всех популярных версиях Windows 7/8/10.

Сначала необходимо нажать сочетание кнопок Win+R — в окне «Выполнить» ввести команду dxdiag и кликнуть по OK.

Далее откроется средство диагностики DirectX — во вкладке «Экран» среди прочих характеристик устройства вы найдете размер видеопамяти (👇).

Видеопамять 1009 МБ

👉 Вариант 2

Доп. параметры дисплея

👉 Вариант 3

Этот вариант также актуален для ОС Windows 10.

ШАГ 3: как вручную установить размер выделения памяти под встроенную видеокарту

Через BIOS/UEFI

Только через настройки BIOS (в принципе) и можно изменить размер выделяемой памяти для интегрированной карты (в редких случаях можно попытаться «обмануть» игры через реестр).

И так, сначала необходимо 👉 войти в BIOS (ссылка на инструкцию в помощь).

Далее нужно перейти в раздел «Configuration» (в некоторых BIOS за это отвечает раздел «Advanced» ).

Затем нам нужно найти один из следующих параметров (прим.: в разных версиях BIOS он называется по-своему) :

На скриншоте ниже приведен параметр «iGPU Configuration» — необходимо отключить авто-режим!

Отключаем Auto режим

А после вручную задать параметр «UMA Frame Buffer Size» — это и есть размер выделяемой видеопамяти (в моем примере можно выбрать от 256 МБ до 2 ГБ 👇).

UMA Frame Buffer Size — ставим 2 GB

Advanced / настройки BIOS / American Megatrends

DVMT ставим на Maximum

Еще один пример для более старой версии American Megatrends см. ниже. 👇

Через настройки реестра (опционально для IntelHD)

Этот способ поможет только «перехитрить» некоторые игры, которые могут вылетать с ошибками после запуска (т.к. у вас якобы недостаточно видеопамяти). Т.е. игра будет «считать», что размер памяти видеокарты у вас больше, чем есть на самом деле.

Причем, хочу отметить, что срабатывает он не всегда (но всё же, вдруг. ).

И так, для начала нужно 👉 открыть редактор реестра — нажать Win+R, и использовать команду regedit.

regedit — открыть редактор реестра

Далее в редакторе нужно создать раздел «GMM» в нижеприведенной ветке:

Создать раздел GMM

После, в разделе «GMM» создать строковый параметр с именем «DedicatedSegmentSize» (без кавычек).

Создать строковый параметр

Далее открыть его и задать значение выделяемой памяти (судя по тестам, способ актуален и работает для значений от 0 до 512).

Источник

Отладка вашей ОС: урок по выделению памяти

Всё началось, как и многие другие расследования, с баг-репорта.

Название отчёта было довольно простым: «При HTTP-подключении iter_content медленно работает с чанками большого размера». Подобное название немедленно включило у меня в голове сирену по двум причинам. Во-первых, довольно сложно определить, что здесь означает «медленно»? Насколько медленно? Насколько велик «большой размер»? Во-вторых, если бы описанное проявлялось действительно серьёзно, то мы бы об этом уже знали. Метод iter_content используется давно, и если бы он существенно притормаживал в распространённом пользовательском режиме, то мимо нас такая информация не прошла бы.

Я быстро просмотрел отчёт. Автор предоставил мало подробностей, но написал вот что: «Это приводит к 100%-й загрузке процессора и снижает пропускную способность сети ниже 1 Мб/с». Я ухватился за эту фразу, потому что такого быть не может. Простое скачивание с минимальной обработкой не бывает настолько медленным!

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

Это просто замечательный воспроизводимый сценарий, потому что он совершенно чётко указывает на стек Requests. Здесь не выполняется пользовательский (user-supplied) код: это часть библиотеки Requests или одной из его зависимостей; нет вероятности, что это пользователь написал дурацкий низкопроизводительный код. Настоящая фантастика. Ещё более фантастично использование публичного URL. Я мог выполнить сценарий! И, сделав это, я столкнулся с багом. При каждом выполнении.

Здесь была ещё одна прелестная подробность:

При 10 Мб не отмечается какого-то роста нагрузки на процессор и влияния на пропускную способность. При 1 Гб процессор загружается на 100 %, как и при 100 Мб, но пропускная способность падает ниже 100 Кб/с, в отличие от 1 Мб/с при 100 Мб.

Это очень интересный момент: он намекает на то, что литеральное значение (literal value) размера чанка влияет на рабочую нагрузку. Если учесть, что это происходит только при использовании PyOpenSSL, а также что большую часть времени стек обслуживает вышеприведённый код, проблема становится ясна:

Настоящий баг

Шутки в сторону: это действительно позволило решить проблему. Но несколько дней спустя мне задали очень глубокомысленный вопрос: зачем вообще память активно обнулялась? Чтобы понять суть вопроса, давайте отвлечёмся и поговорим о выделении памяти в POSIX-системах.

malloc и calloc и vmalloc, ох ты ж!

Многим программистам известен стандартный способ запроса памяти у оперативной системы. В этом механизме задействована функция malloc из стандартной библиотеки С (можете почитать документацию о ней для вашей ОС, введя в мануале в поиск man 3 malloc ). Эта функция берёт один аргумент — количество байтов памяти, которое нужно выделить. Стандартная библиотека С выделяет память по одной из нескольких разных методик, но так или иначе она возвращает указатель на участок памяти, по крайней мере такой же большой, как и запрошенный вами объём.

По умолчанию malloc возвращает неинициализированную память. То есть стандартная библиотека С выделяет какой-то объём и немедленно передаёт его вашей программе, без изменения данных, которые уже там находятся. То есть при использовании malloc вашей программе будет возвращаться буфер, в который она уже записывала данные. Это распространённая причина багов в не безопасных по памяти (memory-unsafe) языках, например С. В целом читать из неинициализированной памяти очень рискованно.

Но у calloc есть побочный эффект, связанный с его исходным предназначением для размещения массивов в памяти. О нём очень скромно упоминается в мануале.

Выделенная память заполнена нулевыми байтами.

Такое поведение означает, что malloc возвращает неинициализированную память, а calloc — инициализированную. А раз так, да ещё и в свете вышеупомянутых строгих обещаний, то операционная система может оптимизировать выделяемую память. И действительно, многие современные ОС так делают.

Воспользуемся calloc

Конечно, простейший способ внедрить calloc — это написать что-то вроде:

Стоимость подобной функции изменяется примерно линейно по отношению к размеру выделяемой памяти: чем больше байтов, тем дороже их все обнулить. Сегодня большинство ОС по факту содержат стандартные библиотеки С, в которых прописаны оптимизированные пути для memset (обычно используются специализированные процессорные векторные инструкции, позволяющие одной инструкцией обнулять сразу большое количество байтов). Тем не менее стоимость этой процедуры меняется линейно.

Для выделения больших объёмов в ОС используется ещё один трюк, имеющий отношение к виртуальной памяти.

Виртуальная память

Здесь мы не будем разбирать всю структуру и работу виртуальной памяти, но я очень рекомендую об этом почитать (тема крайне интересная!). Вкратце: виртуальная память — это ложь ядра ОС процессам о доступной памяти. У каждого выполняемого процесса есть своё представление о памяти, принадлежащей ему и только ему. Это представление косвенно «отображается» (mapped) на физическую память.

В результате ОС может прокручивать всевозможные хитрые трюки. Чаще всего она выдаёт за память специальные файлы, отображаемые в неё (memory-mapped file). Они используются для выгрузки содержимого памяти на диск, а также для отображения в них памяти. В последнем случае программа просит ОС: «Пожалуйста, выдели мне n байтов памяти и сохрани их в файле на диске, так, чтобы, когда я буду писать в память, все записи выполнялись бы в этот файл, а когда считываю из памяти, то данные считывались бы из него же».

На уровне ядра это работает так: когда процесс пытается считать из такой памяти, процессор уведомляет, что память не существует, ставит процесс на паузу и бросает «ошибку страницы» (page fault). Ядро помещает в память актуальные данные, чтобы приложение могло их считать. Затем процесс снимается с паузы и находит в соответствующем месте волшебным образом появившиеся данные. С точки зрения процесса всё произошло мгновенно, без паузы.

Этот механизм можно использовать для выполнения других тонких трюков. Один из них заключается в «бесплатности» выделения очень больших объёмов памяти. Или, точнее, в том, чтобы сделать их стоимость пропорциональной степени использования этой памяти, а не выделяемому размеру.

Чтобы избежать очень больших затрат при запуске приложений, операционные системы начали врать приложениям. В большинстве ОС, если вы попытаетесь выделить более 128 Кб в рамках одного вызова, стандартная библиотека С напрямую попросит у ОС совершенно новые страницы виртуальной памяти, которые покроют запрошенные объёмы. Но главное: такое выделение почти ничего не стоит. Ведь на самом деле ОС ничего не делает: она лишь перенастраивает схему виртуальной памяти. Так что при использовании malloc расходы получаются мизерными.

Память не была «приписана» к процессу, и, как только приложение пытается использовать её на самом деле, возникает ошибка страницы памяти. Здесь вмешивается ОС, находит нужную страницу и помещает её туда, куда обращается процесс, так же, как и в случае с ошибкой памяти и файлом отображаемой памяти. Только разница в том, что виртуальная память обеспечивается памятью физической, а не файлом.

В результате, если вызвать malloc(1024 * 1024 * 1024) для выделения 1 Гб памяти, это произойдёт почти мгновенно, потому что на самом деле процессу память не выделяется. Зато программы могут моментально «выделять» для себя многие гигабайты, хотя в реальности это происходило бы далеко не быстро.

Вернёмся к нашему багу

Очень простая программа на C, выделяющая и освобождающая 100 Мб посредством вызова calloc десять тысяч раз. Затем выполняется выход. Далее — два варианта 5 :

Более того, если увеличить ALLOCATION_SIZE (например, 1000 * 1024 * 1024 ), то на MacOS эта программа станет работать почти мгновенно! Что за чертовщина?

Что тут вообще происходит?

Углублённый разбор

В MacOS есть утилита sample (см. man 1 sample ), которая может многое рассказать о выполняемом процессе, регистрируя его состояние. Для нашего кода sample выдаёт такое:

Похоже, вся магия происходит в large_malloc. Эта ветка нужна для выделения памяти крупнее 127 Кб, она использует трюк с виртуальной памятью. Так почему у нас всё медленно работает?

В этом есть свой резон: обнулённые страницы — ограниченный ресурс, особенно в условиях скромного железа (смотрю на Apple Watch). Так что если страницу можно использовать повторно, то это может дать хорошую экономию.

В результате на MacOS стоимость calloc линейно возрастает в зависимости от размера выделяемой памяти вплоть до 125 Мб, несмотря на то что другие ОС демонстрируют поведение O(1) начиная со 127 Кб. После 125 Мб MacOS перестаёт кешировать страницы, так что скорость волшебным образом взлетает.

Я не ожидал найти такой баг из программы на Python, и у меня возник ряд вопросов. Например, сколько процессорных циклов теряется на обнуление памяти, которая уже обнулена? Сколько переключений контекста уходит на то, чтобы заставлять приложения загружать (page-in) память, которую они не использовали (и не собираются), чтобы ОС могла бессмысленно её обнулить?

Мне кажется, всё это подтверждает верность старой поговорки: утечки есть во всех абстракциях (all abstractions are leaky). Вы не можете забывать об этом лишь потому, что программируете на Python. Ваша программа выполняется на машине, использующей память и всякие трюки для её управления. Однажды, совершенно неожиданно, написанный вами код станет работать очень медленно. И разобраться с этим удастся, лишь разобравшись во внутренностях ОС.

Этот баг был описан как Radar 29508271. Один из самых странных багов, что мне встречались.

Источник

Что такое доступная и выделенная видеопамять?

Память на видеокартах может быть как выделенной, так и выделяемой. Выделенная память означает, что видеопамять реализуется путем размещения на карте нескольких микросхем памяти. Все современные видеокарты, претендующие на сколько-нибудь сносную производительность, оснащаются выделенной памятью, хотя это и повышает их физические размеры, тепловыделение и, разумеется, цену. Видеокарты с выделяемой видеопамятью не имеют собственных чипов памяти, а, по мере необходимости, задействуют часть общесистемной памяти. Выделяемая память обычно не позволяет получить высокую производительность видеосистемы и используется в основном, в интегрированных и недорогих мобильных решениях, где вопросы экономичности выходят на первый план.

Пример.
Чтоб знал =)
1. Доступно графической памяти: 2804 МБ
Абсолютно бесполезный параметр. Вся память, доступная для графической обработки. Возможно, система не использует всю эту память, но она доступна при необходимости.

2. Используется видеопамяти: 1024 МБ
Этот параметр указывает объем памяти установленной на видеокарте.
При использовании интегрированных графических карт эта память резервируется системой BIOS и извлекается из памяти системы перед загрузкой Windows

4. Общей системной памяти: 1780 МБ
Дополнительный резерв памяти, который может быть оперативно перенаправлен и использован. При необходимости эта память может использоваться для графики или различными программами.

P.s: У вас 4Гб Оперативной памяти из которых системе доступно 3,85Гб
1Гб Видеопамяти на видеокарте (обычной или мобильной), а система может отсыпать еще 1780мб в случае острой необходимости, оставив себе 2Гб ОЗУ для работы. (но она этого не сделает.

Источник