Що таке фрагментація пам'яті?

Я чув, що термін "фрагментація пам'яті" вживався кілька разів у контексті динамічного розподілу пам'яті C ++. Я знайшов кілька питань, як боротися з фрагментацією пам'яті, але не можу знайти прямого питання, яке стосується саме цього. Так:

• Що таке фрагментація пам'яті?
• Як я можу визначити, чи є фрагментація пам'яті проблемою для мого додатка? Яка програма найбільше страждає?
• Які хороші поширені способи боротьби з фрагментацією пам'яті?

Також:

• Я чув, що використання динамічних розподілів багато що може збільшити фрагментацію пам'яті. Це правда? У контексті C ++ я розумію, що всі стандартні контейнери (std :: string, std :: vector тощо) використовують динамічне розподілення пам'яті. Якщо вони використовуються протягом програми (особливо std :: string), чи швидше за все фрагментація пам'яті буде проблемою?
• Як можна розібратися з фрагментацією пам'яті в додатку, важкому для STL?

Уявіть, що у вас є "велика" (32 байт) простора вільної пам'яті:

----------------------------------
|                                |
----------------------------------

Тепер виділіть деякі з них (5 виділень):

----------------------------------
|aaaabbccccccddeeee              |
----------------------------------

Тепер звільніть перші чотири розподіли, але не п'яте:

----------------------------------
|              eeee              |
----------------------------------

Тепер спробуйте виділити 16 байт. На жаль, я не можу, навіть якщо майже удвічі більша кількість безкоштовних.

У системах з віртуальною пам’яттю фрагментація є меншою проблемою, ніж ви могли б подумати, тому що великі асигнування потребують суміжного лише у віртуальному адресному просторі, а не у фізичному адресному просторі. Тож у моєму прикладі, якби у мене була віртуальна пам’ять з розміром сторінки в 2 байти, то я могла б без проблем виділити 16 байт. Фізична пам'ять виглядала б так:

----------------------------------
|ffffffffffffffeeeeff            |
----------------------------------

тоді як віртуальна пам'ять (значно більша) може виглядати так:

------------------------------------------------------...
|              eeeeffffffffffffffff                   
------------------------------------------------------...

