Эффективно удаляйте 10M + файлов из ZFS


30

Я написал программу с ошибками, которая случайно создала около 30 миллионов файлов в каталоге / tmp. (Ошибка была введена несколько недель назад и создавала пару подкаталогов в секунду.) Я мог переименовать / tmp в / tmp2, и теперь мне нужно удалить файлы. Система FreeBSD 10, корневая файловая система zfs.

Тем временем один из дисков в зеркале вышел из строя, и я заменил его. Диск имеет два 120 ГБ SSD-диска.

Вот вопрос: замена жесткого диска и восстановление всего массива заняли меньше часа. Удаление файлов / tmp2 - это другая история. Я написал другую программу для удаления файлов, и она может удалять только 30-70 подкаталогов в секунду. Удаление всех файлов займет 2-4 дня.

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня? Почему у меня такая плохая производительность? 70 удалений в секунду - очень плохая производительность.

Я могу удалить inode для / tmp2 вручную, но это не освободит место, верно?

Может ли это быть проблемой с zfs, жесткими дисками или чем?


1
Я не эксперт по zfs, поэтому я не могу говорить о вашей настройке производительности или о том, что вы могли бы сделать, чтобы улучшить ее (это также потребовало бы много информации и, вероятно, лучше всего было бы сделать это непосредственно экспертом). Тем не менее, я могу сказать, что повторное преобразование происходит на уровне блоков, а удаление происходит на уровне файловой системы. Файловая система будет иметь большую нагрузку при удалении таких пакетов с миллиардным индексом.
Спулер

Пожалуйста, оставьте свои df -hи zpool listи zfs list.
ewwhite

5
Написана другая программа: rm -rf /tmp2не сделаете работу?
Турбьёрн Равн Андерсен

2
Не могли бы вы просто перезагрузиться? /tmpдолжна быть tmpfsфайловой системой и храниться в памяти.
Блендер

Ответы:


31

Удаление в ZFS стоит дорого. Тем более, если в файловой системе включена дедупликация (поскольку разыменование дедуплицированных файлов обходится дорого). Снимки тоже могут усложнить ситуацию.

Возможно, вам лучше удалить /tmpкаталог, а не данные, содержащиеся в нем.

Если /tmpэто файловая система ZFS, удалите ее и создайте заново.


1
@nagylzs В этом случае я бы предложил создать отдельную файловую систему ZFS. Затем вы можете убрать текущий / tmp с пути, переместить новый / tmp на место и удалить файлы на досуге системы. Результат: минимальное время простоя плюс небольшое снижение производительности (можно уменьшить ionice, если оно есть во FreeBSD) во время удаления.
резюме

9
Я был неправ. Это была отдельная файловая система. Вот что сработало: перезагрузитесь в однопользовательский режим, затем выполните «zfs delete zroot / tmp; zfs create zroot / tmp; chmod 41777 / tmp»
nagylzs

6
Общее время простоя составило 5 минут. Фантастика! :-)
nagylzs

1
Что ж, это также говорит о моей озабоченности тем, что удаление фиков никогда не освобождает место из-за снимков. Но tmp будет настроен так, чтобы не делать автоматические периодические снимки, верно ?
JDługosz

1
На самом деле это было: zfs создать -o сжатие = on -o exec = on -o setuid = off zroot / tmp; chmod 1777 / zroot / tmp; zfs set mountpoint = / tmp zroot / tmp; Я не уверен, как отключить автоматические снимки, хотя. Существует "zfs set com.sun: auto-snapshot = false", но это работает только на солярисе, я думаю.
nagylzs 6.09.16

27

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня?

Рассмотрим офисное здание.

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

Разрушить все здание с гексогеном это гораздо быстрее, но следующий клиент вполне вероятно, жалуется , как сквозняк места есть.


5
ZFS - это не офисное здание :)
developerbmw

9
@developerbmw там тоже нет ни файла, ни папки, но нам нужны метафорические понятия, чтобы понять, что происходит.
Джеймс Райан

2
@JamesRyan Да, на самом деле это хорошая аналогия ... Я просто был глупым
developerbmw

5

Здесь происходит много вещей.

Во-первых, все современные дисковые технологии оптимизированы для массовых переносов. Если вам нужно переместить 100 МБ данных, они сделают это намного быстрее, если они будут в одном непрерывном блоке, а не разбросаны повсюду. SSD здесь очень помогают, но даже они предпочитают данные в смежных блоках.

Во-вторых, повторное переключение является довольно оптимальным с точки зрения дисковых операций. Вы читаете массивный непрерывный кусок данных с одного диска, выполняете несколько быстрых операций ЦП на нем, а затем переписываете его в другой большой непрерывный блок на другой диск. Если в течение некоторого времени происходит сбой питания, ничего страшного - вы просто проигнорируете любые данные с неверными контрольными суммами и продолжите работу, как обычно.

