Comments 66
Процессоры i386 и подобные не умеют размеры блока, не соответствующие размеру страницы памяти, а она ровно 4к.
Что-то здесь не так:
$ uname -a
Linux athlon 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ man mkfs.ext2
…
OPTIONS
-b block-size
Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem (see the -T option). If block-size is preceded by a negative sign ('-'), then mke2fs will use heuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful for certain hardware devices which require that the blocksize be a multiple of 2k.
30 секунд… многовато будет. Причем основное время уходит на обработку файлов в user space, а вовсе не на работу ядра.
Но решение есть:
Проблема с ls в том, что оно сортирует список перед выводом на экран, что приводит к тормозам на чахлом процессоре. Очевидное решение — отключить сортировку, и оно работает немного быстрее, чем трюк с find:
$ time ls largedir >/dev/null
real 0m2,199s
user 0m1,695s
sys 0m0,302s
$ time find largedir >/dev/null
real 0m0,848s
user 0m0,526s
sys 0m0,257s
$ time ls -U largedir >/dev/null
real 0m0,499s
user 0m0,261s
sys 0m0,229s
Управление доступом, кстати, удобное только пока простое. Потом оно либо становится неудобным, либо в принципе недостаточно гибким. Есть такой пример: если сделать доступными файлы из какого-то бакета по префиксу доступными на чтение (через WebUI или консольный клиент), то стандартный WebUI позволял просматривать их список без авторизации. Решалось только применением кастомных политик. Возможно, сейчас исправлено.
Если вам никогда не надо посмотреть, что на самом деле воон в том файле, или, не дай бог, срочно заменить неправильный на правильный, и уж точно никогда не надо восстанавливать бекап прошлогодней базы — могу только порадоваться за вас.
Обычно в таких случаях создают вложенные каталоги, по первым буквам имени файла или по каким-либо другим параметрам, например, по датам, в большинстве случаев это спасает.
Однако если вдруг однажды потребуется обход по всем файлам (например, чтобы сделать бэкап или rsync), то он будет нереально долгим. Сейчас попробовал сделать простой find -type f по одному такому своему каталогу (55 тысяч файлов, заботливо рассованных по подкаталогам) — заняло целых три минуты (и это я даже не пытался читать само содержимое файлов). Перенёс всё в один-единственный каталог без вложенки — и даже ls с выдачей размера, сортировкой по имени и прочими радостями жизни отработал меньше чем за секунду (линуксовый кэш предварительно чистил, если что)
Впрочем, 55 тысяч это таки далеко не 55 миллионов. Буду надеяться, что полный обход по 55 миллионам файлов мне никогда не придётся делать)
мониторит файловую систему на предмет изменений с использованием inotify
Вроде можно случайно упереться в ядрёные лимиты типа fs.inotify.max_user_watches?
Проблема шестая: как понять, кто грузит диски
fatrace
Еще он капризный и совсем недавно были фиксы в ядре www.opennet.ru/opennews/art.shtml?num=50631
Очевидно, штатные фс и подходы вам будут жать. Вероятно, вам не нужна фс как таковая, скорее всего более подходящим будет тот или иной object storage. Из простого — монгодб (gridfs), посложнее — ceph.
Если оставаться все же в рамках фс, то я бы глянул на zfs. Она требует вдумчивости, но например вы могли бы выделить память и ссд только под кэширование метаданных, соотв уйдут тормоза с поиском файла (после прогрева кэша). Да, штатный pagecache тоже кэширует, но будет вымываться чтением данных.
Если у вас там файлы жмутся хорошо — получите прозрачное сжатие.
Главное! Не. Включайте. Дедупликацию. :)
А, а насчет синхронизации, там есть родной zfs send.
Кстати, с ZFS на SSD вы заодно получите работающий trim, чего на железных RAID вы не имеете. Только если будете ставить ZFS в продакшене — не подключайте диски через железный RAID, ну на крайняк в RAW режиме (адаптек умеет, LSI — не умеет).
Насчет сжатия на zfs — это скорее приятное дополнение к остальным фичам, но совсем не основное. Если у вас более-менее серьезные объемы и кол-во файлов — нужна соответствующая ФС. Увы, из бесплатного есть только ZFS и XFS. Хотя сравнивать их безусловно нельзя.
И еще. =) В данный момент ZFS лучше поднимать на Freebsd. Пока, в ближайшем будущем (после R12), видимо, разницы с ZoL уже не будет — кодовая база объединяется.
Нет, мне не уняться…
>Пока радуемся жизни
Следите. SSD коварен, если вдруг кончится место для очистки мусора, получите резкую деградацию до уровня десктопного SATA. Если не секрет — какую модель SSD использовали?
Zfs перестаёт создавать новые stripes, зато начинает уплотнять старые, производительность неожиданно падает и это обычно неприятный сюрприз.
Любая файловая система деградирует, когда количество свободного места меньше ХХ %. Это не специфично только для ZFS.
Т.е., извините — хотите гарантированную производительность — оставляйте свободное место.
Еще хуже то, что в случае с НТФС — производительность при забитии на 99% падает, а потом, когда место появляется — она не возвращается в норму.
Всё не так страшно, но да, она деградирует.
Специфично это не для всех ФС, а для copy-on-write.
На XFS у меня несколько 100+Tb массивов залиты под самое горлышко и всё хорошо.
С ZFS такие шутки могут выйти боком, да.
О преимуществах ReiserFS
Benchmark схожего use case
Но естественно, нужно тестить под ваш use case.
Файл это нечто больше 64 килобайт, как минимум. Все что меньше это поле в БД.
Как вариант — можете попробовать не ext4, а btrfs/ReiserFS или jfs/xfs — но последние 2 могут развалиться при внезапном отрублении электричества. xfs очень хорошо работает с большим количеством больших файлов на огромных разделах.
У меня XFS уже больше 5 лет где-то на 3х десятках хостов, местами разделы по 150Т. Отрубали искричество не раз — пока ни разу не развалилась.
Безусловно, сломать можно всё, но повреждения могут быть вызваны битой памятью и/или дисковой системой — в этом случае ничего не спасет, кроме бэкапов, да =)
В частности, та же ZFS очень болезненно относится к битой памяти вплоть до умирания всего пула. А вот диски мы из неё доставали прямо во время работы — всё ок.
Слушайте, ну не бывает совсем безглючного софта, тем более в таких сложных штуках, как ФС.
Прочитал ваш тикет — подозрительно, но вам тоже сказали, что это больше похоже на железную проблему. EXT4 вы проверяли на другом сервере, что только больше подтверждает теорию.
8-10 дисков по 10Т — не абы какой объем для xfs, у меня буквально недавно было 4 хоста, в каждом 12 10Тб-ков. Гоняли под нагрузкой, зависания были, но виновником был контроллер. Хотя в итоге всё равно ушли на XFS on FreeBSD. И наступили покой и счастие. =)
Слушайте, ну не бывает совсем безглючного софта, тем более в таких сложных штуках, как ФС.
не находите, что fs — как раз та вещь, от которой хочешь безглючности? чаще всего фичи не важны, если фс не может стабильно работать.
EXT4 вы проверяли на другом сервере, что только больше подтверждает теорию.
разумеется на другом, этот (а точнее пара) стоит в хетцнере и отдаёт контент 24/7 на скорости 0.5-1Гбит/c. поднять рядом ещё один с ext4 и перелить на него — это примерно 400 евро, я не решился столько тратить на эксперииенты
и на другом я получил то же самое — xfs иногда фризится. с ext4 (на том же другом сервере) вопроизвести проблему не удалось.
всё равно ушли на XFS on FreeBSD
вы хотели сказать zfs?
не находите, что fs — как раз та вещь, от которой хочешь безглючности?
Нахожу. Хочу такую. Найдете — расскажите, плиз :)
вы хотели сказать zfs?
да, конечно, zfs
Насчет фризов, согласитесь, если бы был баг, он бы проявлялся не только у вас. Тем не менее, за несколько лет коллег по несчастью не нашлось. Поэтому, увы.
А Хейцнер, это которые ставят б/у шное железо? Были у их, да :)
Мне показалось удобнее использовать монтируемые ФС, а не архивы. Но у меня юзкейс — не только отдача по web, но и обычные файловые операции. В каждую тулзу zip не просунешь, увы… И вот тут внезапно squashfs — если делать архивы посуточно, понедельно и т.д. Получается "тот же zip", но при этом монтируется и даёт произвольный доступ. С другой стороны, много примонтированных архивов тоже не выглядит изящным решением.
Ещё экспериментировал с udf (там ещё и писать можно), но не масштабно.
Как заметили выше — рекомендую тоже отключить (опциями монтирования) записи времени чтения и доступа.
Статья интересная, но я из заголовка ожидал увидеть советы типа
- не использовать ls * и аналогичные баш подстановки. Т.к. когда много файлов, то они взрываются.
- использовать find
- использовать пайплайнинг и xargs, где это возможно.
и пр.
По inode — интересно насколько помогла бы тонкая настройка параметров ФС или использование других, более подходящих для мелких файлов (если таковые вообще есть) ФС.
Мораль: или продумывать все кейсы наперед, или не строить из себя супергероя и пользоваться стандартными настройками для домохозяек.
Это когда хочешь сделать что-то идеально, а потом сам себе роешь яму (не зная того) и в нее падаешь в конце-концов.
Он тоже работает через rsync, но дополнительно мониторит файловую систему на предмет изменений с использованием inotify и fsevents и запускает копирование только для тех файлов, которые появились или изменились.
Пишут, что inotify на 100500 файлов — это плохо. Не вызывало ли это проблем?
Почему Load Average=2 Вы считаете «плохим»? Специально сверился со статьей про этот показатель, он показывает общую нагрузку на систему и, как я понял, коррелирует с количеством процессоров.
Но я исходил из нашего опыта на наших машинах, и в районе 2х более-менее, обычно меньше, 5-6 — это усердное копирование файлов, требует мониторинга админа, ибо чревато скачком, а при 8 уже клиенты ругаются.
Вернее не синхронизация как таковая а полное копирование каталога.
Просто из любопытства, что вы там храните в таком количестве мелких файлов? Квантовую конфигурацию всех атомов во Вселенной? :)
Разумные рекомендации почти все озвучены.
Осталось напомнить, что Berkeley DB еще никто не отменял. А она быстрая.
В нашей практике помогало выставлять nice максимальным (19 — это минимальный приоритет, -20 (минус 20) — максимальный).Это очень полезный совет, кстати.
Для процесса, который в основном занят вводом/выводом и почти ничего не считает в юзерспейсе, ставить максимальный приоритет (-20) — крайне выгодно. Т.к. этот процесс в основном вызывает syscall-ы ввода-вывода и ждёт результата. Получив квант времени от планировщика, этот процесс вызовет следующий syscall (т.е. немедленно отдаст CPU обратно).
Повышенный приоритет уменьшает время между двумя просыпаниями процесса (т.е. он сможет вызывать syscall-ы чаще), а отнимаемое у других процессов время — не меняется.
Не так давно искал «идеальный архиватор», его, конечно, не нашёл, но нашёл довольно много интересного и немножко поапгрейдил своё хранилище.
Если надо экономить диск, то LZMA/LZMA2 жмёт в некоторых условиях раза в два лучше, чем GZIP (и заметно лучше, чем BZIP) правда, выше потребление RAM/CPU при паковке. Но это настраивается размерами словаря и прочими ключами. Распаковка чуть медленнее GZip-а. Контейнер Zip не умеет потоки LZMA, но их умеет, разумеется, 7-Zip. Ещё б не умел, если архиватор и алгоритм делал один и тот же человек. Вообще 7-Zip — весьма клёвый архиватор. К нему можно разные сжимательно-разжимательные плагины подключать. Программно можно юзать его через exec/pipe (7z {-si|-so}) или через libarchive. Разжатие через libarchive точно работает (в моём случае в python-скриптах), сжатие не проверял — нет надобности.
Если надо, наоборот, разгрузить проц, то безумно быстрые и при том сравнимые с зипом по сжатию — гугловский Brotli, фейсбучные ZSTD и LZ4. А распаковка у них вовсе реактивная, особенно Brotli.
Есть и другие алгоритмы, но они экзотические и не особо применимы в реальной жизни, в отличие от этих.
На данный момент собираю данные в текстовые логи без сжатия с почасовой ротацией и затем жму их офлайново в LZMA при помощи 7-Zip с плагином Fast LZMA. Он работает быстрее штатного раза в два. Сжатие доходит до 1:200. Да-да, Карл, в 200 раз, это не опечатка. Например, исходный файл 32.742.408 байт жмётся до 167.805. Конечно, так жмутся не все файлы, но это РЕАЛЬНЫЕ данные, а не какие-то там специально сделанные, чтоб мощь архиватора показать.
Организация хранения — подкаталоги с названием даты. На каждый поток данных — один файл архива, в который регулярно добавляются почасовки.
Другая часть данных собирается в базу MySQL RocksDB с промежуточной компрессией LZ4 и финальной ZSTD. Тут компрессия, конечно, поменьше, зато поменьше и RAM+CPU/время отклика
Вообще же стремление народа из Linux к NIH-подходу иногда перевешивает здравый смысл — btree сейчас это достаточно банально и позволяет вкусностей больше, чем просто быстрый поиск по точному имени.
Хаки при работе с большим числом мелких файлов