Отличная спецификация! У вас, должно быть, очень загруженный сайт?
Вы уверены, что не происходило повторной обработки?
Сколько изображений публикуется в минуту?
Подготовка миниатюр в основном реализована в базовом коде и требует обязательной дополнительной обработки изображений.
Это относится к любому плагину или компоненту темы подобного рода.
Мы отключили плагин примерно на 24 часа, а затем снова включили его на 24 часа.
Ниже я привожу заметки от нашего другого администратора.
Плагин вызывает замедление планирования задач.
Чем больше задач в очереди, тем сложнее процессору успевать за ними.
В результате сервер видит большой трафик, и всё кажется нормальным какое-то время, пока задачи не начнут накапливаться.
В конце концов процессор перестаёт справляться, и его загрузка резко колеблется вверх и вниз по мере выполнения накопленных задач.
Именно поэтому ранее мы наблюдали более 3000 накопленных задач.
В обычных условиях никогда не бывает больше 5 задач, но почти всегда их ноль, поскольку задачи не должны накапливаться — они должны обрабатываться немедленно.
Прикреплённое изображение показывает текущее накопление задач. Сейчас их количество колеблется в районе 30–35.
Все задачи новые и появились после последнего сообщения в sidecar.
Пока я не могу точно сказать почему, но это происходит только тогда, когда плагин включён.
Использование ресурсов процессора за последний час
Последние 24 часа, с указанием примерного момента включения плагина (см. восходящий тренд после пика)
Кажется, что для выявления паттерна требуется более 24 часов, но плагин вызывает общее использование ресурсов на уровне 80–90+% большую часть времени.
Как только мы его отключим, в течение следующих 24 часов мы заметим, что средняя загрузка сервера составит 60–75%, и задачи перестанут накапливаться.
Кроме того, когда мы этого хотим, я изменил файл app.yml, установив 16 рабочих процессов unicorn. Когда мы захотим провести пересборку, я думаю, следует отключить плагин и использовать 16 рабочих процессов unicorn. Мы будем наблюдать за производительностью сервера в течение этого периода и скорректируем значение количества рабочих процессов до оптимального.
За последние 7 дней:
красный = включён
синий = выключен
После повторного включения плагина загрузка процессора снова резко возрастает. Я меньше уверен, что часть с задачами является основной проблемой. Я заметил, что количество задач увеличивается вместе с ростом числа рабочих процессов unicorn. Думаю, эти показатели не связаны.
Тем не менее я всё ещё вижу проблему с тем, что плагин занимает ресурсы.
Пока я не на 100% уверен, но я очень уверен, что плагин является проблемой.
плагин + 16 рабочих процессов: сервер зависает
16 рабочих процессов без плагина — работает хорошо
плагин + 8 рабочих процессов — работает медленно, но функционирует
График после отключения плагина
Привет,
Я тот самый администратор, который создал эти заметки.
Больше не считаю, что задачи являются частью проблемы.
К сожалению, я недостаточно хорошо разбираюсь во внутреннем устройстве Discourse, чтобы понять, что может быть причиной. Я могу судить только о том, что наблюдаю сейчас.
Это можно свести к следующему: при включённом режиме с 8 воркерами сайт в целом работает медленно, а с 16 воркерами он практически перестаёт отвечать.
При отключённом плагине сайт работает отлично, и при достаточном количестве воркеров он работает очень быстро.
Это заставляет меня предположить, что плагин замедляет работу сайта — либо из-за потребления ресурсов, либо из-за блокировок в операциях ввода-вывода или асинхронных задачах.
Пожалуйста, проверьте вашу очередь Sidekiq. Видите ли вы много задач в очереди и какие у них имена?
Уверен, это просто накопившаяся очередь генерации миниатюр, которая разрядится, как только все изображения будут обработаны.
Это основной процесс.
Вы можете безопасно удалить плагин Sidecar, если вам не нужны его дополнительные функции, и использовать только компонент темы.
Подтвердите, пожалуйста, сохраняется ли проблема при активном компоненте темы, но без плагина Sidecar.
Если плагин Sidecar никогда не устанавливался, значит проблема в ядре.
Если вам нужна помощь с анализом, вы можете нанять Pavilion.
Я приветствую независимые отчеты об этой проблеме.
Просто подтверждаю: при включении любого компонента темы, отвечающего за создание миниатюр для списков тем, ожидается увеличение числа задач по изменению размера изображений с высокой загрузкой ЦП 
. Ядро генерирует миниатюры «по требованию» для первого пользователя, просматривающего данную тему в списке тем.
Как отметил @merefield, ситуация стабилизируется, как только миниатюры будут сгенерированы для часто просматриваемых тем.
Увеличение числа воркеров, вероятно, не лучшая идея — попытка выполнять больше задач параллельно на машине с ограниченной мощностью ЦП только усугубит симптомы. Лучше оставить количество воркеров на обычном уровне, чтобы задачи могли выстраиваться в очередь и обрабатываться без перегрузки системы.
В интерфейсе Sidekiq вам, скорее всего, стоит обратить внимание на вкладки «Busy» (Занято) и «Queued» (В очереди). Задачи на вкладке «Scheduled» (Запланировано) предназначены для выполнения в конкретное время в будущем, поэтому они крайне маловероятно являются причиной проблем с производительностью.
На предпросмотре выглядит отлично, но в реальности всё совершенно иначе. Что я делаю не так?
Многие темы с «полной конверсией» не поддерживаются. Я подозреваю, что у FKB Pro есть собственные переопределения, которые конфликтуют с этим компонентом. Боюсь, я не могу поддерживать такой сценарий.
Этот компонент темы предназначен для использования в качестве строительного блока внутри темы, которая не пытается охватить все аспекты.
Если вы хотите боковую панель справа с предварительным просмотром списков тем, попробуйте комбинацию Right Side Blocks.
Добавлена экспериментальная функция:
Это работает уже довольно хорошо, но пока скрыто за настройкой:
Элемент адаптивен по ширине, поэтому отображается только в режиме плиток (masonry), когда область списка достаточно широка.
Демо здесь: https://www.starzen.space/
NB: Лишние отступы в правом нижнем углу — это известная проблема, связанная с рендерером masonry. Для повышения производительности (он работает быстро!) он выравнивает элементы по ближайшему ряду сетки. Как только (!) нативная поддержка masonry будет реализована в CSS Grid, я переделаю это, чтобы всё выглядело лучше.
NB#2: На скриншоте также видны элементы управления из темы Discourse Bars (боковая панель скрыта). Функция предпросмотра списка тем отлично работает в связке с Discourse Bars.
На главной странице отображается изображение для YouTube.
Может ли оно быть и для Twitter?
Это никоим образом не ограничено YouTube.
Он отображает любую миниатюру. Если вставка Twitter создает миниатюру, то да.
Не могли бы вы подсказать, какие настройки нужно выбрать, чтобы получилось как на этом изображении?
Мне нужно, чтобы это было в виде списка миниатюр, как на этом изображении.
изображение выровнено по левому краю
Удалите маршруты из этой настройки:
В противном случае они будут отображаться как «плитки». Если вы хотите, чтобы ни один маршрут не отображался в формате «плитки», удалите все эти строки, но, возможно, стоит оставить плитки для мобильных устройств (в этом случае оставьте те, что с *-mobile).
Теперь всё отлично, спасибо тебе 
В соответствующем плагине-спутнике (перечисленном в первом сообщении) есть настройка:
Но если у вас нет этого плагина, попробуйте использовать встроенные настройки:
Я давно не проверял это! 
Я пробую настройки, о которых вы упоминали, но они не работают.
Интересно, что по одной теме слишком мало сводок, а по другой — слишком много.
Персонаж должен укладываться в определённый лимит символов.
Установите плагин sidecar и примените эту настройку.
Полагаю, вам нужно запустить повторную обработку поста, чтобы обновить краткое содержание темы.
