На сколько фрагментация памяти замедляет работу системы и приложения?

Question

[beduin01]

Вопрос касается сборщика мусора. Как я понимаю хороший GC умеет выполнять дефрагментацию памяти т.е. после удаления объекта из памяти освободившиеся дырки ликвидируются.

Собственно вопрос -- на сколько ручное управление памятью приводит к фрагментации (вряд ли программисты в своем большинстве делают что-то большее кроме как простое удаление объекта).

На сколько падает производительность? Где про это дело почитать подробнее.

В каких задачах вы сталкивались с проблемами фрагментации памяти?

Answer 1

[Михаил Усоцкий]

Влияние фрагментации памяти на производительность хорошо выражено в тех системах, где существуют значительные задержки доступа к памяти прежде, чем выполнять чтение и запись. Поэтому для жёстких дисков и существует служба дефрагментации. А для памяти типа ОЗУ это делать ненужно и вредно. Потому что процессору придётся снова сбрасывать свой кэш преобразования адресов. А это уйдёт куда больше времени. Потому что с точки зрения преобразования адресов фрагментации памяти нет. То есть каждая задача видит память не замусоренной и линейной. Да и страничная организация памяти позволяет программистам жить лучше. Другое дело - сегментная организация памяти. Но они давно не используются. Сборщики мусора занимаются несколько другими задачами. Их задача - очистить память от неиспользуемых объектов в течение такого-то времени, чтобы потом не возникла проблема доступностью памяти для различных операций. Иначе произойдёт утечка памяти. Но они не занимаются дефрагментацией.

Comments

[beduin01]

Михаил Усоцкий Тоесть просто есть куча страниц и когда нужно выделить еще место то просто свободная страница выделяется?

[Михаил Усоцкий]

beduin01: да, именно так. Когда создаётся какой-нибудь объект, куча, стек и прочее, динамически создаётся новая(ые) страница(ы) под их нужды. Когда завершается любая работа с ними, страница(ы) просто удаляется(ются) сборщиком мусора или деструктором в конкретных языках. Всё остальное уже делает процессор. Страницы позволяют гибко работать с памятью без серьёзных потерь производительности. Например. Создали мы три объекта размером 3, 1 и 5 страниц. Один объект размера одной страницы удалили. Создали новый объект из семи страниц. Вот одна страница разместится на освобождённой странице, а оставшиеся страницы разместятся в другой области памяти. А трансляция адресов позволяет обращаться к ним к равной степени производительности. Даже переписывать код программы не надо, процессор об этом позаботится. Вот так и решили проблему с фрагментацией памяти.

[beduin01]

Михаил Усоцкий зачем тогда нужны аллокаторы?
Сегментная адресация где-то используется?
Страницы это и есть та самая виртуальная память?

[Михаил Усоцкий]

beduin01: страницы и есть виртуальная память. Без страниц мы бы не смогли обеспечить многозадачность операционных систем, приложений и прочее. Сегментная организация практически не используется. Он использовался во времена MS DOS, где ограничение памяти из-за разрядности процессора было проблемой (16-разрядные процессоры по факту не могли обращаться к памяти более 64 кБ, но Intel нашла альтернативный путь за счёт сегментов нарастить до 1 МБ, из которых пользователю выделяются те самые знаменитые 640 кБ). В настоящее время используется только один сегмент для виртуализации (виртуальные машины). Остальные сегменты убрали полностью в 64-разрядных процессорах. А на 32-разрядных ещё можно встретить. Но большинство компиляторов тупо совмещают сегмент кода, данных и стека в одной плоскости памяти, чтобы не заморачиваться проблемой переноса программы на альтернативную архитектуру. Например: ARM. Ибо сегментная модель памяти - прерогатива x86. Сегментная модель памяти - это тоже виртуальная память, но очень геморройная в плане фрагментации (придётся смещать чуть ли не весь огромный кусок побайтно области памяти, и это делать нужно чуть ли не на каждом этапе). Поэтому отдали предпочтение страничной памяти (там не нужно ничего перемещать, достаточно изменить в таблице преобразования адресов значение, что конкретный кусок в памяти находится по новому адресу, но физически остаётся на месте).

Аллокаторы нужны для выделения памяти под свои нужды и задачи. Задаёшь размер памяти, а процессор его разбивает на страницы, если выделяется довольно большой участок памяти, или одну страницу, если аллокатор просит выделить участок памяти меньше страницы.

[beduin01]

Михаил Усоцкий тоесть аллокаторы нужны для очень редких кейсов когда вручную нужно иметь возможность определять размеры страниц? Просто я слабо себе представляю где это может потребоваться.

[Михаил Усоцкий]

beduin01: ну я не программирую на C++. Программирую на C#. Но применение его зависит от конкретных задач. Аллокаторы могут понадобиться там, где стандартные инструменты пасуют. Для обработки больших данных. Например, для кодирования и декодирования видео лучше выделить конкретные участки памяти. Или создание кучи.

Answer 2

[Армянское Радио]

Правильно это называть "Фрагментация адресного пространства". На 32 битной системе проблема действительно есть, и, в зависимости от задачи, может вылезти посадка скорости.

На 64 битной системе адресное пространство огромно, его тяжело фрагментировать.

Comments

[beduin01]

И как там дела обстоят? В случае чего просто адреса с запасом выделяются чтобы размера дыры между ними хватило для самих данных?

[Армянское Радио]

beduin01: Ваш вопрос мне непонятен.

[beduin01]

Армянское Радио: ну вот на 32 битной системе нельзя допускать появление больших дырок верно? На 64 битной запас по адресам большой и можно размещать данные, так что между ними будут дырки, которые позволят к примеру увеличивать длину строки не опасаясь, что она упрется в границу следующих данные. Так?

[Армянское Радио]

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