Плохая производительность NTFS
Почему случается так, что производительность NTFS так паршива по сравнению с, например, Linux/ext3? Чаще всего я вижу это при проверке (больших) исходных деревьев от Подверсии. Контроль занимает приблизительно 10-15 минут на NTFS, в то время как соответствующий контроль на Linux (почти на идентичном оборудовании) берет порядок величины быстрее (1 - 1.5 минуты).
Возможно, это характерно для обработки партии маленьких файлов, и NTFS лучше когда дело доходит до больших файлов, но почему это должно быть? Не был бы, улучшая производительность NTFS для маленьких файлов быть чрезвычайно выгодным для производительности Windows в целом?
Править: Это не предназначено, поскольку "NTFS сосет по сравнению с ext3" подстрекательский вопрос; я действительно интересуюсь тем, почему NTFS работает плохо в определенных случаях. Это - просто плохой дизайн (относительно которого я сомневаюсь), или есть ли другие проблемы, которые играют роль?
3 ответа
NTFS имеет эту вещь, названную Главной файловой таблицей. Звучит действительно здоровым, когда Вы читаете об этом.
Вы видите, что ext3 работает хорошо приблизительно до 95%-го дискового использования, в то время как существование MFT означает, что NTFS действительно не хочет, чтобы Вы использовали больше чем 90% своего диска. Но я предположу, что это не Ваша проблема, и что Ваша проблема со многими операциями на многих маленьких файлах.
Одно из различий здесь - то, что происходит, когда Вы создаете маленький файл. Если файл меньше, чем размер блока, он не записан в свой собственный блок, а скорее хранится в MFT. Это хорошо, если файл остается точно способ, которым это было при создании. На практике, хотя, это означает, что то, когда svn касается файла для создания его, затем добавляет к тому файлу, удаляет из него или просто изменяет его недостаточно для перемещения его в свой собственный блок, операция является довольно медленной. Также просто чтение большого количества маленьких файлов помещает некоторое напряжение на MFT, где они все находятся с кратными числами на блок. Почему это сделало бы это? Это заблаговременно избегает фрагментации и использует больше блоков эффективнее, и в целом это - хорошая вещь.
В ext2 и 3, в отличие от этого, блоки файла для каждого файла хранятся рядом с, где метаданные каталога для каталога, они находятся в (если это возможно, если Ваш диск не фрагментируется, и у Вас есть приблизительно 20% свободного пространства). Это означает, что, поскольку svn открывает каталоги, много блоков кэшируются в основном бесплатно в том кэше 16 МБ на Вашем диске, и с другой стороны в кэше ядра. Те файлы могли бы включать .svn файл и файлы пересмотра для Вашего последнего обновления. Это удобно, так как это вероятно, некоторые файлы svn смотрят на затем. NTFS не добирается, чтобы сделать это, хотя значительные части MFT должны кэшироваться в системе, они не могли бы быть частями, которые Вы захотите затем.
-
1Вы корректны, который это - то, где маленькие файлы живут, но я не уверен, почему это должно поместить напряжение на MFT. Разве это не сделало бы намного легче считать эти файлы, поскольку Вы, как почти гарантируют, вытянете много этих файлов в кэш при получении по запросу какого-либо из них? – ChrisInEdmonton 29.07.2009, 22:38
-
2@ChrisInEdmonton, Это - обновления MFT, которые подчеркивают это, потому что Вы не касаетесь блоков, где соседнее место является свободным, Вы заканчиваете тем, что переместили вещи и также делали недействительным кэшируемые части MFT. Я предоставлю Вам, что на бумаге MFT должен быть очень быстрым способом обработать маленькие файлы. Это просто не подтверждает на практике. – dlamblin 29.07.2009, 22:50
Ну, Ваша конкретная проблема состоит в том потому что
- Сама подверсия прибывает из мира UNIX, версия Windows поэтому принимает подобные рабочие характеристики.
- Производительность NTFS действительно не является большой с огромным количеством маленьких файлов.
То, что Вы видите, является просто артефактом чего-то разработанного для конкретной операционной системы с предположениями производительности на этом операционные системы. Это обычно ломается плохо при взятии к другим системам. Другие примеры разветвились бы по сравнению с поточной обработкой. На UNIX - любит традиционный способ parallizing, что-то должно только породить другой процесс. В Windows, где процессы берут по крайней мере в пять раз дольше для запуска, это - действительно плохая идея.
В целом Вы не можете только взять артефакты конкретной ОС, которую предоставят на любом другом один с весьма другой архитектурой. Также не забывайте, что NTFS имеет много функций файловой системы, которые отсутствовали в файловых системах UNIX, широко используемых в той точке, таких как журналирование и ACLs. Те вещи прибывают в стоимость.
Однажды, когда у меня есть много свободного времени, я планировал записать модуль файловой системы SVN, который использует в своих интересах функции, которые Вы имеете на NTFS, таком как поддержка транзакции (должен устранить "касающиеся миллионы маленькой проблемы файлов"), и чередуйтесь, потоки данных (должен избавить от необходимости отдельного .svn каталог). Это была бы хорошая вещь иметь, но я сомневаюсь, что SVN devs обойдет реализацию таких вещей в обозримом будущем.
Примечание стороны: единственное обновление на большом репозитории SVN, который я использую, взяло приблизительно 250 000 операций файла. Некоторая крошечная речь говорит мне, что это действительно очень для 24 файлов, которые изменились...
-
1Но почему быть производительность NTFS плохо при контакте с огромным количеством маленьких файлов? Это приносить в жертву для получения чего-то еще? – JesperE 29.07.2009, 22:07
Вот информация Microsoft о том, как NTFS работает. Это может быть излишество для того, что Вы ищете, но изучаете, это может пролить некоторый свет на то, с какими сценариями NTFS имеет проблемы.