У меня складывается подозрение что даже удаленные файлы как-то влияют на внутрение журналы файловой системы или еще куда-то что файловая система ведет себя не адекватно.

Да. Это такая особенность ext* Всё-таки в RHEL недаром дефолтной ФС сделали XFS.

если коротко, то во всём виноваты иноды http://stackoverflow.com/questions/21397110/how-to-store-one-billion-files-on...
но на самом деле нет, во всём виноваты ваши php-макаки

dd

cp -aux

Писать дохулиард файлов в одну директорию ровным слоем - самый адовый ад который можно придумать. Используй иерархию с хорошей вложенностью и всё залетает.

но на самом деле нет, во всём виноваты ваши php-макаки

Лучший ответ! И ведь верно.

Крона кастани.

btrfs-убийца (комментарий)

50 миллионов - это многовато всё-таки. И да, директория - это тоже файл, он занимает место на диске, может фрагментироваться (если файлы создавались по одному долгое время вперемежку с остальной активностью, то фрагментация там огого).

Утилита filefrag из e2fsprogs покажет число фрагментов. Для пустого файла покажет 0, для небольшого файла и большинства директорий 1, для /usr/include 3, для скачанного с торрентов кинца может и 3000.

дык cp -ax mod-tmp mod-tmp1 && rm -r mod-tmp && mv mod-tmp1 mod-tmp

Писать дохулиард файлов в одну директорию ровным слоем - самый адовый ад который можно придумать.

Ханс Райзер в своё время пытался этот вопрос обойти. Для БД 50 миллионов записей — копейки. Что мешает в ФС нормальное индексирование сделать?

Используй иерархию с хорошей вложенностью и всё залетает.

Только не в ext4 в случае find/rsync. Обход больших вложенных каталогов в ext4 — это ад.

Сделал проверку диска, получил:

fsck.ext4 -nvf /dev/sda5
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

      291074 inodes used (0.99%, out of 29491200)
         707 non-contiguous files (0.2%)
         105 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 284439/145/3
    31170967 blocks used (26.43%, out of 117939968)
           0 bad blocks
           2 large files

      273802 regular files
       10313 directories
          55 character device files
          25 block device files
           0 fifos
          27 links
        6867 symbolic links (6396 fast symbolic links)
           3 sockets
------------
      291092 files

на вопрос кто виноват, ехт4 или макаки, предлагаю ТС проверить другую ФС. А вообще да, для специфичных задач надо было нормально планировать параметры создания/форматирования ФС.

За время работы сервера в директории mod-tmp накопилось около 50 миллионов файлов,

И с какими параметрами вы выполняли mkfs.ext4, милейший?

Справедливости ради, это не они виноваты, а разработчики исп и мейнтейнеры пыха в дебиане.

Но это не отвечает на вопрос, что происходит у ТС на сервере.

У тебя опухоль иноды mod-tmp. Просто удали этот каталог и создай заново.

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

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

Почему так происходит? элементарно. В freebsd, debian, ubuntu по умолчанию для пыха отключена очистка файлов ссесий, так как данная процедура мягко говоря средствами пыха не сильно производительная, по этому применяются костыли виду ручной очистки по крону. Но фишка в том что никто из ISPSystem не додумался когда пользователю создается профиль, добавить таск на очистку данных файлов, в итоге тысячи серверов имеют такие проблемы со временем. А тут еще и разработчики которые не особо задумываются как там на сервере хранятся файлы, в итоге рано или поздно сервер ставится в позу вместе с диском. Нам же остается только выгребать этого состояние и пытатся подсунуть очередной костыль.

Думает потому что каталог большой и фрагментированный, говорю же посмотри filefrag mod-tmp и ужаснись. А большой потому что записи не удаляются, а помечаются как удалённые. fsck.ext4 -D сжимает/переиндексирует такие раздувшиеся директории.

Это всего лишь показатель неэффективности конкретной ФС.

Это всего лишь показатель неэффективности конкретной ФС.

на вопрос кто виноват, ехт4 или макаки, предлагаю ТС проверить другую ФС. А вообще да, для специфичных задач надо было нормально планировать параметры создания/форматирования ФС.

выполни e4defrag - ext4 уже умеет дефрагментацию, вдруг поможет

при удалении файлов из каталога размер inode самого каталога не меняется. Это как в базе данных - просто отметили запись как удаленную и все. Для удаления таких записей делают vacuum, но для ext4 такого механизма нет (кроме полного сжатия до 0 т.е. удаления).

Нужно создать временный каталог, если в старом есть нужные данные, то перенести их в временный каталог, далее старый каталог удалить, а временный каталог переименовать старый

Ты поощряешь разработчиков ФС и тулз, которые начинают тупить далеко до заявленных лимитов ФС.

Как это повлияет на удаленные иноды?

а лимит ли это фс? может там винты виноваты? Дуреют от такого количества файлов. головки то чай не резиновые!

Винтам какая разница? Винт - это блочное устройство. Ведь в БД хранят же миллионы и миллиарды записей, а файлы БД хранятся на тех же винтах.

Сделал себе 50 миллионов файлов через seq 1 50000000 | ionice xargs touch. Два раза папка корраптилась, и приходилось делать fsck -fD, наверно шлейф херовый, а может баг в ядре. Считывается папка нормально:

[root@battlehummer 50m]# time \ls -f | wc
50000002 50000002 438888902                                                                                                                                             
real    0m59.677s
user    0m30.330s
sys     0m19.996s