В-третьих, удаление файла очень медленно . ZFS особенно плох, но практически все файловые системы медленно удаляются. Они должны изменить большое количество различных фрагментов данных на диске и правильно рассчитать их время (т. Е. Ждать), чтобы файловая система не была повреждена при сбое питания.

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня?

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

70 удалений в секунду - очень плохая производительность

Это зависит. Я бы не удивился этому. Вы не упомянули, какой тип SSD вы используете. Современные твердотельные накопители Intel и Samsung довольно хорошо справляются с такой операцией (чтение-изменение-запись) и будут работать лучше. Более дешевые / старые SSD (например, Corsair) будут работать медленно. Количество операций ввода-вывода в секунду (IOPS) является определяющим фактором здесь.

ZFS является особенно медленно удалить вещи. Обычно он выполняет удаление в фоновом режиме, поэтому вы не видите задержку. Если вы делаете огромное количество из них, это не может скрыть это и должно задержать вас.


Приложение: почему удаление происходит медленно?

  • Удаление файла требует нескольких шагов. Метаданные файла должны быть помечены как «удаленные», и в конечном итоге они должны быть восстановлены, чтобы пространство можно было использовать повторно. ZFS - это «файловая система со структурой журналов», которая работает лучше всего, если вы когда-либо только создаете вещи, но никогда не удаляете их. Структура журнала означает, что если вы что-то удаляете, в журнале есть пробел, поэтому другие данные должны быть перегруппированы (дефрагментированы), чтобы заполнить этот пробел. Это невидимо для пользователя, но обычно медленно.
  • Изменения должны быть сделаны таким образом, чтобы в случае сбоя питания на полпути файловая система оставалась согласованной. Часто это означает ожидание, пока диск не подтвердит, что данные действительно находятся на носителе; для SSD это может занять много времени (сотни миллисекунд). Чистый эффект этого заключается в том, что ведется гораздо больше бухгалтерии (т.е. операций ввода-вывода на диске).
  • Все изменения небольшие. Вместо того, чтобы читать, записывать и стирать целые флэш-блоки (или цилиндры для магнитного диска), вам нужно немного изменить один из них. Для этого оборудование должно прочитать весь блок или цилиндр, изменить его в памяти, а затем снова записать на носитель. Это занимает много времени.

Я не знаю о ZFS, но некоторые файловые системы позволяют вам отсоединить каталог с содержимым, но это содержимое будет удалено позже во время фазы сборки мусора / defrag / cleanup. Есть ли в ZFS какие-либо утилиты для такого ленивого удаления? Это на самом деле не ускорит удаление OP, но, вероятно, сделает его менее проблематичным, если это произойдет неявно во время ведения домашнего хозяйства.
Vality

2

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня?

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

Почему у меня такая плохая производительность? 70 удалений в секунду - очень плохая производительность.

Это должно сделать много бухгалтерии ...

Я могу удалить inode для / tmp2 вручную, но это не освободит место, верно?

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

Может ли это быть проблемой с zfs, жесткими дисками или чем?

Что- zfs scrubнибудь говорит?


2

Удаление большого количества файлов никогда не бывает быстрой операцией.

Чтобы удалить файл в любой файловой системе, необходимо прочитать индекс файла, удалить (или пометить как удаленный) запись файла в индексе, удалить любые другие метаданные, связанные с файлом, и отметить пространство, выделенное для файла, как неиспользованными. Это должно быть сделано индивидуально для каждого удаляемого файла, что означает, что удаление большого количества файлов требует большого количества небольших операций ввода-вывода. Делать это таким образом, который обеспечивает целостность данных в случае сбоя питания, добавляет еще больше накладных расходов.

Даже без учета особенностей ZFS удаление 30 миллионов файлов обычно означает более ста миллионов отдельных операций ввода-вывода. Это будет занимать много времени , даже с быстрым SSD. Как уже упоминалось, дизайн ZFS еще больше усугубляет эту проблему.


2

Ян Хоусон дает хороший ответ о том, почему это медленно.

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

Так что попробуйте:

find /tmp -print0 | parallel -j100 -0 -n100 rm

и посмотрите, работает ли он лучше, чем ваши 70 удалений в секунду.


0

Очень просто, если вы измените свое мышление.

  1. Получить второй диск (у вас, кажется, уже есть)

  2. Скопируйте все с диска A на диск B с помощью rsync, за исключением каталога / tmp. Rsync будет медленнее, чем блочная копия.

  3. Перезагрузитесь, используя диск B в качестве нового загрузочного тома

  4. Переформатировать диск А.

Это также дефрагментирует ваш диск и даст вам новый каталог (хорошо, дефрагментация не так важна для SSD, но линеаризация ваших файлов никогда не повредит)


