Почему добавление рабочих единорогов не увеличивает пропускную способность (heroku, rails, postgres, memcachier) - PullRequest
Новая
       15

Почему добавление рабочих единорогов не увеличивает пропускную способность (heroku, rails, postgres, memcachier)

0 голосов
/ 22 января 2019

Это про героку, рельсы, postgres, приложение memcachier.

rails (3.2.16) единорог (4.8.3)

Мы работаем с кластером из 2X (общих) динамов героку.Каждый динамометр работает под управлением единорога с 3 рабочими, что примерно соответствует пределу памяти, который может быть обработан с помощью 2X динамо.

Мы иногда сталкиваемся с ошибками экземпляров, когда запросы на одном экземпляре постепенно замедляются, что приводит к сбою этого экземпляра.и требует перезагрузки.Остальная часть кластера не затронута.Newrelic часто сообщает, что сетевые операции postgres, кэширования или удаленных API-интерфейсов занимают много времени в транзакциях, о которых он сообщает.

Я подозреваю, что это связано с небольшим сетевым сбоем / замедлением, которое создает резервную копию экземпляра, вызываетнедоступный кэш (короткий тайм-аут), который усугубляет проблему

Чтобы преодолеть это, я хотел бы увеличить параллелизм и покинуть мир общих динамов

Обновление до динамов Pm кажется хорошимidea

При включении динамометров PM я не могу увеличить пропускную способность за счет увеличения количества рабочих.Метрики Heroku сообщают, что динамометрическая нагрузка увеличивается пропорционально, но метрики heroku не сообщают о каком-либо увеличении пропускной способности (RPS) при увеличении количества рабочих.

Добавление второго динамометра удваивает заявленную пропускную способность

Так с этим фоном.Мой вопрос:

Как я могу выяснить, почему увеличение числа рабочих-единорогов не увеличивает сообщаемую пропускную способность?

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

unicorn.rb 

UNICORN_WORKER_COUNT = (ENV.fetch('UNICORN_WORKER_COUNT', 3).to_i || 3) # amount of unicorn workers to spin up

puts "UNICORN_WORKER_COUNT=#{UNICORN_WORKER_COUNT}"

worker_processes UNICORN_WORKER_COUNT
timeout 35         # restarts workers that hang for 35 seconds, 5 seconds longer than heroku timeout

preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

before_fork do |server, worker|
  puts "Unicorn before_fork nr=#{worker.nr}"

  Signal.trap 'TERM' do
    puts 'Unicorn master intercepting TERM and sending myself QUIT instead'
    Process.kill 'QUIT', Process.pid
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  puts "Unicorn after_fork nr=#{worker.nr}"

  Signal.trap 'TERM' do
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to send QUIT'
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

backlog_setting = Integer(ENV['UNICORN_BACKLOG'] || 1024)

puts "Unicorn PORT=#{ENV['PORT']} UNICORN_BACKLOG=#{backlog_setting}"

listen ENV['PORT'], :backlog => backlog_setting
...