のPostgresサーバのシャットダウンは、私は私のレールのアプリで次のエンドポイントを持っているのActiveRecordクエリ

Question

から小さなデータセット上のすべての選択：これまでのところ

def index 
if params.key?(:start) 
     if params[:start].to_i.to_s == params[:start] #unix epoche time format 
      p = Param 
        .where(devise_id: params[:devise_id]) 
        .where('"TimeStamp" >= ?', Time.at(params[:start].to_i)) 
        .order('created_at DESC') 
     else 
      raise Exceptions::RequestError, '...' 
     end 
end 

とても良いです。 paramsテーブルには、希望するdevise_idの約20000エントリがあります。私はこのPostgreSQLのクラッシュを再現することができませんでした

2016-12-08 12:22:58 CET LOG: server process (PID 16510) was terminated by signal 9: Killed 
2016-12-08 12:22:58 CET DETAIL: Failed process was running: SELECT COUNT(*) FROM "params" WHERE "params"."devise_id" = $1 
2016-12-08 12:22:58 CET LOG: terminating any other active server processes 

：しかし、返すために1つのAPIコールは、すべての20000のエントリのPostgresは、次のエラーメッセージを表示してシャットダウンを得ました。

ただし、ユニコーンは30秒後にタイムアウトするように設定されています。このエンドポイントをテストすると、応答時間が若干長くなることがあるので、unicorn workerがkillされ、もう1つがunicorn masterによって開始されます。 データベースのアクセスには数ミリ秒かかりますが、ルビーハッシュのすべてのデータのフォーマットにはほとんどの時間がかかります。

ここで、なぜpostgresqlサーバーがクラッシュしたのか、そしてこれを防ぐ方法を理解したいと思います。 psqlでは20000エントリはほとんどありません。 これは一度しか登場しますが、私はそのように維持したいと思います;）

スタック：9.3.13

ユニコーン

• はpsql（PostgreSQLの）5.1.0
• のRails 4.2.7
• ルビー2.3.0

Answer 1

これはおそらく、あなたのためにやり過ぎですが、私たちは殺さプロセスやPostgreSQLのSERのいくつかの例を持っていたので、 verはリカバリモードに入り、他のセッションをキャンセルします。私たちは接続プールのためにpgbouncerをインストールしました。このように、データベースはこれらのケースの多くから保護されています。