Хакове при работа с голям брой малки файлове

Идеята на статията се роди спонтанно от дискусия в коментарите към статията «Нещо за inode».

Факт е, че вътрешната специфика на работата на нашите услуги е съхранението на огромно количество малки файлове. В момента разполагаме с около стотици терабайти от тези данни. Срещнахме се с някои очевидни и не много очевидни проблеми и успешно преминахме през тях.

Затова споделям нашия опит, може на някого да му е полезен.

Проблемът е първият: «Няма място на устройството»

Както бе споменато в горепосочената статия, проблемът е, че свободните блокове в файловата система са налични, но inodes са свършили.

Броят на използваните и свободни inodes може да се провери с командата df -ih:

Няма да преразказвам статията, в кратце, на диска има както блокове за данни, така и блокове за метаинформация, които също са inodes (индексен възел). Броят им се задава при инициализацията на файловата система (става дума за ext2 и нейни наследници) и след това не се променя. Балансът между блоковете за данни и inodes се изчислява на база средностатистически данни, в нашия случай, когато имаме много малки файлове, балансът трябва да се измести към броя на inodes — те трябва да бъдат повече.

В Linux вече са предвидени опции с различен баланс, и всички тези предразчетени конфигурации се намират в файла /etc/mke2fs.conf.
Затова при първоначалната инициализация на файловата система чрез mke2fs можете да зададете желан профил.

Ето няколко примера от файла:

    small = {
        blocksize = 1024
        inode_size = 128
        inode_ratio = 4096
    }

    big = {
        inode_ratio = 32768
    }

    largefile = {
        inode_ratio = 1048576
        blocksize = -1
    }

Избиране на необходимия вариант на употреба е възможно с опцията «-T» при извикване на mke2fs. Също така можете ръчно да зададете необходимите параметри, ако нямате готово решение.

Повече подробности са описани в мануалите за mke2fs.conf и mke2fs.

Необсъдената в споменатата статия особеност е, че можете да зададете размер на блока данни. Очевидно е, че за големи файлове е смислено да имате по-голям размер на блока, а за малки — по-малък.

Въпреки това, трябва да се вземе предвид и интересната особеност, като архитектурата на процесора.
Някога си помислих, че за големи файлове снимки ми трябва по-голям размер на блока. Ставаше въпрос за домашни условия, на домашна файлова система WD на архитектура ARM. Без много да се замисля, зададох размер на блока 8k или 16k вместо стандартните 4k, след като предварително измерих спестяването. И всичко беше чудесно, точно до момента, в който самата система излезе от строя, а диска остана непокътнат. Поставяйки диска в обикновен компютър с обикновен Intel процесор, получих изненада: неподдържан размер на блока. Ситуацията стана сложна. Данните са налични, всичко е наред, но не мога да ги прочета. Процесорите i386 и подобни не могат да работят с размери на блока, които не отговарят на размера на страницата в паметта, а тя е точно 4k. В крайна сметка, всичко приключи с използването на утилити от потребителското пространство, всичко беше бавно и тъжно, но данните бяха спасени. За интересуващите се – потърсете по името на утилитата fuseext2. Морален урок: или да обмислите всички случаи предварително, или да не се правите на супергерой и да използвате стандартните настройки за домакини.

UPD. По забележката на потребителя berez уточнявам, че за i386 размерът на блока не трябва да надвишава 4к, но не е задължително да бъде точно 4к, т.е. допустими са 1к и 2к.

И така, как решавахме проблемите.

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

На второ място, решението трябваше да бъде спешно.

В крайна сметка решихме, че трябва да променим баланса, като намалим броя на файловете.
За да намалим броя на файловете, решихме да съхраняваме файловете в един общ архив. Съобразявайки се със спецификата ни, съхранявахме в един архив всички файлове за определен период от време и извършвахме архивиране с cron задача ежедневно през нощта.

Избрахме zip архив. В коментарите към предишната статия беше предложен tar, но с него има една трудност: той няма съдържание и файловете в него са подредени последователно (не случайно «tar» е съкращение от «Tape Archive», наследство от лентовите носители), т.е. ако искате да прочетете файл в края на архива — трябва да прочетете целия архив, тъй като в него няма отклонения за всеки файл спрямо началото на архива. И затова това е дълга операция. При zip всичко е много по-добре: той има същото съдържание и отклонения на файловете в архива, а времето за достъп до всеки файл не зависи от неговото местоположение. А в нашия случай можеше да се зададе опция за компресия «0», тъй като всички файлове вече предварително бяха компресирани в gzip.

Клиентите изтеглят файлове през nginx, и според старото API, се посочва просто името на файла, например така:

http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5