Прежде всего, скопируйте все, кроме / TMP? Итак, включая / dev и / proc? Во-вторых, звучит немного глупо для меня, особенно на производственном сервере.
Хеннес

Я предполагаю, что он достаточно умен, чтобы исключить не файлы, подключенные тома и папку виртуальной памяти, большинство из которых не может быть угадано здесь. Или сделайте это из загрузочного пакета, где ничего из этого не имеет значения.
Питер

Я думаю, что вы также можете zfs send/recv(копировать на уровне блоков) все другие файловые системы, кроме корневой файловой системы (где в данном случае находится / tmp), и вручную копировать оставшиеся данные в корневой файловой системе (за исключением, конечно, / tmp).
user121391

2
Это позволит потерять снимки и обойти некоторые функции надежности. Пропускает смысл использования ZFS.
JDługosz

2
@ JDługosz действительные баллы, но уместно только если пользователь заботится. Вроде как "мои резервные копии повреждены, как восстановить?" -> "Вам нужны какие-либо резервные файлы?" -> «Нет» -> «Переформат».
Питер

-1

У вас есть 30 миллионов записей в несортированном списке. Вы сканируете список на предмет записи, которую хотите удалить, и удаляете ее. Теперь в вашем несортированном списке есть только 29 999 999 записей. Если они все находятся в / tmp, почему бы просто не перезагрузиться?


Отредактировано, чтобы отразить информацию в комментариях: Формулировка проблемы: удаление большинства, но не всех , неправильно созданных 30M + файлов в / tmp занимает много времени.
Проблема 1) Лучший способ удалить большое количество нежелательных файлов из / tmp.
Проблема 2) Понимание, почему это так медленно, чтобы удалить файлы.

Решение 1) - / tmp сбрасывается в пустую при загрузке большинством * nix-дистрибутивов. FreeBSD, однако, не является одним из них.
Шаг 1 - скопируйте интересные файлы в другое место.
Шаг 2 - как root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Шаг 3 - перезагрузка.
Шаг 4 - измените clear_tmp_enable обратно на «Нет».
Нежелательные файлы теперь исчезли, так как ZFS во FreeBSD имеет функцию, заключающуюся в том, что «Уничтожение набора данных происходит гораздо быстрее, чем удаление всех файлов, которые находятся в наборе данных, так как не включает сканирование всех файлов и обновление всех соответствующих метаданных. " поэтому все, что нужно сделать во время загрузки, - сбросить метаданные для набора данных / tmp. Это очень быстро.

Решение 2) Почему это так медленно? ZFS - замечательная файловая система, которая включает в себя такие функции, как постоянный доступ к каталогам. Это хорошо работает, если вы знаете, что делаете, но факты свидетельствуют о том, что ОП не является экспертом ZFS. ОП не указал, как они пытались удалить файлы, но я бы сказал, что они использовали вариант «find regex -exec rm {} \;». Это хорошо работает с небольшими числами, но не масштабируется, потому что выполняются три последовательные операции: 1) получить список доступных файлов (возвращает 30 миллионов файлов в порядке хеширования), 2) использовать regex, чтобы выбрать следующий файл, который нужно удалить, 3 ) скажите ОС найти и удалить этот файл из списка 30 миллионов. Даже если ZFS возвращает список из памяти и если 'find' кэширует его, регулярное выражение все равно должно идентифицировать следующий файл, который будет обработан из списка, а затем сказать ОС обновить свои метаданные, чтобы отразить это изменение, а затем обновить список, чтобы он не обрабатывался снова.


1
Я думаю, вы неправильно поняли вопрос. Мне нужно было удалить большинство файлов. То есть 30M + файлов.
nagylzs 6.09.16

@nagylzs / tmp очищается при перезагрузке. Если вы хотите удалить большинство , то вам нужно оставить только некоторые , то есть менее половины, поэтому скопируйте те, которые вы хотите сохранить, а затем перезагрузите компьютер, чтобы избавиться от остальных. Причина, по которой ваши удаления происходят так медленно, заключается в том, что наличие большого количества файлов в каталоге приводит к большому несортированному списку, который необходимо обработать, чтобы найти файл, с которым нужно работать, что занимает много времени. Единственная проблема здесь - PEBCAK.
Пол Смит

ZfS каталоги НЕСОРТИРОВАННАЯ ? Я думал, что zfs определенно хорошо справляется с большими каталогами.
JDługosz

Ну, / tmp не очищается, только файлы, связанные с X. По крайней мере, на FreeBSD. Его все равно нельзя очистить при загрузке, потому что для удаления скрипта rc потребуется несколько дней.
nagylzs 6.09.16

@JDlugosz - ZFS намного лучше большинства, но списки инодов (то есть все каталоги) не отсортированы.
Пол Смит
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.