Діагностика помилок кешу та запобігання втраті даних у Windows

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

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

Що таке кеш у Windows і чому він може спричиняти проблеми?

Кеш, як у апаратні засоби Як і в програмному забезпеченні, це, по суті, швидка область зберігання, де зберігаються дані для пришвидшення подальшого доступу.У процесорах та пам'яті ми говоримо про кеші L1, L2 або L3; Операційна система Як і у Windows, кеш файлів системи зберігає дані диска, які, ймовірно, будуть прочитані знову, зменшуючи час повільного доступу. зберігання фізичні

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

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

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

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

Лічильники ключів для моніторингу кешу файлів у Windows

До появи Windows Server 2012 існували дві типові проблеми, які призводили до неконтрольованого зростання кешу файлів. доки доступна пам'ять практично не вичерпається. Хоча архітектура була покращена в останніх версіях, все ще корисно знати, які лічильники слід контролювати для виявлення подібних ситуацій.

Найважливішими лічильниками продуктивності для моніторингу цих сценаріїв є:

• Пам'ять\Довгостроковий середній час життя кешу в режимі очікування (с)Середній довгостроковий час служби резервної пам'яті. Якщо це значення залишається меншим за 1800 секунд (30 хвилин), це вказує на те, що резервні сторінки перезавантажуються занадто швидко, оскільки системі не вистачає пам'яті.
• Доступна пам'ять (байти / кілобайти / мегабайти)Це відображає обсяг доступної пам'яті в системі. Постійно низькі значення в поєднанні з високим використанням системного кешу зазвичай є попереджувальним сигналом.
• Резидентні байти кешу пам'яті/системиЦе вказує на обсяг фізичної пам’яті, який використовується кешем системних файлів. Якщо це значення становить дуже велику частку від загального обсягу оперативної пам’яті, а доступної пам’яті мало, кеш може бути завеликим.

Якщо ви помітили, що обсяг доступної пам'яті низький, і водночас обсяг резидентного кешу системи (Memory\System Cache Resident Bytes) займає значну частину оперативної пам'яті.Наступний крок – з’ясувати, для чого саме використовується цей кеш. Для цього RAMMap є важливим інструментом.

Використовуйте RAMMap для визначення того, що заповнює кеш файлів

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

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

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

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

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

Вплив FILE_FLAG_RANDOM_ACCESS та найкращих практик застосування

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

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

Така поведінка, у поєднанні з багатьма відкриттями великих файлів та справді випадковим доступомЦе може призвести до надмірного зростання системного кешу. Хоча у Windows Server 2012 та пізніших версіях запроваджено покращення обрізання робочої області, постачальник програми зрештою несе відповідальність за виправлення цієї проблеми.

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

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

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

Застарілий поріг сторінок у віддалених файлах та ризик очікування

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

У версіях, що передували Windows Server 2016, коли було досягнуто порогу кількості застарілих (брудних) сторінок, кешованих для віддаленого файлу.Додаткові записи оброблялися так, ніби це були одночасні записи. Це призводило до запису величезної кількості даних на диск, а якщо ємності сховища було недостатньо, виникала значна затримка і навіть переривання мережевого з’єднання.

Щоб вирішити цю проблему, Windows Server 2016 запроваджує окреме порогове значення застарілих сторінок для віддалених записів.Коли цей поріг перевищено, система виконує онлайн-очищення диска, тобто записує дані поступово, щоб уникнути величезних піків, які можуть перевантажити підсистему зберігання.

Цей механізм може спричиняти деяке уповільнення під час періодів дуже інтенсивного письма.Але натомість це значно зменшує ймовірність того, що віддалений клієнт зіткнеться з тайм-аутом через занадто велику кількість даних, що очікують запису.

Значення за замовчуванням для цього віддаленого порогу становить 5 ГБ на файл.Залежно від конфігурації обладнання та робочого навантаження, може бути доцільним його налаштувати: у деяких середовищах вище обмеження дає кращі результати, в інших краще залишити значення за замовчуванням.

Як налаштувати RemoteFileDirtyPageThreshold у реєстрі

Якщо обмеження в 5 ГБ не відповідає вашим потребам, ви можете змінити поріг віддаленої застарілої сторінки за допомогою реєстру Windows.Цей параметр контролюється значенням RemoteFileDirtyPageThreshold.