Класичний симптом фрагментації пам’яті полягає в тому, що ви намагаєтеся виділити великий блок і не можете, навіть якщо вам здається, що вільної пам'яті не вистачає. Інший можливий наслідок - неможливість процесу повернути пам'ять до ОС (адже там якийсь об'єкт досі використовується у всіх блоках, які він виділив з ОС, хоча ці блоки зараз здебільшого не використовуються).

Тактика запобігання фрагментації пам'яті в C ++ працює шляхом розподілу об'єктів з різних областей відповідно до їх розміру та / або очікуваного терміну експлуатації. Тож якщо ви збираєтесь створити багато об’єктів і знищити їх усі разом пізніше, виділіть їх із пулу пам'яті. Будь-які інші розподіли між ними не будуть з пулу, отже, вони не будуть розташовуватися між ними в пам'яті, тому пам'ять не буде фрагментована в результаті.

Як правило, вам не потрібно дуже хвилюватися з цього приводу, якщо ваша програма не працює довго і не робить багато розподілу та звільнення. Саме тоді, коли у вас є суміші короткотривалих і довгоживучих об'єктів, ви найбільше ризикуєте, але вже тоді mallocзробите все можливе, щоб допомогти. В основному, ігноруйте це, поки у вашій програмі не виникнуть збої при розподілі або несподівано не змусить система втратити пам'ять (вловлюйте це під час тестування, для переваги!).

Стандартні бібліотеки не гірші за все, що виділяє пам'ять, а стандартні контейнери мають Allocпараметр шаблону, який ви можете використовувати для точної настройки стратегії їх розподілу, якщо це абсолютно необхідно.

Що таке фрагментація пам'яті?

Фрагментація пам’яті полягає в тому, що більша частина вашої пам’яті виділяється на велику кількість безперервних блоків або шматок, залишаючи непоганий відсоток від вашої загальної пам’яті нерозподіленим, але непридатним для більшості типових сценаріїв. Це призводить до винятку пам'яті або помилок при розподілі (тобто malloc повертає null).

Найпростіший спосіб подумати над цим - уявити, що у вас є велика порожня стіна, на яку потрібно розмістити зображення різного розміру . Кожна картина має певний розмір, і ви, очевидно, не можете розділити її на більш дрібні шматки, щоб вона підходила. Вам потрібно порожня пляма на стіні, розмір малюнка, інакше ви не можете поставити його. Тепер, якщо ви почнете вішати фотографії на стіну, і не стежите за тим, як їх розташувати, незабаром у вас з’явиться стіна, яка частково покрита картинками, і хоча у вас можуть залишитися порожні плями, більшість нових фотографій не підійдуть. оскільки вони більше, ніж доступні місця. Ви все одно можете повісити дійсно невеликі фотографії, але більшість з них не підходять. Тож вам доведеться переставити (компактно) ті, які вже є на стіні, щоб звільнити місце для більше.

А тепер уявіть, що стіна - це ваша (купа) пам’яті, а зображення - об’єкти. Це фрагментація пам’яті ..

Як я можу визначити, чи є фрагментація пам'яті проблемою для мого додатка? Яка програма найбільше страждає?

Показовий знак того, що ви можете мати справу з фрагментацією пам’яті, якщо ви отримуєте багато помилок розподілу, особливо коли відсоток використаної пам’яті високий - але ви ще не використали всю пам’ять - так що технічно у вас повинно бути багато місця для об'єктів, які ви намагаєтеся виділити.

Коли пам'ять сильно фрагментована, розподіл пам’яті, швидше за все, триватиме більше часу, оскільки алокатор пам’яті повинен зробити більше роботи, щоб знайти відповідний простір для нового об’єкта. Якщо у свою чергу у вас є багато розподілу пам'яті (що, мабуть, ви робите з того часу, коли ви закінчилися з фрагментацією пам'яті), час розподілу може навіть спричинити помітні затримки.

Які хороші поширені способи боротьби з фрагментацією пам'яті?

Використовуйте хороший алгоритм для розподілу пам'яті. Замість того, щоб виділяти пам'ять для багатьох дрібних об'єктів, попередньо виділіть пам'ять для суміжного масиву цих менших об'єктів. Іноді бути невеликим марнотратством при розподілі пам’яті можна піти на шляху до продуктивності і може врятувати вам проблеми, коли вам доведеться боротися з фрагментацією пам'яті.

Фрагментація пам’яті - це те саме поняття, що і фрагментація диска: це стосується витраченого простору, оскільки використовувані області недостатньо упаковані разом.

Припустимо для простого іграшкового прикладу, що у вас є десять байт пам'яті:

 |   |   |   |   |   |   |   |   |   |   |
   0   1   2   3   4   5   6   7   8   9

Тепер виділимо три трибайтові блоки, назви A, B і C:

 | A | A | A | B | B | B | C | C | C |   |
   0   1   2   3   4   5   6   7   8   9

Тепер розмістіть блок B:

 | A | A | A |   |   |   | C | C | C |   |
   0   1   2   3   4   5   6   7   8   9

Тепер що станеться, якщо ми спробуємо виділити чотирибайтовий блок D? Ну, у нас немає чотирьох байтів пам'яті, але у нас немає чотирьох суміжних байтів пам'яті, тому ми не можемо виділити D! Це неефективне використання пам’яті, оскільки ми повинні були вміти зберігати D, але цього нам не вдалося. І ми не можемо перемістити C, щоб звільнити місце, тому що, швидше за все, деякі змінні в нашій програмі вказують на C, і ми не можемо автоматично знайти та змінити всі ці значення.

Звідки ти знаєш, що це проблема? Ну, найбільша ознака полягає в тому, що розмір віртуальної пам’яті вашої програми значно перевищує об’єм пам’яті, який ви насправді використовуєте. У прикладі реального світу у вас буде набагато більше десяти байт пам'яті, тож D просто виділиться, починаючи байт 9, а байти 3-5 залишаться невикористаними, якщо пізніше ви не виділили щось три байти довгими або меншими.

У цьому прикладі 3 байти - це не багато марна трата, але розглянемо більш патологічний випадок, коли два виділення пару байтів, наприклад, на десять мегабайт в пам'яті, і вам потрібно виділити блок розміром 10 мегабайт + 1 байт. Для цього вам потрібно попросити ОС на понад десять мегабайт більше віртуальної пам’яті, навіть якщо ви лише один байт соромляться того, що вже вистачає місця.

Як вам запобігти? Найгірші випадки, як правило, виникають, коли ви часто створюєте та знищуєте дрібні предмети, оскільки це, як правило, створює ефект "швейцарського сиру" з багатьма дрібними предметами, розділеними багатьма маленькими отворами, що робить неможливим виділення більших предметів у цих отворах. Коли ви знаєте, що ви будете робити це, ефективна стратегія полягає в тому, щоб заздалегідь виділити великий блок пам'яті як пул для своїх маленьких об’єктів, а потім вручну керувати створенням малих об'єктів у цьому блоці, а не дозволяти алокатор за замовчуванням обробляє його.

Загалом, чим менше виділень, тим менше ймовірність, що пам'ять буде фрагментованою. Однак STL займається цим досить ефективно. Якщо у вас є рядок, який використовує всю її поточну розподіл, і ви додаєте до неї один символ, він не просто переділяє його на поточну довжину плюс один, він подвоює його довжину. Це зміна стратегії "пул для частих невеликих виділень". Рядок захоплює великий шматок пам'яті, щоб він міг ефективно справлятися з повторними невеликими збільшеннями розміру, не роблячи повторних невеликих перерозподілів. Усі контейнери STL насправді роблять подібне, тому, як правило, вам не потрібно буде надто турбуватися про фрагментацію, викликану автоматичним перерозподілом контейнерів STL.

Хоча, звичайно, контейнери STL не об'єднують пам'ять між собою, тому якщо ви збираєтеся створити багато маленьких контейнерів (а не кілька контейнерів, які часто змінюють розмір), можливо, вам доведеться потурбуватися про те, щоб запобігти фрагментації таким же чином, як і ви буде для будь-яких часто створюваних невеликих об'єктів, STL чи ні.

• Що таке фрагментація пам'яті?

Фрагментація пам'яті - це проблема пам'яті, що стає непридатною для використання, навіть якщо вона теоретично доступна. Існує два види фрагментації: внутрішня фрагментація - це пам'ять, яка виділяється, але не може бути використана (наприклад, коли пам’ять виділяється в 8 байтних фрагментах, але програма повторно виконує одиночні повідомлення, коли їй потрібно лише 4 байти). зовнішня фрагментація - це проблема, коли вільна пам'ять поділяється на багато невеликих шматочків, тому великі запити на розподіл неможливо задовольнити, хоча загальної вільної пам'яті достатньо.

• Як я можу визначити, чи є фрагментація пам'яті проблемою для мого додатка? Яка програма найбільше страждає?

Фрагментація пам’яті є проблемою, якщо ваша програма використовує набагато більше системної пам’яті, ніж вимагало її фактичних даних про зарплату (а ви виключаєте витоки пам’яті).

• Які хороші поширені способи боротьби з фрагментацією пам'яті?

Використовуйте хороший розподільник пам'яті. IIRC, ті, хто використовують стратегію "найкращого пристосування", як правило, набагато перевершують уникнення фрагментації, якщо трохи повільніше. Однак було також показано, що для будь-якої стратегії розподілу існують найгірші патологічні випадки. На щастя, типові схеми розподілу більшості застосунків насправді відносно доброякісні для роботи алокаторів. Там є купа паперів, якщо вас цікавлять деталі:

• Пол Р. Вілсон, Марк С. Джонстоун, Майкл Нілі та Девід Болз. Виділення динамічного зберігання: опитування та критичний огляд. У працях Міжнародного семінару 1995 року з управління пам’яттю, Springer Verlag LNCS, 1995
• Марк С. Джоунстон, Пол Р. Вілсон. Проблема фрагментації пам'яті: вирішено? У повідомленнях ACM SIG-PLAN, том 34 № 3, стор. 26-36, 1999
• М. Р. Гері, Р. Л. Грехем та Дж. Д. Уллман. Найгірший аналіз алгоритмів розподілу пам'яті. У четвертому щорічному симпозіумі ACM з теорії обчислень, 1972

Оновлення:
Google TCMalloc: Caching Thread Malloc
Виявлено, що він досить добре справляється з фрагментацією в тривалому процесі.

Я розробляв серверну програму, яка мала проблеми з фрагментацією пам'яті на HP-UX 11.23 / 11.31 ia64.

Це виглядало так. Був процес, який здійснював розподіл пам’яті та розсилку пам’яті та тривав цілими днями. І незважаючи на те, що не було витоків пам'яті, споживання пам'яті цього процесу постійно зростало.

Про мій досвід. У HP-UX дуже просто знайти фрагментацію пам'яті за допомогою gdb HP-UX. Ви встановлюєте точку перерви, і при натисканні на неї виконайте цю команду: info heapі перегляньте всі розподіли пам'яті для процесу та загальний розмір купи. Потім продовжуйте свою програму, а потім через деякий час знову потрапили до точки зламу. Ви знову info heap. Якщо загальний розмір купи більший, але кількість та розмір окремих розподілів однакові, то, ймовірно, у вас є проблеми з розподілом пам'яті. При необхідності зробіть цю перевірку кілька разів.

Мій шлях покращення ситуації був таким. Після того, як я зробив деякий аналіз з HP-UX gdb, я побачив, що проблеми з пам'яттю викликані тим, що я використовував std::vectorдля зберігання деяких типів інформації з бази даних. std::vectorвимагає, щоб його дані зберігалися в одному блоці. У мене було кілька контейнерів на основі std::vector. Ці контейнери регулярно відтворювали. Часто траплялися ситуації, коли в базу даних додавались нові записи, після чого контейнери були відтворені. А оскільки відтворені контейнери були більшими, вони не вміщувались у доступні блоки вільної пам’яті, а час виконання запитував про новий більший блок від ОС. Як результат, навіть не було витоків пам'яті, споживання пам'яті в процесі зросло. Я покращив ситуацію, коли змінив контейнери. Замість цього std::vectorя почав використовуватиstd::deque який має інший спосіб розподілу пам'яті для даних.

Я знаю, що один із способів уникнути фрагментації пам’яті на HP-UX - це використання Small Block Allocator або використання MallocNextGen. У RedHat Linux алокатор за замовчуванням, схоже, справляється з виділенням безлічі маленьких блоків. У Windows є, Low-fragmentation Heapі він вирішує проблему великої кількості невеликих виділень.

Я розумію, що у важкому для STL додатку ви повинні спочатку виявити проблеми. Алокатори пам’яті (як у libc) насправді вирішують проблему безлічі невеликих виділень, що характерно для std::string(наприклад, у моєму серверному застосуванні є багато рядків STL, але, як я бачу, із запуску info heapвони не викликають жодних проблем). Моє враження, що вам потрібно уникати частих великих виділень. На жаль, бувають ситуації, коли ви не можете їх уникнути, і вам доведеться змінити код. Як я кажу у своєму випадку, я покращив ситуацію, коли перейшов std::deque. Якщо ви визначите фрагментацію пам’яті, можливо, про неї можна поговорити точніше.

Фрагментації пам'яті, швидше за все, відбудеться , коли ви виділяєте і звільнити безліч об'єктів різних розмірів. Припустимо, у вас є така пам’ятка в пам’яті:

obj1 (10kb) | obj2(20kb) | obj3(5kb) | unused space (100kb)

Тепер, коли obj2випущено, у вас є 120 кб невикористаної пам’яті, але ви не можете виділити повний блок у 120 кбіт, оскільки пам'ять фрагментарна.

Загальні методи уникнення цього ефекту включають кільцеві буфери та об'єкти пули . У контексті STL подібні методи std::vector::reserve()можуть допомогти.

Дуже детальну відповідь щодо фрагментації пам'яті можна знайти тут.

http://library.softwareverify.com/memory-fragmentation-your-worst-nightmare/

Це є кульмінацією 11 років відповідей на фрагментацію пам’яті, які я давав людям, які задавали мені питання щодо фрагментації пам’яті на сайті softwareverify.com

Що таке фрагментація пам'яті?

Коли ваша програма використовує динамічну пам'ять, вона виділяє та звільняє шматки пам'яті. На початку весь простір пам’яті вашого додатка - це один суміжний блок вільної пам’яті. Однак, коли ви виділяєте та вільні блоки різного розміру, пам’ять починає роздроблено , тобто замість великого суміжного вільного блоку та декількох сусідніх виділених блоків буде виділено виділений та вільний блоки. Оскільки вільні блоки мають обмежений розмір, їх важко повторно використовувати. Наприклад, у вас може бути 1000 байт вільної пам'яті, але ви не можете виділити пам'ять для 100-байтного блоку, оскільки всі вільні блоки мають довжину не більше 50 байт.

Іншим, неминучим, але менш проблематичним джерелом фрагментації є те, що в більшості архітектур адреси пам'яті повинні бути вирівняні до 2, 4, 8 і т.д. байтових меж (тобто адреси повинні бути кратними 2, 4, 8 і т.д.) Це означає, що навіть якщо у вас є, наприклад, структура, що містить 3 charполя, ваша структура може мати розмір 12 замість 3, через те, що кожне поле вирівняне до 4-байтової межі.

Як я можу визначити, чи є фрагментація пам'яті проблемою для мого додатка? Яка програма найбільше страждає?

Очевидна відповідь полягає в тому, що ви позбулися виключення з пам'яті.

Мабуть, немає хорошого портативного способу виявлення фрагментації пам'яті в додатках C ++. Дивіться цю відповідь для отримання більш детальної інформації.

Які хороші поширені способи боротьби з фрагментацією пам'яті?

У C ++ це важко, оскільки ви використовуєте прямі адреси пам'яті в покажчиках, і у вас немає контролю над тим, хто посилається на конкретну адресу пам'яті. Тому перестановка виділених блоків пам’яті (як це робить збирач сміття Java) - це не варіант.

Спеціальний розподільник може допомогти, керуючи розподілом невеликих об'єктів у більшій частині пам’яті та повторно використовуючи вільні слоти в межах цього фрагменту.

Це супер спрощена версія для муляжів.

Коли об’єкти створюються в пам'яті, вони додаються до кінця використовуваної частини пам'яті.

Якщо об’єкт, який не знаходиться в кінці використовуваної частини пам'яті, буде видалений, тобто цей об’єкт знаходився між двома іншими об'єктами, він створить "дірку".

Це те, що називається фрагментація.

Коли ви хочете додати елемент на купі, то трапляється те, що комп'ютер повинен здійснити пошук місця, щоб вмістити його. Ось чому динамічні асигнування, якщо вони не виконуються в пулі пам'яті або з об'єднаним розподільником, можуть "уповільнити" справи. Для важкого додатка STL, якщо ви робите багатопотокові, є верстат Hoard або версія TBB Intel .

Тепер, коли пам'ять фрагментована, можуть статися дві речі:

1. Потрібно буде більше пошуків, щоб знайти хороший простір для приклеювання «великих» об’єктів. Тобто, при безлічі дрібних предметів, розкиданих щодо пошуку приємного суміжного шматка пам'яті, за певних умов може бути важко (це надзвичайно.)
2. Пам'ять - це не просто легко читається сутність. Процесори обмежуються тим, скільки вони можуть утримувати і де. Вони роблять це, міняючи сторінки, якщо потрібний їм предмет - одне місце, а поточні адреси - інше. Якщо вам постійно доводиться міняти сторінки, обробка може сповільнитись (знову ж, екстремальні сценарії, де це впливає на продуктивність.) Дивіться цю публікацію у віртуальній пам'яті .

Фрагментація пам'яті відбувається через те, що запитуються блоки пам'яті різного розміру. Розглянемо буфер у 100 байт. Ви вимагаєте дві знаки, а потім ціле число. Тепер ви звільняєте два знаки, а потім запитуєте нове ціле число, але це ціле число не може вміститися в просторі двох символів. Цю пам’ять неможливо повторно використовувати, оскільки вона не знаходиться у досить великому суміжному блоці для її перерозподілу. Крім того, ви попросили багато накладних витрат для своїх знаків.

По суті, в більшості систем пам'ять постачається лише в блоках певного розміру. Після того, як ви розділите ці блоки вгору, вони не зможуть повторно з'єднатися, поки весь блок не буде звільнений. Це може призвести до використання цілих блоків, коли фактично використовується лише невелика частина блоку.

Основний спосіб зменшити фрагментацію купи - зробити більші, рідше виділення. В крайньому випадку, ви можете використовувати керовану купу, яка здатна переміщувати об'єкти, принаймні, у межах вашого власного коду. Це повністю усуває проблему - так чи інакше, з точки зору пам'яті. Очевидно, що рухомі предмети і такі мають вартість. Насправді у вас є справді проблема, якщо ви часто виділяєте дуже невеликі суми з купи. Використання суміжних контейнерів (вектор, рядок тощо) та виділення на стеці якомога по-людськи (завжди хороша ідея для продуктивності) - найкращий спосіб зменшити його. Це також збільшує узгодженість кешу, що робить ваш додаток швидшим.

Що вам слід пам’ятати, це те, що на 32-бітній настільній системі x86 у вас є цілий об'єм пам’яті 2 Гб, який розділений на 4 сторінки «сторінок» (майже впевнений, що розмір сторінки однаковий у всіх системах x86). Вам доведеться викликати деякі фрагменти omgwtfbbq, щоб виникнути проблеми. Фрагментація справді є проблемою минулого, оскільки сучасні купи надмірно великі для переважної більшості застосувань, і є поширеність систем, здатних протистояти цьому, наприклад керованих купи.

Яка програма найбільше страждає?

Приємним (= жахливим) прикладом для проблем, пов’язаних з фрагментацією пам'яті, була розробка та випуск "Elemental: War of Magic" , комп’ютерної гри Stardock .

Гра була побудована на 32-бітну / 2 Гб пам’яті і довелося багато оптимізувати управління пам’яттю, щоб гра працювала в межах цих 2 Гб пам’яті. В якості «оптимізації» призводить до постійного виділенню і де-розподілу, по фрагментації купи пам'яті часу стався і зробили гру аварія кожен раз .

На YouTube є інтерв’ю "Історія війни" .