Я размещаю все свои загруженные файлы на хранилище NAS (glusterfs).
Недавно я обнаружил, что на NAS наблюдается огромный и постоянный сетевой трафик. Я проследил его до запросов Discourse на оптимизированные изображения. Существует ли задача, которая постоянно ищет эти изображения? Почему? И как её отключить?
Кстати, настройка очистки сайта загрузок отключена на моём форуме.
Возможно, это фоновая задача, которую добавил @david для поиска основного цвета изображения.
Она в конечном итоге завершится, и система вернется в стабильное состояние.
Нам нужно обработать все изображения в рамках этой фоновой задачи. Вы можете обойти это, принудительно установив белый цвет (или другой) для всех изображений.
Насколько я вижу,
она обрабатывает 25 изображений за 15 минут. Так? Это должно быть совершенно незначительно. Я наблюдаю, что тысячи файлов запрашиваются каждую минуту.
Кроме того, глядя на трафик за последние шесть месяцев, я вижу такое же поведение. Поэтому я думаю, что причина в чём-то другом.
Однако я почти уверен, что это делает какая-то задача Discourse или что-то подобное, потому что когда я останавливаю приложение Discourse, трафик исчезает. Но когда я останавливаю только nginx для Discourse, трафик всё ещё сохраняется.
Посмотрите в /sidekiq, там должно быть указано, какие задания выполняются. Обязательно откройте все вкладки.
Задача не выполняется. 
. Есть ли какие-то другие задачи, которые не отображаются здесь?
Или, возможно, что-то в контейнере пытается индексировать файлы?
Вся наша фоновая логика выполняется в задачах Sidekiq. Если задача не запущена, но у вас всё ещё наблюдается высокая нагрузка на дисковый ввод-вывод, возможно, это связано с посещением вашего сайта пользователями и отдачей изображений через nginx?
Используете ли вы CDN с кэшированием для раздачи статических ресурсов?
Я уже проверял это ранее.
Значит, дело не в посещении сайта пользователями. В противном случае, если бы это было так, при остановке nginx трафик бы исчез.
Вам потребуется использовать инструменты инспекции Linux, чтобы точно увидеть, какие именно идентификаторы процессов (PID) и системные вызовы будут использоваться.
@Falco @sam Я думаю, я нашел корневую причину.
Сначала я перезапустил приложение Discourse, чтобы остановить постоянный трафик. Затем я перешел в панель администратора и открыл раздел для массовых отчетов. Отчеты здесь уже давно не отображаются корректно:
Сразу после того, как отчеты начинают истекать по тайм-ауту, я вижу резкий скачок сетевого трафика. В логах ошибок я вижу следующее сообщение:
'hijack admin/reports bulk ' все еще выполняется через 90 секунд на базе данных default, этот процесс, возможно, потребуется перезапустить!
Что здесь идет не так?
База данных находится в том же хранилище NAS?
Нет, база данных находится на физическом SSD-диске.
Только папка для загрузки находится на NAS.
Таким образом, между ними нет корреляции. Вернёмся к
На самом деле, я думаю, что корреляция, возможно, есть. В моей тестовой среде здесь вычисляется используемое пространство.
Думаю, вычисление используемого пространства в папке NAS с большим количеством файлов потребовало бы очень много времени и было бы корневой причиной высокого потребления полосы пропускания.
Я прав?
Занимает ли выполнение
df -Pk
df -P
du -s
значительное время на сетевом ресурсе?
А, понятно. Результат этого отчёта кэшируется, но, похоже, он никогда не завершается и не может быть закэширован, потому что ваш сетевой диск работает слишком медленно.
Значит, есть ли что-то, что мы можем сделать, чтобы предотвратить это? Например, относиться к этому как к загрузкам в S3, где мы не вычисляем размер на диске
