А со скейлингом как? Я пытаюсь начать использовать внешние мониторы (примерно такая же конфигурация), но фрустрирует отсутствие возможности нормально заскейлить интерфейс. Ставлю везде скейлинг 200, в итоге на мониторах все огромное, на ноутбучном экране довольно мелкое. Это как-то решается?

Копаю в сторону xrandr, но пока ощущение каких-то адских костылей.

У меня везде 200 и меня устраивает. Монитор подальше отодвинул и мне комфортно.

Ясно, спасибо😐

Sidekiq вопрос:

Кто-то пробовал адаптировать у себя паттерн Queue Sharding (https://www.mikeperham.com/2019/12/17/workload-isolation-with-queue-sharding/)? Получилось ли сделать? Какую обвязку пришлось писать? Есть ли альтернативные решения из коробки?

я не использовал, но интересно было бы разобраться. Из статьи по ссылке я понял что просто запускается 8 инстансов сайдкика со специфичным названием очереди и все задачи распределяются между этими очередями рандомно.
Но вот непонятно как это снизит нагрузку на систему? Ну то есть нельзя же до бесконечности увеличивать количество инстансов. Вот в статье написано что 8 и типа нагрузка уменьшится на 12-25 процентов. А почему не 100 чтобы нагрузка уменьшилась до 1 процента.
Я к тому что если один инстанс сайдкикак будет выполнять задачи из очереди быстрее имея 100% ресурсов, а 8 инстансов - медленее потому что будут ждать когда другой инстанс освободит эти ресурсы. Или я не понимаю?

Если у тебя один сайдкик — он будет просто ждать IO большую часть времени. Если несколько — они будут по очереди пользоваться процессором. Если очень много сайдкиков — процессор станет узким местом

а типа проблема не в самом сайдкике а с какой периодичность он редис опрашивает?

Скорее в том, чем обычно сайдкик занимается

(БД, походы по сети,…)

да согласен, надо понимать контекст. Если рассмотреть работу с БД то по идее можно попробовать распределять разные таски для разных таблиц. если пересечений не будет тогда должны выполняться параллельно. Главное в ограничение по коннектам не упереться

Речь немного о другом 🙂 Если у тебя один сайдкик, то, пока он “пошел” в БД, ничего другого выполняться не будет, если несколько — то в это время можно повыполнять другие джобы.

понял, спасибо

У меня монитор 4к LG на 27 дюймов и убунта.
Я через gnome tweak tool в разделе шрифтов коэффициент масштабирования выставил на 1,25. Мне стало норм.

Да так можно, но в моем случае проблема в том, что у меня еще и ноутбук для экрана которого хочется свои настройки:)

задача не в снижении нагрузки на систему, а в избежании ситуации, когда очередь забита задачами одного большого аккаунта; например, у одного аккаунта 100k пользователей и он отправляет им рассылку; это может занимать десятки минут, очередь mailers будет занята, все письма у других аккаунтов пойдут с задержкой

в статье как раз и говорится, что речь о multi-tenant приложениях

мы решали эту проблему (а это серьезная, кстати, проблема) по-другому: на этапе постановки задачи в очередь делали throttle — запрещали ставить больше X задач в N секунд (для X+K устанавливали задержку, т.е., `wait(until: some_time)`); таким образом, задачи в очереди от разных аккаунтов перемешиваются и "маленькие" аккаунты спокойно проскакивают

Шардинг выглядит более простым решением, но в нём есть недостаток: с вероятностью 1/N у нас задачи всё равно попадают в забитый шард и кому-то придётся ждать; да, реже, но всё же.

Кажется, логичным продолжением этой идеей является балансировка: когда мы не случайно выбираем шард для очереди, но сначала смотрим, в каком шарде меньше всего размер.

А можешь подробнее рассказать как вы задержку ставили?