Как сейчас помню, понедельник 25е октября, я заступаю на дежурство по проду и с самого утра мне прилетает задача: сегодня в ночь с 24 на 25 ноября, наблюдалась проблема с недоступностью приложения. Глянув сентри я увидел кучу ошибок от базы со statement timeout, а так же непонятные ActiveRecord::ConnectionNotEstablished: No connection pool with 'primary' found С мыслью "база не отвечала, проблема не на нашей стороне" я спокойно отдал задачу на разбирательство админам, а сам параллельно глянул графики, может там был всплеск каких-нибудь джобок или запросов, но ничего криминального в графане небыло: тяжеловесных джобок в 12 не запускается, а те, что запускаются отработали очень быстро.

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

Давным давно уже уже была написана статья о том что такое GVL (или GIL, кому как привычнее) и как он работает, однако с того времени некоторые вещи поменялись (к примеру, , а так же в Ruby 3.0 завезли Ractor'ы - новую абстракцию для реальной параллельной работы тредов. Мне стало интересно узнать что поменялось в планировщике ruby для реализации множества GVL. В этой статье я попытаюсь понять алгоритм, по которому GVL передается от одного треда к другому, как блокирующее IO позволяет продолжить работать другим тредам, а так же выяснить до сих пор ли операция добавления элемента в массив является атомарной операцией

Очень часто разработчики на Rails для извлечения заведомо одной записи из базы используют один из методов first/last из ActiveRecord. Это рабочее решение, но есть одно НО: чтобы извлечь всего одну запись база данных должна найти все, подходящие по условию, отсортировать их и вернуть только одну. Если вы подумали "Сортировка одной записи? Да это же легко!", то не будте так оптимистичны, я постараюсь показать, что это важно.

Есть много туториалов, которые рассказывают как хранить логи Rails приложения в ELK, большинство сводится либо к парсингу логов, либо сохранению краткой статистики запроса по UDP в logstash. В этой статье я бы хотел сосредоточиться на переносе абсолютно всех логов приложения в ELK по UDP.