PostgreSQL 9.1.1 및 Rails 3.2.8을 사용하고 있습니다. NewRelic의 개발 모드를 사용하여 여러 SQL 쿼리가 후속 요청보다 서버를 시작하거나 다시 시작한 첫 번째 요청 중에 훨씬 더 오래 걸리는 것으로 나타났습니다.PostgreSQL 쿼리가 서버 시작 후 첫 번째 요청에서 후속 요청보다 느린 이유는 무엇입니까?
준비된 진술로 인해 그 이유가 있습니까?
시작 직후에는 인덱스가 메모리에로드되지 않으므로 서버는 매우 느린 디스크 읽기를 많이해야합니다. 활동이 점점 더 진행됨에 따라 인덱스 페이지가 메모리에로드되고 이러한 페이지에 대한 컨설팅이 훨씬 더 빠릅니다.
서버가 호스팅되는 OS는 무엇입니까? Linux에서 파일 시스템은 파일에 RAM 캐시를 사용합니다. 새 파일을 열어야 할 때 여유 공간이 있으면 캐시에 저장됩니다. 공간이 없으면 가장 오래된/마지막으로 액세스 한 파일이 제거되어 새 파일을위한 공간을 만듭니다. PostgreSQL은 관계 (테이블과 인덱스)를 파일로 저장합니다. 파일을 처음 읽으면 Linux 파일 시스템이 파일을 메모리로로드합니다. 이렇게하면 데이터에 훨씬 빠르게 액세스 할 수 있습니다. 그러나 초기 읽기의 오버 헤드는 당신이 겪고있는 "느린"것입니다. 캐시를 스왑하지 않는 한 후속 데이터 읽기는 RAM에서 직접 수행됩니다.
제 경험상, 테이블과 인덱스의 크기를 모니터링해야합니다. 크기가 너무 커지면 이러한 "괴물 테이블"에서 하나의 쿼리로 다른 일반적으로 사용되는 모든 파일이 캐시에서 벗어나 전체 시스템이 손상 될 수 있습니다. 테이블을 더 작게 유지하십시오 (백만 행의 범위에 들어갈 경우 파티셔닝을 시도하십시오). 그리고 날짜 대신 인덱스를 사용하는 매우 정확한 필드에 대해서는 인덱스하지 마십시오. 인덱스 노드가 적어지며 인덱스가 작아집니다. 파일 (매일 많은 레코드가 있다고 가정). 이렇게하면 OS가 캐시간에 관계를 훨씬 효율적으로로드 할 수있게되고 속도 차이를 많이 느끼지 않게됩니다.
Windows에서 호스팅되는 경우 성능 문제를 설명 할 수 없습니다. * nix 서버로 옮길 필요가 있다면 성능에 관한 PostgreSQL의 문서를 진지하게 읽어야합니다.
9.2+에서''EXPLAIN (BUFFERS, ANALYZE)/* query * /;''를 사용하면 이것을 볼 수 있습니다. 첫 번째 실행은 "read"계획 항목을 가질 것이고, 후속 실행은''shared''가 0이되지 않을 것입니다. – Sean
장기간 사용하지 않으면 비슷한 지연이 발생하는 이유는 무엇입니까? –