Comments 7
Еще рекомендую сделать в кроне после команды
`/dev/null 2>&1`
А то не ожидано будет удивить что место засрало в логах крона, я так за год крона сьел 800гб свободного места и не заметил.
Вот вам идеи, что если вам хранить презентацию в архиве?
1)
JS может распаковать архив ZIP на клиенте и в память браузера, картинки отображать через blob
Мы экономим ноды без лишней вложенности.
2)
При обращении на урл первого слайда проверяем файл слайда
По такому пути /slides/<id>/хеш1/файл.
Если нет файла, то распаковать архив в некую временную папку tml/<id презентации>/вложенность из архива.
перинаправление на реальный файл можно сделать через X-Accel-Redirectheader(sprintf('X-Accel-Redirect: /tmp/<id>/%s', $path));
Очищать временную папку можно по таймеру, скажем никто из посетителей не смотрел 2 дня презентацию.
https://github.com/google/ngx_brotli
Если я не перепутал, он умеет отдавать сразу сжатые файлы, от этого увеличится скорость загрузки презентаций, и так же умеет динамически их сжимать. Понятно что не nginx'ом единым, но референс
дальше продолжать копать
По-моему, эта история с исчерпанием inodes (и затыки с iops'ами) Вам сделала прозрачный такой намёк, что пора уже "повзрослеть" и в плане железа, и в плане софта... Я правильно понял по прошлому посту, что у Вас там просто 2 HDD по 4 Тб, даже не в RAID? У меня в домашней файлопомойке такие четырёхтерабайтники и то в RAID-6 (ну точнее, в программном RAIDZ2 средствами ZFS), а у Вас коммерческий проект... С постоянной нагрузкой шансы, что всё неожиданно загнётся, приближаются к 100%. И как это всё бэкапится, к слову?
Ну т.е. хотя бы сделать нормальный RAID из SSD с запасом места под развитие уже очевидно пора. И завести на нём ту же ZFS, например. А возможно и перепрыгнуть сразу на следующую ступеньку и подумать про отказоустойчивость, кластер, распределённые ФС и вот это всё. Или венруться к облачным решениям и разместить эти Ваши 8 Тб в каком-нибудь объектном хранилище.
Я вам открою еще одну, возможно, будущую проблему. В ext4 есть так называемое индексирование на уровне папки. Для каждой папки существует хеш-таблица имен вложенных в нее файлов. Максимальное кол-во записей в этой таблице фиксированно. Если место в таблице закончится, Вы получите ошибку о недостатке свободного места на диске, хотя и место на диске будет и inod'ы свободные будут.
Лечится данная проблема через отключение индексирования на уровне раздела диска. Отключается утилитами для тюнинга ext4
Я ловил эту проблему, когда разработчики положили в одну папку несколько десятков миллионов файлов.
Почему бы не перейти например на BTRFS если такие проблемы с EXT4?
Там и сжатие данных, и дедупликация (которую можно запланировать на наименее нагруженные часы, или же задать load average), и проверка целостности (scrub), и иноды выделяются динамически.
Как вариант, использовать xfs, btrfs, zfs - файловые системы, не зависимые от inodes
Два с половиной месяца простоя? Круто, а взять диски в аренду и сократить это время, ну скажем раз в 5? И вообще, 8 терабайт, сколько сейчас стоит 8 терабайтный диск(Хорошо 2, уговорили), в смысле просто купить... Я думаю это возможно. Еще стоит подумать о другой файловой системе, в общем предложений масса.
8 ТБ на сайт с презентациями