• Ключовий шлях: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
• вид: DWORD
• Назва значення: RemoteFileDirtyPageThreshold
• Дані: кількість сторінок, де кожна сторінка еквівалентна розміру сторінки, керованому менеджером кешу (зазвичай 4096 байт).

Щоб обчислити правильне значення, потрібно перетворити потрібну кількість байтів на кількість сторінок.Наприклад, якщо ви хочете встановити поріг на 10 ГіБ, спочатку обчислюєте 10 737 418 240 байт / 4096 = 2 621 440 сторінок; це десяткове значення, яке слід ввести в параметр DWORD.

Загальні рекомендації вказують на роботу в безпечному діапазоні від 128 МБ до 50% доступної пам'яті.завжди перетворюється на сторінки. В ідеалі ліміт слід збільшувати з кроком 256 МБ, вимірюючи продуктивність після кожної зміни, доки не буде знайдено точку рівноваги.

Зверніть увагу, що будь-яка зміна RemoteFileDirtyPageThreshold вимагає перезавантаження комп'ютера. щоб нове значення набуло чинності. Без скидання система продовжуватиме використовувати раніше активний поріг.

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

Виявлення вичерпання пам'яті та події 2004 у Windows

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

Типовий приклад події 2004 року (Microsoft-Windows-Resource-Exhaustion-Detector) Він містить повідомлення про те, що Windows успішно діагностувала стан низького рівня віртуальної пам'яті, і перелічує програми, які споживали найбільше пам'яті на цей момент, з іменем їх виконуваного файлу, PID та кількістю зафіксованих байтів.

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

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

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

Використання VMMap для класифікації типу витоку пам'яті

Коли є підозра на витік пам'яті, першим кроком є ​​визначення того, який тип пам'яті неконтрольовано зростає.Для цієї мети VMMap є дуже корисним інструментом, оскільки він розбиває використання пам'яті процесом на категорії: приватні дані, купи, зображення, стеки тощо.

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

Коли доступний дамп пам'яті процесу, WinDbg можна використовувати для виконання команди !address -summary.У резюме проблемна віртуальна пам'ять розподілу зазвичай відображається в категорії , що вказує на великі некласифіковані області пам'яті, які займають дуже значну частину зайнятого простору.

Якщо витік пов'язаний з купою процесу, це буде відображено в категоріях купи у VMMap.Використання купи пам'яті буде постійно зростати з часом. el tiempo, без помітної віддачі.

Знову ж таки, з дампом та !address -summary у WinDbg, у цих випадках дуже високий відсоток буде позначено як Heap32 або Heap64.Залежно від архітектури процесу. Решта категорій (зображення, стеки тощо) становитимуть значно меншу частку загального використання.

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

Збирайте трасування за допомогою WPR для віртуальної пам'яті розподілу

Щойно стане зрозуміло, що відбувається віртуальний витік розподілу, наступним кроком буде збір відтворюваних даних, які показують, хто здійснює ці резервування.Для цієї мети можна використовувати засіб запису продуктивності Windows (WPR), який вбудований у Windows 10 та Windows Server 2016.

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

C:\>wpr -start VirtualAllocation

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

C:\>wpr -stop virtalloc.etl

Цей файл virtualloc.etl міститиме події віртуального розподілу, які потім будуть проаналізовані за допомогою аналізатора продуктивності Windows (WPA)., що дозволяє побачити, які функції та модулі знаходяться за резервуваннями пам'яті, які не звільнено.

Збирайте трасування за допомогою WPR для купи пам'яті

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

Ви можете змінити реєстр вручну або скористатися WPR для налаштування цільового бінарного файлу.Наприклад, щоб увімкнути трасування купи для VirtMemTest32.exe, запустіть його з командного рядка з правами адміністратора:

C:\>wpr -heaptracingconfig VirtMemTest32.exe enable

Ця команда створює ключ конфігурації під HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\VirtMemTest32.exe, зі значенням DWORD під назвою Tracing Flags, яке зазвичай встановлюється на 1, що дозволяє трасування купи для цього виконуваного файлу.