За да разпаковваме файлове на летящо, намерихме и свързахме модула nginx-unzip-module (https://github.com/youzee/nginx-unzip-module) и настроихме два апстрима.

В резултат получихме такава конфигурация:

Двата хоста в настройките изглеждаха така:

server {
  listen *:8081;

  location / {
    root      /home/filestorage;
  }
}

сървър {
  слушай *:8082;

  местоположение ~ ^/hydra/(d+)/(
  d+)/(.)$ {
    корен /home/filestorage;
    file_in_unzip_archivefile "/home/filestorage/hydra/$1/$2.zip";
    file_in_unzip_extract "$2/$3";
    file_in_unzip;
  }
}

И конфигурацията на апстримите за по-високия nginx:

upstream storage {
  server server.com:8081;
  server server.com:8082;
}

Как работи:

• Клиентът отива на front nginx
• Front nginx опитва да отдаде файл от първия апстрим, т.е. директно от файловата система
• Ако файлът липсва — опитва да отдаде от втория апстрим, който опитва да намери файла в архива

Втората проблема: отново „Няма пространство на устройството“

Това е втората проблема, с която се сблъскахме, когато в каталога има много файлове.
Опитваме се да създадем файл, системата се оплаква, че няма място. Променяме името на файла и отново опитваме да го създадем.

Получава се.

Изглежда приблизително така:

Проверка на инодите не показа нищо — много са свободни.
Проверка на място — същото.
Помислихме, че може би има твърде много файлове в каталога, а на това има ограничение, но отново не: Максимален брой файлове на директория: ~1.3 × 10^20

И файл може да се създаде, ако се смени името.
Извод — проблемът е в името на файла.

По-нататъшните търсения показаха, че проблемът е в алгоритъма за хеширане при изграждането на индекса на каталога, при голям брой файлове се наблюдават колизии с всички произтичащи последици. По-подробно можете да прочетете тук: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

Можете да деактивирате тази опция, но… търсенето на файл по име може да стане непредсказуемо дълго при преглеждането на всички файлове.

 tune2fs -O "^dir_index" /dev/sdb3

В общи линии, като временно решение може да сработи.

Морал: много файлове в каталога — това обикновено е лошо. Не трябва да се прави така.

Обикновено в такива случаи създават вложени каталози, по първите букви на името на файла или по други параметри, например, по дати, в повечето случаи това спасява.
Но общият брой на малките файлове — това все пак е лошо, дори ако са разделени в каталози — тогава вижте първия проблем.

Трети проблем: как да се види списъка с файлове, ако те са много

В нашата ситуация, когато имаме много файлове, така или иначе, сме се сблъсквали с проблема как да видим съдържанието на каталога.

Стандартното решение — командата ls.
Добре, нека видим какво се получава с 477209 файла:

$ time ls /home/app/express.repository/offercache/ >/dev/null

real	0m30.203s
user	0m28.327s
sys	0m1.876s

30 секунди... малко много ще е. Особено основното време отива за обработка на файлове в потребителското пространство, а не на работата на ядрото.

Но решението е:

$ time find /home/app/express.repository/offercache/ >/dev/null

real	0m3.714s
user	0m1.998s
sys	0m1.717s

3 секунди. 10 пъти по-бързо.
Ура!

UPD.

Още по-бързо решение от потребителя berez — деактивиране на сортиране при ls

time ls -U /home/app/express.repository/offercache/ >/dev/null
real	0m2.985s
user	0m1.377s
sys	0m1.608s

Проблем четвърти: висок LA при работа с файлове

Периодично възниква ситуация, в която е необходимо да се копират много файлове от една машина на друга. При това често LA наистина скача, тъй като всичко зависи от производителността на самите дискове.

Най-разумното, което можем да направим — е да използваме SSD. Наистина невероятно. Въпросът е само в цената на многотерабайтните SSD.

Но ако дисковете са обикновени, файловете трябва да се копират, а това е и продакшън система, където претоварването води до недоволни възгласи от клиенти? Има поне два полезни инструмента: nice и ionice.

nice — намалява приоритета на процеса, съответно шедулера разпределя повече квантово време на другите, по-приоритетни процеси.
В нашата практика е било полезно да задаваме nice на максимално ниво (19 — това е минималният приоритет, -20 (минус 20) — максимален).

ionice — съответно коригира приоритета на входа/изхода (I/O scheduling)

Ако използвате RAID и е нужно да се синхронизира внезапно (след неуспешен ребут или за възстановяване на RAID масива след смяна на диск), в определени ситуации има смисъл да се намали скоростта на синхронизация, за да могат останалите процеси да работят по-адекватно. За това може да помогне следната команда:

echo 1000 > /proc/sys/dev/raid/speed_limit_max

Проблем пет: Как да синхронизираме файлове в реално време

Имаме същите огромни количества файлове, които трябва да се архивират на втори сървър, за да се избегне… Файловете постоянно се записват, затова, за да се минимизират загубите, трябва да ги копираме максимално бързо.

Стандартно решение: Rsync over SSH.

Това е добър вариант, ако не е нужно да се прави на всеки няколко секунди. А файловете са много. Дори ако не ги копираме — все пак трябва да разберем какво се е променило, а сравнението на няколко милиона файла е време и натоварване на дисковете.

Т.е. трябва да знаем веднага какво да копираме, без да стартираме сравнение всеки път.

Спасение — lsyncd. Lsyncd — Демон за живо синхронизиране (Mirror). Той работи и чрез rsync, но допълнително следи файлова система за промени с помощта на inotify и fsevents и стартира копирането само за файловете, които са се появили или изменили.

Проблем шести: как да разберем кой натоварва дисковете

Вероятно всеки знае това, но все пак за целостта на картината: за мониторинг на дискoвата подсистема има команда iotop — подобно на top, но показва процесите, които най-активно използват дисковете.

Между другото, старият добър top също може да покаже дали има проблеми с дисковете или не. За това има два най-подходящи параметъра: Load Average и IOwait.

Първият показва колко процеси чакат в опашка за обслужване, обикновено повече от 2 — нещо не е наред. При активно копиране на резервни сървъри допускаме до 6-8, след което ситуацията се счита за нестандартна.

Вторият — колко зает е процесорът с дискови операции. IOwait >10% е причина за притеснение, въпреки че на нашите сървъри с конкретен профил на натоварване стабилно получаваме 40-50%, и това наистина е норма.

На това приключвам, въпреки че със сигурност има много моменти, с които не сме се сблъсквали, с удоволствие ще очаквам коментари и описания на интересни действителни случаи.

Източник: habr.com