Niska wydajność na dysku NTFS z dużą liczbą plików

Patrzę na tę konfigurację:

• Windows Server 2012
• Dysk NTFS 1 TB, klastry 4 KB, pełne ~ 90%
• ~ 10 mln plików przechowywanych w 10 000 folderów = ~ 1000 plików / folder
• Pliki w większości dość małe <50 KB
• Dysk wirtualny hostowany na macierzy dyskowej

Gdy aplikacja uzyskuje dostęp do plików przechowywanych w losowych folderach, odczytanie każdego pliku zajmuje 60–100 ms. Za pomocą narzędzia testowego wydaje się, że opóźnienie występuje podczas otwierania pliku. Odczyt danych zajmuje wtedy ułamek czasu.

Podsumowując, oznacza to, że odczyt 50 plików może z łatwością zająć 3-4 sekundy, czyli znacznie więcej niż oczekiwano. Pisanie odbywa się wsadowo, więc wydajność nie jest tutaj problemem.

Postępowałem już zgodnie z zaleceniami dotyczącymi SO i SF, aby dojść do tych liczb.

• Korzystanie z folderów w celu zmniejszenia liczby plików w folderze ( Przechowywanie miliona obrazów w systemie plików )
• Uruchom, contigaby defragmentować foldery i pliki ( https://stackoverflow.com/a/291292/1059776 )
• 8.3 nazw i czasu ostatniego dostępu wyłączone ( Konfigurowanie systemu plików NTFS pod kątem wydajności )

Co zrobić z czasami czytania?

• Uważaj, że 60-100 ms na plik jest w porządku (tak nie jest, prawda?)
• Wszelkie pomysły, w jaki sposób można ulepszyć konfigurację?
• Czy istnieją narzędzia monitorowania niskiego poziomu, które mogą powiedzieć, na co dokładnie spędza czas?

AKTUALIZACJA

1. Jak wspomniano w komentarzach, system uruchamia Symantec Endpoint Protection. Jednak wyłączenie go nie zmienia czasów odczytu.

2. PerfMon mierzy 10-20 ms na odczyt. Oznaczałoby to, że każdy odczyt pliku wymaga ~ 6 operacji odczytu I / O, prawda? Czy byłoby to wyszukiwanie MFT i kontrole ACL?

3. Rozmiar MFT wynosi ~ 8,5 GB, czyli więcej niż pamięć główna.

Serwer nie miał wystarczającej ilości pamięci. Zamiast buforować dane metapliku NTFS w pamięci, każdy dostęp do pliku wymagał wielu odczytów dysku. Jak zwykle problem jest oczywisty, gdy go zobaczysz. Pozwólcie, że podzielę się tym, co zaciemniło moją perspektywę

• Serwer pokazał 2 GB pamięci dostępnej zarówno w Menedżerze zadań, jak i RamMap. Tak więc albo Windows zdecydował, że dostępna pamięć nie jest wystarczająca do przechowywania znaczącej części danych metapliku. Lub niektóre ograniczenia wewnętrzne nie pozwalają na użycie ostatniego bitu pamięci dla danych metapliku.

• Po uaktualnieniu pamięci RAM Menedżer zadań nie wyświetlał więcej używanej pamięci. Jednak RamMap zgłosił, że wiele GB danych metapliku jest przechowywanych jako dane rezerwowe. Najwyraźniej dane w trybie gotowości mogą mieć znaczący wpływ.

Narzędzia użyte do analizy:

• fsutil fsinfo ntfsinfo driveletter:pokazać rozmiar NTFS MFT (lub NTFSInfo )
• RamMap, aby pokazać przydział pamięci
• Monitor procesu, aby pokazać, że każdy odczyt pliku poprzedza około 4 operacji odczytu na dysk: \ $ Mft i dysk: \ $ Directory. Chociaż nie mogłem znaleźć dokładnej definicji $ Directory, wydaje się, że jest ona również związana z MFT .