Все файлы пустые и фс пустая, так что фрагментации нет:

[root@battlehummer test]# filefrag 50m
50m: 3 extents found

Это был контрольный опыт, дальше попробую воспроизвести ситуацию ПОа, но это наверно неделю займёт.

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

12 лямов 32-х символьных случайных имен в одном каталоге, дальше «Directory index full!»

# ls -l /tmp/50M/
total 719360
drwxr-xr-x 2 root root 736595968 Apr 20 22:37 A/
drwx------ 2 root root     16384 Apr 20 22:20 lost+found/

ext4/lvm/ssd

создалось за 10 минут

удалялось 12 минут по «rm -r A»

700Мб каталог - это жесть!

Права. Не забыть про (если есть) всякие selinux, acl и т.п.

Записей - да. Но не запросов. «du» это не «сложная дисковая операция», это 2N отдельных простых, выполняющихся последовательно. «Нормальный» диск отработает 50к файлов в лучшем случае минут за 5 - и будет всю дорогу занят по уши самой верхней головки.

Лучшее, что могли сделать авторы ФС - убрать влияние удалённых 50М. Но, для сравнения, некоторые ДБА вынуждены регулярно перестраивать индексы таблиц с большими удалениями, абы не тормозило, т.ч. далеко не все БД переживают такие случаи без вмешательства извне. Каталог от индекса отличается почти ничем, и его не перестраивали - это может ещё добавить времени к тем 5мин.

Я тут кстати продолжаю эксперименты. Теперь я удалил свои 50м пустых файлов:

[root@battlehummer 50m]# time ionice -c 3 find -delete
real    2085m21.623s
user    0m0.001s
sys     0m0.004s
[root@battlehummer 50m]# time \ls -f | wc
      2       2       5

real    0m31.428s
user    0m0.000s
sys     0m4.640s
[root@battlehummer 50m]# ll -h ..
итого 871M
drwxr-x--- 2 legolegs legolegs 871M апр 24 01:57 50m
drwx------ 2 root     root      16K апр 16 13:58 lost+found

Даже немного неохота повторять опыт с непустыми файлами - этож на неделю диском трещать.

сиречь fsck -D

Только fsck.ext4 так умеет? А e4defrag?

продолжаю эксперименты

find -delete

Любой программист, написавший что-то типа

for i in $(select key from 50m-record-table)
do something with 50m-record-table where key=$i

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

Попробуй, лучше, положить это в tmpfs или ramfs

Зачем мне tmpfs, если я ставлю опыты над ext4?

Грош цена той файловой системе, которая колом встает при создании и удалении миллиона файлов в директории.

Почему? У топикстартера 50 миллионов файлов копились долгие годы и он и не знал о них, пока не сделал du.

Тут не только в API дело, а ещё в утилите find. Она сначала читает всё и создаёт список подходящих файлов, а уже потом для каждого файла из списка делает unlink(). И при таком количестве файлов велика вероятность, что к моменту, когда find начёт удалять файлы, из дискового кеша уже «уйдут» блоки с содержимым каталога.

2 legolegs Если интерестно, попробуйте сразу читать имя файла и удалять его, кодом на Си, примерно таким. Проблема с хардом. Не могу прочитать каталог. (комментарий) ИМХО, должно быть быстрее, чем ″find -delete″.

find. Она сначала читает всё и создаёт список подходящих файлов, а уже потом для каждого файла из списка делает

Честно говоря, сомнительно. find создана, чтобы обходить огромные деревья, хоть всю фс, список файлов вовсе не обязан помещаться в память. Надо, конечно, смотреть исходники, но я почти уверен, что find работает аналогично вашему коду. Попробую, когда время будет.

Ожидал увидеть код с getdents(), а так это несерьёзно.

Надо, конечно, смотреть исходники,

Проще посмотреть вывод strace(). У меня сначала идёт куча getdents64(), потом куча unlinkat(). Правда, я делал это на 100000 файлах, на 50 млн. мне времени жалко, сомневаюсь, что find меняет алгоритм при больших объёмах.

Там ещё ″fputs(..., stdout)″, а не истинный хардкорный ″write(1, ...)″.

можно узнать, пожалуйста, что вы храните в таком кол-ве файлов?

не только в API дело

Не соглашусь. Посчитаем: пусть наш диск обслуживает 200 операций в секунду (оценка из расчётов дисковых массивов, оптимистичная, но умножать проще) = (1/5)к/c. Удаление 50м файлов - 50м отдельных записей в журнал. Умножив на скорость получим 10000секунд, или 4166 минут - у ТС получилось почти в 2 раза быстрее, т.е. жаловаться не на что.

Просто файлуха затачивалась на поиск одиночный поиск файла, и именно это делает хорошо.

я ставлю опыты

Я думал, тебе нужно, чтобы работало.

Грош цена той файловой системе, которая колом встает

Могу спорить, что открытие одного файла в таком каталоге работает всего раз в 30 медленнее, чем в почти пустом, как и должно быть при оптимальном поиске в такой куче. Т.ч. она не «колом встаёт», а «слишком много работает».

Это ТС нужно, а я не ТС, а просто играюсь с ФС и наблюдения публикую.

Извини, недосмотрел. Первая буква логина слишком похожа.

monsterid рулит :)

Вот тут еще всплыло:

https://ru.wikipedia.org/wiki/Inotify