Нам нужны твои мозги

Постановка задачи

Memory Bloat (или «распухание памяти») возникает, когда приложению требуется одновременно загрузить большое количество данных в оперативную память. Это опасно, так как виртуальная машина Ruby очень неохотно возвращает запрошенную память системе, а для эксплуатации приложения требуется больше ресурсов. Многие APM умеют обнаруживать уже случившиеся распухания памяти, но хотелось бы иметь возможность обнаруживать потенциальные узкие места заранее.

Чаще всего распухание возникает сразу после получения данных из некоторого источника, и решением проблемы является уменьшение объема читаемых данных. Допустим, нам требуется посчитать сумму неких транзакций за месяц:

class ReportController < ApplicationController
  def monthly_transaction_sum
    sum = Transactions.where(date: Date.current.all_month).sum(&:amount)
    render json: { sum: sum }
  end
end

Мы загрузили все транзакции за месяц (а их может быть много!), но в ответе пользователю отправили всего одно число. Если транзакция всего одна — ничего страшного, но что произойдет, если их несколько тысяч?

В качестве решения предлагается использовать хитрую метрику I/O to response payload ratio, которая вычисляется как отношение объема данных, полученных из I/O (БД/Redis/файла/HTTP/…) в процессе обработки HTTP–запроса клиента к объему итогового HTTP–ответа. В результате каждый из экшенов должен быть обернут в некий блок, собирающий информацию об обращении к I/O и формировании HTTP–ответа:

class ReportController < ApplicationController
  include IoToResponsePayloadRatio::Controller

  def monthly_transaction_sum
    sum = Transactions.where(date: Date.current.all_month).sum(&:amount)
    render json: { sum: sum }
  end
end

Затем, в зависимости от настроек, будет происходить либо журналирование, либо публикация события в ActiveSupport::Notifications:

IoToResponsePayloadRatio.configure do |config|
  config.publish = :logs
  # или
  config.publish = :notifications
end

В случае журналирования можно будет увидеть подобную запись:

Completed 200 OK in 1232ms (ActiveRecord: 400ms, DB Payload: 10kB, Body: 1kB, Allocations: 213223)

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

IoToResponsePayloadRatio.configure do |config|
  config.warn_threshold = 0.8
end

При снижении ниже порога нужно использовать WARN с подробным описанием ситуации; для начала ограничимся следующим:

I/O to response payload ratio is 0.4, while threshold is 0.8

В идеальном случае ratio должен быть близок к единице 🙂

Для первой версии ограничимся только подсчетом объема данных, полученных из БД, но стоит заложить в архитектуру гема возможность учитывать и другие источники данных — Redis, HTTP–запросы, и так далее.

Советы по реализации

Для того, чтобы узнать, какое количество данных было получено из БД, можно попробовать посмотреть события в ActiveSupport::Notifications, или запатчить класс, отвечающий за выполнение запросов.

Вот так Rails пишет в логи.

Инструкции по выполнению

1. (Опционально) Придумать имя покороче 🙂
2. Форкнуть проект io_to_response_payload_ratio на GitHub.
3. Реализовать необходимый функционал.
4. Сделать PR.