Файловая система теряет производительность при заполнении?
Контекст вопроса - это компьютер с Windows (поэтому речь идет о файловой системе NTFS), который заполняется данными, которые, вероятно, могут быть удалены. Но я не знаю, стоит ли потратить время на то, чтобы проползти через это, или нам стоит просто дефрагментировать и двигаться дальше.
По сути, "полнота" файловой системы вызывает снижение производительности или это просто фрагментация, которая замедляет процесс? И если это так, имеет ли это существенное значение?
6 ответов
Многие вещи могут повлиять на производительность обслуживания файлов на сервере. Полнота файловой системы - это всего лишь одна из многих вещей, которые могут помочь.
- Сырая пропускная способность диска. Если количество операций ввода-вывода, создаваемых на ваших дисках, превышает их способность поддерживать скорость, это замедлится.
- Шаблоны дискового ввода-вывода. Некоторые диски ведут себя лучше при широком случайном вводе / выводе, чем другие. SATA, например, не так хорошо работает с массивно-случайным вводом / выводом, как диски SAS или SCSI.
- Исчерпание ресурса контроллера диска. Независимо от того, что вы используете для RAID (предположим, что вы используете, а это не просто один диск), есть свои собственные ресурсы. Если вы используете паритет RAID, это процессор ЦП, который ограничивает скорость передачи данных на диск. Кроме того, большинство аппаратных контроллеров имеют собственный встроенный кеш. Это используется для многих вещей, но включает в себя изменение порядка записей для повышения эффективности. Если ввод / вывод будет слишком случайным, ваша карта RAID также не сможет оптимизировать.
- Файловый кеш памяти. Файловые серверы работают лучше, когда они могут полностью кэшировать 100% открытых файлов в памяти. Это позволяет им принимать записи от клиентов и переупорядочивать коммиты на диск таким образом, чтобы сделать их более эффективными. Если вы не можете поместить весь открытый набор файлов в память, для этих операций ввода-вывода придется перейти непосредственно на диск, и вы потеряете это повышение производительности.
- Клиентские локальные ресурсы памяти. Благодаря использованию O pLocks клиенты могут локально кэшировать открытые файлы. Как только несколько клиентов открывают один и тот же файл, сервер сообщает клиенту очистить кэш, и это исчезает. Однако для некоторых рабочих нагрузок это может быть реальной экономией. Если клиенту не хватает места в файловом кеше для кэширования открытых файлов, производительность может заметно ухудшиться при открытии файлов исключительно.
- Фрагментация файловой системы. Сильно фрагментированная файловая система по самой своей природе индуцирует крайне случайную схему ввода-вывода в дисковой подсистеме. Если эта подсистема не может терпеть такого рода схемы ввода / вывода, все становится очень медленным.
- Сгенерированные пользователем шаблоны ввода / вывода. Если ваши пользователи работают с миллионами офисных документов (обычно размером менее 2 МБ), ваши шаблоны доступа будут очень случайными. Если ваши пользователи работают с большими файлами, такими как видеофайлы, геопространственные данные или файлы AutoCAD, ваши пользователи будут генерировать много последовательных операций.
Некоторые из них взаимосвязаны, и много раз это будет множеством проблем, приводящих к проблемам с производительностью. В целом фрагментация файловой системы NTFS оказывает влияние. Эффект наихудший при выполнении больших последовательных чтений из такой файловой системы, как это происходит во время резервного копирования. Влияние на общую производительность обслуживания файлов не так существенно для типичных нагрузок офис-сервер, так как в любом случае это в основном случайный ввод-вывод; а в некоторых случаях вы можете даже увидеть некоторые улучшения производительности с фрагментированной системой по сравнению с полностью дефрагментированной.
Для файлового сервера, хранящего много файлов AutoCAD, фрагментация NTFS будет ощутима для конечных пользователей. Этот сгенерированный пользователем шаблон ввода-вывода является значительно последовательным и, следовательно, уязвим к деградации в результате фрагментации. То, насколько это будет реально затронуто, зависит от того, сколько оперативной памяти имеет сервер для кэширования, и от того, насколько быстрым является базовое хранилище в отношении случайных шаблонов ввода-вывода. Вполне возможно, что базовое хранилище достаточно быстрое, чтобы конечные пользователи не заметили том с 60% фрагментацией. Или это может вызвать насыщение ввода / вывода только 15% фрагмента.
Для файлового сервера, хранящего много простых старых офисных файлов, фрагментация NTFS не будет столь заметна для конечных пользователей. Этот шаблон ввода-вывода пользователя является в значительной степени случайным и минимально подвержен фрагментации. Проблемы возникнут в процессе резервного копирования, поскольку время резервного копирования каждого ГБ будет увеличиваться по мере увеличения фрагментации.
Что подводит меня к моей последней точке. Одна операция ввода-вывода, которая больше всего подвержена фрагментации, - это последовательный ввод-вывод. Большинство серверов подвергаются крупномасштабным последовательным схемам ввода-вывода в процессе резервного копирования. Если у вас возникли проблемы с размещением резервной копии в окне резервного копирования, дефрагментация может помочь ускорить процесс. Ваши нижележащие системы хранения будут определять степень воздействия, которое может оказать фрагментация, а ваши значения фрагментации будут определять степень воздействия, которое она фактически оказывает. Знай свое хранилище.
Фрагментация приведет к некоторой медлительности. В целом, вероятно, пользователь ничего не заметит, если не будет много работать с видео или работать с огромными файлами.
На самом деле, я думаю, что это замедлилось бы, если бы была тонна операций поиска, тысячи крошечных файлов, которые сильно пострадали.
В большинстве случаев с достаточной памятью и процедурой, состоящей из нескольких файлов, ОС будет кэшировать вещи в памяти, и вы не заметите слишком большой разницы. Только отметки покажет.
В конце концов... это еще один вопрос "все зависит". Зависит от больших файлов от маленьких, от моделей использования на компьютере и от того, насколько фрагментированы фрагменты и насколько восприимчивы ваши пользователи к разнице в производительности в несколько секунд.
Ничего не повредит, если вы запустите MyDefrag. Freeware; он также пытается "оптимизировать" расположение файлов в тех областях диска, где доступ будет немного быстрее.
Если вы используете Windows 2008, то вы можете использовать средство дедупликации, которое может освободить некоторые ненужные файлы, которые заполняют ваш жесткий диск
Дефрагментируйте и двигайтесь дальше. Не стоит экономить несколько десятков ГБ. Но, чтобы ответить на ваш вопрос, единственное, что есть на новом диске, это все файлы в начале, поэтому время поиска меньше. Но после его использования файлы могут быть где угодно, поэтому дефрагментация поможет.
Если вы используете менее 80%, не волнуйтесь, просто дефрагментируйте.
Когда он начинает приближаться к 100%, любая файловая система начнет замедляться.
TL;DR: Нет, пока вы не наберете более 75%.
В большинстве случаев заполнение диска не влияет на производительность, пока не будет заполнено более 75%. Это может быть немного отключено в зависимости от использования, но для типичной загрузки рабочей станции это действительно так.
Фрагментация сводится к минимуму, когда все файлы имеют место для размещения. Единственными типами файлов, которые фрагментируются на практически пустом разделе NTFS, являются файлы журналов и метаданные каталогов, поскольку они постоянно расширяются. Если вы часто просматриваете журналы или имеете большую пропускную способность созданных и удаленных файлов, регулярная дефрагментация может быть полезной, даже если диск заполнен меньше.