LINUX.ORG.RU
ФорумAdmin

Падение скорости на ext4 при заполнении

 , ,


1

6

Здравствуйте. Подскажите, куда смотреть и можно ли что-то сделать (подтюнить) ext4 или сразу мигрировать на что-то вроде ZFS или xfs. Имеется разветвленная структура файлов и каталогов, всего около 40-50 млн файлов небольшого размера (до 100-200 Кб), в основном бинарные файлы: шрифты, рисунки в векторных форматах (остатки от работы CAD и пр.). Все это нужно держать как есть, сжать не выйдет, так как старый проприентарный софт именно так это и хочет видеть. Можно размазать по 2-3 дискам, но толку мало. В чем проблема: при наличии уже около 20-30 млн мелких файлов файловая система ext4 начинает дико тормозить при записи, скорость обмена падает до 6-7 Мб/с. Чтение тоже замедляется примерно до тех же величин. Диск 100% исправен. inodes занято около 15%, свободного места - и того больше, пара ТБ точно есть. Понятно, что такое обилие файлов вызывает тормоза - поясните, а что именно вызывает? Какой механизм, я хочу понять где узкое место в случае миллионов файлов возникает? И что можно сделать? Понятно, что перенести, но нет денег и не предвидится (пока). Поможет ли XFS/ZFS в таком случае? Всякие там atime/adirtime убраны в fstab в ноль, а что еще можно подтюнить? Спасибо


Ответ на: комментарий от x905

У меня другая проблема чем у топикстартера: обрабатываю текстовые файлики с устройств, их много, аккумулируются на HDD. Раньше было вот так:

root@alpha1:~# strace -c dd if=/dev/urandom of=/mnt/testfile bs=4096 count=1M oflag=direct
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 1206.42 s, 3.6 MB/s
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 96.38  549.492929         524   1048579           write
  3.62   20.640550          19   1048579           read
  0.00    0.000446          19        23         3 openat
  0.00    0.000300          14        21           mmap
  0.00    0.000228           9        23           close
  0.00    0.000191          10        18           fstat
  0.00    0.000041          13         3           mprotect
  0.00    0.000026           8         3           rt_sigaction
  0.00    0.000023          11         2           dup2
  0.00    0.000021          21         1           munmap
  0.00    0.000021           7         3           brk
  0.00    0.000016          16         1         1 access
  0.00    0.000012          12         1           lseek
  0.00    0.000008           8         1           arch_prctl
  0.00    0.000000           0         1           execve
------ ----------- ----------- --------- --------- ----------------
100.00  570.134812         271   2097259         4 total

Специально пишу 4 Гб блоками по 4 кб. Теперь я поставил ядро 6.6 и вот:

root@alpha1:/mnt/# strace -c dd if=/dev/urandom of=/mnt/testfile bs=4096 count=1M oflag=direct
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 94.8093 s, 45.3 MB/s
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 55.03   14.221970          13   1048579           read
 44.97   11.621899          11   1048579           write
  0.00    0.000015           0        23         3 openat
  0.00    0.000010           0        23           close
  0.00    0.000000           0        18           fstat
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0        21           mmap
  0.00    0.000000           0         3           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         3           rt_sigaction
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         2           dup2
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00   25.843894          12   2097259         4 total
ahnenerbe
()
Ответ на: комментарий от x905

Мне было важно посмотреть как отрабатывает ФС, а не ее кеш. Потому что потом, когда буфер сбрасывается, я ловлю тормоза в любых местах, а не в тех, в которых я жду. Другими словами, если пишу с буфером, то тормозить начинает уже fsync(), а не write() как без него. Мне проще быть готовым, чтобы потом профилировщиком еще пройтись по нужным местам.

ahnenerbe
()