Як зробити `rm` швидше на ext3 / linux?

У мене файлова система ext3 змонтована з параметрами за замовчуванням. На ній у мене є близько ~ 100 ГБ файлів.

Видалення будь-якого з таких файлів займає багато часу (8 хвилин) і спричиняє багато трафіку io, що збільшує навантаження на сервер.

Чи є спосіб зробити RM не таким руйнівним?

Найцікавіша відповідь спочатку була похована в коментарі до питання. Ось це як відповідь першого класу, щоб зробити його більш помітним:

В основному жоден метод звідси не працював, тому ми розробили власний. Описано це тут: http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ - depesz 6 квітня '10 о 15:15

Цей посилання є неймовірно ретельним аналізом розвідки та виявлення працездатного рішення.

Зверніть увагу також:

У статті сказано:

Як бачите, я використовував -c2 -n7варіанти для ionice, які здаються здоровими.

це правда, але користувач TafT каже, що якщо ви не хочете ніяких збоїв, тоді -c3"простоювати" буде кращим вибором, ніж -c2"найкращі зусилля". Він використовував -c3для побудови у фоновому режимі і виявив, що він працює добре, не змушуючи збірку чекати навіки. Якщо ви справді маєте 100% використання io, то -c3видалення не дозволить завершити видалення, але він не очікує, що саме це ви базували на відпрацьованому тесті.

Оновлення до ext4 або іншої сучасної файлової системи, яка використовує розтяжки. Оскільки ext3 використовує схему непрямих блоків, а не розширення, видалення великих файлів неминуче тягне за собою велику роботу.

Ви можете спробувати ionice . Це не зробить це швидше, але може зробити його менш руйнівним.

З точки зору ефективності використання одного rm у файлі не є оптимальним, оскільки для нього потрібні fork та exec для кожного rm.

Припустимо, що у вас є list.txt, який містить файли, які ви хочете видалити, це було б більш ефективно, але все одно буде повільно:

xargs -i rm {} < list.txt

Іншим підходом було б: nice -20 xargs -i rm {} < list.txt
(це займе менше часу, але сильно вплине на вашу систему :)

або

Я не знаю, наскільки це було б швидко, але:

mv <file-name> /dev/null 

або

Створіть спеціальну точку монтажу за допомогою швидкої файлової системи (використовуючи циклічний пристрій?), Використовуйте її для зберігання та видалення величезних файлів.
(можливо, перемістіть файли туди, перш ніж видалити їх, можливо, це швидше або, можливо, просто відключіть їх, коли потрібно, щоб файли пішли)

або

cat /dev/null > /file/to/be/deleted(тож він зараз нульового розміру), і якщо ви хочете, щоб він зник rm -rf <file>зараз

а ще краще

кинь кішку і просто роби # > /file/to/be/emptied

У мене виникли проблеми з отриманням каталогу видалити з розумним темпом, виявляється, процес блокував диск і створював групу процесів, намагаючись отримати доступ до диска. ionice не працювала, вона просто продовжувала використовувати 99% дискового вводу та блокувала всі інші процеси.

Ось код Python, який працював на мене. Він видаляє 500 файлів одночасно, потім робить 2 секунди перерви, щоб інші процеси виконали свою роботу, а потім продовжується. Чудово працює.

import os, os.path
import time

for root, dirs, files in os.walk('/dir/to/delete/files'):
    file_num = 0
    for f in files:
        fullpath = os.path.join(root, f)
        os.remove(fullpath)
        if file_num%500 == 1:
            time.sleep(2)
            print "Deleted %i files" % file_num
        file_num = file_num + 1

Мої два центи.

У мене вже є це питання. "У послідовному скрипті, який потрібно запустити швидко, процес видаляє багато файлу". Отже, "rm" зробить швидкість сценарію близькою до часу очікування / виконання IO.

Щоб зробити це швидше, я додав ще один процес (скрипт bash), запущений за cron .. як сміттєзбірник, він видаляє всі файли в певній директорії.

Потім я оновив оригінальний сценарій, замінивши "rm" mv на "папку сміття" (перейменуйте файл, додавши лічильник у кінці його імені, щоб уникнути зіткнення).

Це працює для мене, сценарій працює як мінімум у 3 рази швидше. але він працює добре лише в тому випадку, якщо папка сміття та оригінальний файл знаходяться під однією і тією ж точкою монтажу (тим же пристроєм), щоб уникнути копіювання файлу. (mv на одному пристрої споживають менше введення, ніж rm)

Сподіваюся, що допоможе ..

Також зауважте, що відповідь Деніса Вільямсона, який пропонує ionice як спосіб вирішення навантаження, буде працювати лише в тому випадку, якщо ваш блоковий пристрій використовує планувальник CFQ io.

Ви можете спробувати створити файлову систему циклу для зберігання резервних копій.

# dd if=/dev/zero of=/path/to/virtualfs bs=100M count=1024 # 100 MB * 1024 = 100 GB
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

Потім, коли потрібно очистити резервні копії:

# umount /mnt/backups
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

Престо! Вся віртуальна файлова система за кілька моментів очищається.

Ви можете використовувати багатоголову з xargs

find . -type f | xargs -P 30 rm -rf 

де 30 - кількість потоків, які ви хочете створити. Якщо ви використовуєте нуль, система створює максимально доступні потоки для користувача, виконуючи завдання.

mv <ім'я файла> / dev / null

/ dev / null - це не каталог. Не вдається перемістити файл у файл або ви ризикуєте його перезаписати.

Створіть спеціальну точку монтажу за допомогою швидкої файлової системи (використовуючи циклічний пристрій?), Використовуйте її для зберігання та видалення величезних файлів. (можливо, перемістіть файли туди, перш ніж видалити їх, можливо, це швидше або, можливо, просто відключіть їх, коли потрібно, щоб файли пішли)

Я не думаю, що це практично. Це використовувало б зайве більше вводу / виводу, ніж хотіли б в ОП.

/ dev / null - це не каталог. Не вдається перемістити файл у файл або ви ризикуєте його перезаписати.

Насправді це пристрій, і всі записані на нього дані відкидаються, тому mv <file> /dev/nullмає сенс

З Вікіпедії, безкоштовної енциклопедії
в Unix-подібних операційних системах / dev / null або нульовий пристрій - це спеціальний файл, який відкидає всі дані, записані до нього (але повідомляє, що операція запису вдалася) і не надає даних жодному процесу, який читає з нього (одержуючи EOF негайно). [1]