Невелика продуктивність на диску NTFS з великою кількістю файлів


12

Я переглядаю цю настройку:

  • Windows Server 2012
  • 1 TB накопичувач NTFS, 4 Кб кластери, ~ 90% повно
  • ~ 10М файлів, що зберігаються у 10000 папках = ~ 1000 файлів / папок
  • Файли переважно досить малі <50 Кб
  • Віртуальний диск, розміщений на масиві дисків

Коли програма отримує доступ до файлів, збережених у випадкових папках, для читання кожного файлу потрібно 60-100 мс. З інструментом тестування здається, що затримка виникає при відкритті файлу. Читання даних потім займає лише частину часу.

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

Я вже дотримувався поради щодо SO та SF, щоб дійти до цих цифр.

Що робити з часом читання?

  • Вважайте 60-100 мс у файлі нормальним (це не так?)
  • Будь-які ідеї, як налаштування можна вдосконалити?
  • Чи є інструменти моніторингу низького рівня, які дозволять підказати, на що саме витрачено час?

ОНОВЛЕННЯ

  1. Як зазначалося в коментарях, система працює під управлінням Symantec Endpoint Protection. Однак його відключення не змінює час читання.

  2. PerfMon вимірює 10-20 мс на читання. Це означатиме, що будь-який зчитування файлів займає ~ 6 операцій з читання вводу / виводу, правда? Це буде пошук MFT та перевірка ACL?

  3. Розмір MFT має розмір ~ 8,5 ГБ, що більше, ніж основна пам'ять.


Щоб щось виключати, ви не хочете поділитися скріншотом RAMMap ?
Томаш Дабасінкас

Ви маєте на увазі таблицю "Зведений файл"? Тепер, коли ви згадуєте про це, я бачу файл SYMEFA.DB з пам'яттю 900 Мб, що нагадує мені, що Symantec Endpoint Protection встановлений у системі. Може, це винуватець? Я спробую дізнатися більше.
Пол Б.

Власне, мене більше зацікавило використання метафайлів
Томаш Дабасінкас,

Добре, зрозумів. Метафайл показує всього 250 Мб, 40 активних, 210 очікування. Здається нормально чи ні?
Пол Б.

Так, здається, так
Томаш Дабасінкас

Відповіді:


5

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

  • Сервер показав 2 ГБ пам'яті, доступної як в диспетчері завдань, так і в RamMap. Отже, або Windows вирішила, що наявної пам’яті недостатньо для вмісту значимої частини даних метафайлів. Або деяке внутрішнє обмеження не дозволяє використовувати останній біт пам'яті для даних метафайлів.

  • Після оновлення диспетчер завдань оперативної пам’яті не відображатиме більше використовуваної пам’яті. Однак, RamMap повідомив про декілька ГБ метафайлів, які зберігаються в режимі очікування. Мабуть, дані в режимі очікування можуть мати істотний вплив.

Інструменти, що використовуються для аналізу:

  • fsutil fsinfo ntfsinfo driveletter:показати розмір MFT NTFS (або NTFSInfo )
  • RamMap, щоб показати розподіл пам'яті
  • Монітор процесів, щоб показати, що кожному прочитаному файлу передує близько 4 операцій зчитування для приводу: \ $ Mft та drive: \ $ Directory. Хоча я не зміг знайти точне визначення $ Directory, схоже, він також пов'язаний з MFT .

Так збільшення фізичної пам'яті покращило час реакції? Ви не налаштували жодного параметра реєстру?
D-Klotz

1
Так. Раніше я бавився з налаштуваннями реєстру. Але врешті-решт ніяких змін після додавання пам’яті не потрібно.
Пол Б.

Пам'ять у режимі очікування - це регіони пам'яті, готові до використання програм. Але оскільки вони ще не використовуються, ОС використовуватиме їх як кеш. Після того, як будь-якій програмі потрібна ця пам’ять, вона буде випущена негайно
phuclv
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.