Після етапу діагностики важливо знову деактивувати відстеження.або видаливши ключ, або встановивши значення прапорців трасування на 0, щоб уникнути непотрібних накладних витрат часу виконання.

З застосованою конфігурацією, захоплення трасування купи виконується за допомогою:

C:\>wpr -start Heap

Як і у випадку з віртуальним розподілом, процес може тривати кілька хвилин, поки спостерігається розмір підтвердження.Оскільки реєструються лише події купи, розмір трасування є керованим у більшості сценаріїв.

C:\>wpr -stop Heap.etl

Результатом є файл Heap.etl, що містить події розподілу та вивільнення купиякі потім будуть вивчені за допомогою WPA для визначення стеків викликів, відповідальних за витоки.

Аналіз трасування за допомогою аналізатора продуктивності Windows (WPA)

Останнім кроком у процесі діагностики є відкриття трасування .etl за допомогою аналізатора продуктивності Windows., інструмент, що входить до складу набору інструментів підвищення продуктивності Windows, який, у свою чергу, є частиною ADK (комплекту оцінки та розгортання).

Перш ніж розпочати аналіз даних, важливо правильно налаштувати шляхи символів.щоб стеки викликів розв'язувалися з іменами функцій, зрозумілими для людини. У WPA це робиться в меню Трасування > Налаштувати шляхи символів, додаючи шлях, подібний до:

srv*C:\LocalPubSymbols*https://msdl.microsoft.com/download/symbols

Після налаштування символів вони завантажуються через меню символів і відкриваються відповідний файл .etl.У разі витоків віртуального розподілу слід відтворити представлення, зосереджене на проблемному процесі, переконавшись, що стовпець «Стек фіксацій» знаходиться ліворуч від золотої або жовтої лінії сітки.

Розгортання стеків комітів визначає функції, які створюють віртуальні призначення які не звільняються. Модуль, який з'являється безпосередньо над функцією розподілу на стеку, зазвичай є логічним модулем, який неодноразово запитує пам'ять.

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

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

Збої кешу веб-застосунків та як їх зменшити

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

На відміну від цього, потрапляння до кешу відбувається, коли вміст отримується безпосередньо з кешу.Чи то в пам'яті, на диску, чи на рівні сервера. Чим більше звернень до кешу, тим швидші відповіді; чим більше промахів, тим вища затримка та більше навантаження нестиме сервер і база даних.

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

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

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

Практичні стратегії для зменшення збоїв кешу у веб-середовищі

Щоб зменшити частоту промахів кешу на веб-сайті, метою є якомога довше зберігати відповідні дані в кеші.завжди балансуючи між продуктивністю та свіжістю контенту.

Одна з основних тактик полягає у встановленні відповідного часу життя (TTL) для кешу.Щоразу, коли дані видаляються, їх необхідно перераховувати та перезаписувати після наступного запиту, що може призвести до початкових збоїв. Розширення TTL, коли вміст не змінюється часто, допомагає зменшити кількість недійсностей і, отже, менше промахів.

У керованих постачальниках поширеною практикою є очищення певних розділів кешу лише тоді, коли виявляються відповідні зміни.Наприклад, плагіни, подібні до тих, що використовуються деякими спеціалізованими хостинг-провайдерами, очищають кеш лише зміненого запису або певних областей сайту, а не стирають весь кеш сервера.

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

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

Зрештою, дуже корисно вибирати політики заміни кешу, які відповідають шаблону доступу програми.Серед найпоширеніших є FIFO (перший прийшов, перший вийшов), LIFO (останній прийшов, перший вийшов), LRU (найменше використаний) та MRU (найбільше використаний), кожен з яких має свої переваги та недоліки залежно від типу навантаження.

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

На практиці, узгодьте конфігурацію кешування сайту з хостинг-провайдером. Зазвичай це найкращий спосіб налаштувати TTL, політики та ємність, особливо в керованих середовищах, де багато рішень щодо кешу приймаються на рівні сервера.

Розуміння того, як Windows керує кешем і пам'яттю, як діагностувати витоки та проблемні пороги, а також як оптимізувати використання кешу в таких програмах, як WordPress Це дозволяє уникнути вузьких місць, зменшити затримку та мінімізувати ризик втрати даних або тайм-аутів як на локальних серверах, так і в вимогливих веб-середовищах.