0

에서 작은 데이터 세트에 모두 선택 나는 내 레일 응용 프로그램에서 다음 엔드 포인트가 있습니다포스트 그레스 서버 종료 액티브 쿼리

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 개의 항목이 있습니다. 그러나 하나의 API 호출은 모두 20000 개 항목 포스트 그레스는 다음과 같은 오류 메시지와 함께 종료를 가지고 돌아갑니다 :

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 

나는이 PostgreSQL의 충돌을 재현 할 수 있습니다.

그러나 유니콘은 30 초 후에 시간 초과되도록 설정됩니다. 이 엔드 포인트를 테스트 할 때 응답이 약간 더 오랜 시간이 걸리기 때문에 unicorn worker이 죽고 unicorn 마스터가 다른 것을 시작합니다. (설계, 구현 단계에서 이것에 대해 생각하지 않았고 곧 일부 파티셔닝으로 변경하려고합니다) 데이터베이스 액세스에는 몇 밀리 초가 걸리지 만 루비 해시의 모든 데이터를 포맷하는 데 대부분 시간이 걸립니다.

나는 지금 postgresql 서버가 왜 추락했는지, 그리고 이것을 막는 지 이해하고 싶습니다. psql에서는 20000 개의 항목이 거의 없습니다. 이 한 번만 등장하지만 난 그런 식으로 계속 싶습니다)

스택 : 9.3.13

  • 유니콘

    • psql의 (PostgreSQL을)를 5.1.0
    • 레일 4.2.7
    • 루비 2.3.0
  • 답변

    0

    이 아마 당신을 위해 과잉이다하지만 우리는 사망 과정과 PostgreSQL 버리는 몇 가지 사례를 가지고 있기 때문에 ver은 복구 모드로 들어가고 다른 모든 세션을 취소합니다. 우리는 연결 풀링을 위해 pgbouncer를 설치했습니다. 이런 식으로 데이터베이스는 이러한 많은 경우로부터 보호됩니다.