Why does a rails application slow down terribly on the server, although everything flies to localhost?

Question

PostgreSQL

The rails application is deployed on the capistrano+unicorn+nginx server. Until yesterday, no brakes were observed, no changes were made to the server settings from the very beginning, and the beginning was about two months ago.
I run cap production deploy in the terminal, after that I go to the site everything works, without brakes, even faster than on localhost, after about five minutes some kind of "plug" happens and everything starts to slow down terribly. Creating posts, comments, voting, deleting, editing. Any operation takes from 5 to 20 seconds, by the way, just like opening an article page. I didn't find any errors in the logs.
At first I thought that the problem lies in Turbolinks, but as it turned out, no. I updated all the software on the production server - it did not help.
Where to dig I do not know. I will be glad for any help!
Here is my Gemfile:

source 'https://rubygems.org'
ruby '2.2.1'



gem 'rails', '4.2.1'
gem 'bootstrap-sass', '~> 3.3.6'
gem 'font-awesome-sass'
gem 'carrierwave'
gem 'mini_magick'
gem 'remotipart', '~> 1.2'
gem 'russian', '~> 0.6.0'

gem 'will_paginate', '~> 3.1.0'

gem 'sass-rails', '>= 3.2'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.1.0'


gem 'jquery-rails'

gem 'turbolinks'

gem 'jbuilder', '~> 2.0'

gem 'sdoc', '~> 0.4.0', group: :doc

gem 'devise'
gem 'omniauth'
gem 'omniauth-facebook'
gem 'omniauth-vkontakte'
gem 'cancancan', '~> 1.10'
gem 'friendly_id', '~> 5.1.0'
gem 'cancancan', '~> 1.10'
gem 'rolify'


group :test do
  gem 'selenium-webdriver'
  gem 'capybara'
end

group :development, :test do
  gem 'sqlite3'
  gem 'rspec-rails'
  gem 'byebug'

  gem 'web-console', '~> 2.0'

  gem 'spring'
end
group :development do
  gem 'capistrano'
  gem 'capistrano-rails'
  gem 'capistrano-bundler'
  gem 'capistrano-rvm'
  gem 'capistrano-passenger'
  gem 'capistrano-bower'
end

group :production do
  gem 'pg'
  gem 'rails_12factor'
  gem 'unicorn'
end

Maybe some other file needs to be shown, I don’t know if write something.
--------
Updated 30/08
Today I set up a log of slow queries in the database config. At the beginning, something went wrong, and the site stopped responding to requests at all. I rolled back the database config settings, everything worked. And, which does not please me at all, it has been working for a couple of hours without failures very quickly, as I just did not excel. It would be better if I found the problem, now figs understand ...
What to do next?
-----
Output top during "plugging"

Answer 1

Today I set up a log of slow queries in the database config. At the beginning, something went wrong, and the site stopped responding to requests at all. I rolled back the database config settings, everything worked. And, which does not please me at all, it has been working for a couple of hours without failures very quickly, as I just did not excel. It would be better if I found the problem, now figs understand ...
What to do next?
______________________
Found a solution to the problem! It was in unicorn.rb
. I didn't have before_fork and after_fork sections.
Right now my unicorn.rb looks like this:

APP_PATH = File.expand_path('../../', __FILE__)

working_directory APP_PATH
listen            APP_PATH + '/tmp/sockets/unicorn.sock'
worker_processes  2
timeout           30
preload_app       true

before_exec do |server|
  ENV['BUNDLE_GEMFILE'] = APP_PATH + '/Gemfile'
end

before_fork do |server, worker|
  ActiveRecord::Base.connection.disconnect! if defined?(ActiveRecord::Base)
end

after_fork do |server, worker|
  ActiveRecord::Base.establish_connection if defined?(ActiveRecord::Base)
end

Answer 2

It's strange that they haven't asked yet - what does top show?
Maybe there is simply not enough memory and everything goes into swap.

Answer 3

I bet the database is slowing down the application.
Profile calls to the database, look at the database logs.

Answer 4

Set up a slow query log in the database config.

Answer 5

This confirms the version that the problem was in the DBMS. Dig in that direction.