Назад | Перейти на главную страницу

Фрагментация диска при работе с большим количеством небольших файлов

Ежедневно мы генерируем около 3,4 миллиона небольших файлов jpeg. Мы также удаляем около 3,4 миллиона изображений 90-дневной давности. На сегодняшний день мы имеем дело с этим контентом, храня изображения в иерархическом порядке. Гериархат выглядит примерно так:

/Year/Month/Day/Source/

Эта иерархия позволяет нам эффективно удалять контент за несколько дней из всех источников.

Файлы хранятся на сервере Windows 2003, подключенном к 14 дискам SATA RAID6.

У нас начались серьезные проблемы с производительностью при записи и чтении с дисков.

Это может быть связано с производительностью оборудования, но я подозреваю, что фрагментация диска может быть виноват ну.

Некоторые люди рекомендовали хранить данные в базе данных, но я не решался это сделать. Другая мысль заключалась в том, чтобы использовать какой-то контейнерный файл, например VHD или что-то в этом роде.

Есть ли у кого-нибудь совет по уменьшению такой фрагментации?

Дополнительная информация:

Средний размер файла 8–14 КБ.

Информация о формате из fsutil:

NTFS Volume Serial Number :       0x2ae2ea00e2e9d05d
Version :                         3.1
Number Sectors :                  0x00000001e847ffff
Total Clusters :                  0x000000003d08ffff
Free Clusters  :                  0x000000001c1a4df0
Total Reserved :                  0x0000000000000000
Bytes Per Sector  :               512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x000000208f020000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0x000000001e847fff
Mft Zone Start :                  0x0000000002163b20
Mft Zone End   :                  0x0000000007ad2000

Из вашего сообщения я предполагаю, что вы храните изображения на 90 дней. Проведя некоторые быстрые подсчеты, окажется, что вам нужно 4,28 ТБ хранилища. На что похожи шаблоны ввода-вывода (т.е. к каким-либо данным обращаются чаще)? На скольких томах разбросаны эти данные? Как быстро производительность снизится до неприемлемого уровня после дефрагментации?

Если вы не желаете вносить изменения в систему (вводя базу данных), возможно, вам следует сосредоточиться на том, как вы можете управлять дефрагментацией с помощью инструментов, которые входят в состав ОС. Поверните и разделите данные на несколько меньших LUN, чтобы можно было дефрагментировать их по отдельности. После того, как вы закончите записывать данные за X дней, перейдите к следующему LUN и дефрагментируйте том с помощью предыдущих X дней. Если вы больше не пишете в него, вам не следует больше вносить фрагментацию.

Если вам предоставили значительный бюджет, вы можете выбрать носитель, устойчивый к фрагментации (например, SSD).

Diskeeper 2009 (теперь 2010) хорошо работает для дефрагментации в реальном времени с минимальным влиянием на производительность. Однако есть цена, так как это коммерческий пакет. Мы попробовали несколько бесплатных приложений и обнаружили серьезные проблемы с производительностью.

Домашняя страница Diskeeper