Heroku Puma Sidekiq Running 167% kritische r14 Speicherkontingent überschritten auf 3 Web-Dynos mit einem Besucher

Question

Ich betreibe Puma 3.4, Rails 4.2.6, Sidekiq 4.2.2, Redis Mini, auf 3 Dynoden (Standard 1x) auf Heroku. Ich mache einfache Beta-Tests und ich kann meine Puma-Dyno Situation nicht optimieren. Wenn ein Benutzer auf der Site ist, erhalte ich Warnungen bei hoher Reaktionszeit und kritische Speicherkontingente (ich verwende New Relic zur Überwachung).

Ich habe Puma Worker Killer hinzugefügt, um dies zu diagnostizieren, aber keine Hilfe.

Ich habe alles mit Umgebungsvariablen (max_threads, Nebenläufigkeit, etc) eingestellt und ich habe das Internet für die Konfiguration durchforstet.

Ich setze Optionen in database.yml, sidekiq.rb, puma.rb, puma_worker_killer.rb und sidekiq.yml, also könnte ich Dinge an zu vielen Orten setzen.

Da ich 3 Standard 1x Web-Dynos für einen Benutzer betreibe, weiß ich, dass etwas nicht stimmt.

config/puma.rb

before_fork do 
    require 'puma_worker_killer' 
    ActiveRecord::Base.connection_pool.disconnect! 

    PumaWorkerKiller.config do |config| 
    config.ram   = ENV['PUMA_WORKER_KILLER_RAM'] || 1024 # mb 
    config.frequency  = 5 # seconds 
    config.percent_usage = 0.98 
    config.rolling_restart_frequency = 12 * 3600 # 12 hours in seconds 
    end 

    PumaWorkerKiller.start 
end 

workers Integer(ENV['WEB_CONCURRENCY'] || 5) 

min_threads_count = Integer(ENV['MIN_THREADS'] || 1) 

threads_count = Integer(ENV['RAILS_MAX_THREADS'] || 5) 

threads min_threads_count, threads_count 

preload_app! 

rackup  DefaultRackup 
port  ENV['PORT']  || 5000 
environment ENV['RACK_ENV'] || 'development' 

on_worker_boot do 


    ActiveSupport.on_load(:active_record) do 
    ActiveRecord::Base.establish_connection 
    end 
end 

config/Initialisierungen/sidekiq.rb

require 'sidekiq' 

redis_url = ENV['REDISTOGO_URL'] 

redis_config = { 
    url: redis_url, 
    namespace: 'oct', 
} 

Sidekiq.configure_server do |config| 
    config.redis = { url: ENV["REDISTOGO_URL"], namespace: 'oct', size: ENV["SIDEKIQ_SERVER_CONNECTIONS"].to_i || 6} 

    config.error_handlers << Proc.new do |exception, context_hash| 
    SidekiqErrorService.new(exception, context_hash).notify 
    end 
end 

Sidekiq.configure_client do |config| 
    config.redis = { url: ENV["REDISTOGO_URL"], namespace: 'oct', size: ENV["REDIS_CLIENT_CONNECTION_SIZE"].to_i || 2} 
end 

config/sidekiq.yml

:verbose: false 

:concurrency: <%= ENV["WEB_CONCURRENCY"] %> 

production: 
    :timeout: <%= ENV["SIDEKIQ_TIMEOUT"] %> 
development: 
    :timeout: 30 

:queues: 
    - [highest, 2] 
    - medium 
    - lowest 
    - mailers 

config/Initialisierungen/puma_worker_killer.rb

PumaWorkerKiller.enable_rolling_restart 

config/database.yml

default: &default 
    adapter: postgresql 
    encoding: unicode 
    pool: <%= ENV["DB_POOL"] || ENV['RAILS_MAX_THREADS'] || 5 %> 

development: 
    <<: *default 
    database: myapp_development 
    username: myapp 
    password: myapp 
    host: localhost 
    port: 5432 
test: 
    <<: *default 
    database: myapp_test 
    username: myapp 
    password: myapp 
    host: localhost 
    port: 5432 

meine aktuellen Umgebungseinstellungen

Speicher 125-167% (auf Web-Prüfständen, nicht Arbeiter dynos)

WEB_CONCURRENCY: 4 
DB_POOL: 15 
SIDEKIQ_SERVER_CONNECTIONS: 25 
MIN_THREADS: 1 
RAILS_MAX_THREADS: 5 
REDIS_CLIENT_CONNECTION_SIZE: 1 
SIDEKIQ_TIMEOUT: 30 
DATABASE_REAP_FREQ: 5 
PUMA_WORKER_KILLER_RAM: 1535 

Ich habe auch versucht, diese zu verwenden Helfer http://manuelvanrijn.nl/sidekiq-heroku-redis-calc/

aber es machte es schlimmer, 300% + Speicher Verwendung

WEB_CONCURRENCY: 45 
DB_POOL: 15 
SIDEKIQ_SERVER_CONNECTIONS: 47 
MIN_THREADS: 1 
RAILS_MAX_THREADS: 5 
REDIS_CLIENT_CONNECTION_SIZE: 1 
SIDEKIQ_TIMEOUT: 30 
DATABASE_REAP_FREQ: 5 
PUMA_WORKER_KILLER_RAM: 1535 

Answer 1

Für eine Rails 4 haben Sie zu viele Puma-Arbeiter sogar bei 4 (45 ist unmöglich hoch für diese Stufe). Standard-1x Dynos haben 512 MB. Versuchen Sie WEB_CONCURRENCY runter auf 2 und ich vermute, dass Sie eine genügend große Reduzierung des Speicherverbrauchs sehen werden, um R14s zu verhindern.

Wenn Sie immer noch Probleme haben, nachdem Sie WEB_CONCURRENCY auf 2 umgestellt haben, müssen Sie einige Speicheroptimierungen durchführen oder auf 1 reduzieren.