d'Ivan

Linux perf tool в помощь.

Выполнять задачи в очереди можно если задачи могут выполняться отложенно. При обработке в очереди нет гарантии выполнения в заданный срок времени и механизмы взаимодействия при этом усложняются.
Для управления нагрузкой в пиковое время необходимо горизонтально масштабировать экземпляры приложения при повышении нагрузки сверх заданного лимита. По ходу, может понадобиться масштабирование СУБД.

Если я отправлю в очередь 'send_push' сообщение '{post_id: 123}': , его получит консьюмер, выберет из БД 1тыс пользователей

А что мешает консьюмеру брать из БД по 1000 в цикле?

Написать сервис, который читает unix socket и отдает метрики через HTTP.

Стартапы чаще пишут код на языках с динамической типизацией, поскольку проще выпустить первый релиз-монолит в короткие сроки. А раз быстро, то по мере роста компании будет появляться все больше "костылей" и говно-кода. На определенном этапе в компании приходят к выводу, что монолит медленно работает, его трудно развивать и он плохо масштабируем. И тогда сначала пробуют дробить монолит на мелкие службы на том же языке, что и монолит, на даже этого по производительности может не хватать. И тогда начинают искать язык, на котором можно писать высокопроизводительные службы, при этом был легок в изучении, легко разворачиваем на сервере, у которого было хорошее сообщество и легко было найти новых разработчиков или переобучить их. Таких языков не так много.

Железо (электронику) нет смысла восстанавливать, так как исправно работать не будет. А вот данные на накопителе - зависит от желания и финансов.

чуть ли не постоянно БД получала too many connections

Возможно, время между открытием соединения и закрытием проходит достаточно много времени и поэтому СУБД вынуждена держать много открытых соединений одновременно, что плохо.
Скорее всего, код нужно исправлять.

Из MySQL table creation insanely slow

SET profiling = 1;
CREATE TABLE blah (id BIGINT UNSIGNED NOT NULL PRIMARY KEY);
SET profiling = 1;

На самом деле, в конце должно быть = 0, чтобы убрать профилирование.

Есть подозрение, что есть проблема с диском.

Нужно выбрать нужную кодировку и это зависит от возможностей распаковщика.
Попробуй Bandizip

Проверить целостность архива можно так:
7z t archive.7z

... LIMIT 1
и вместо * указать первичный ключ в таблице.

Скорее всего из-за выполнения блокирующих операций I/O.

Надо замерить время выдачи страницы сервером Puma и от этого плясать дальше. Если оно близко к 30мс от RoR, то нужно выяснять относительно конфигурации nginx.

Есть.
AWS IAM policy.

https://ru.wikipedia.org/wiki/URL#%D0%9A%D0%BE%D0%...