때때로 Postgres 쿼리를 실행하는 데 30 초가 걸립니다. 그런 다음 즉시 동일한 쿼리를 실행하고 2 초가 걸립니다. Postgres에는 일종의 캐싱이있는 것 같습니다. 캐시가 무엇을 보유하고 있는지 어떻게 든 볼 수 있습니까? 튜닝을 위해 모든 캐시를 강제로 지울 수 있습니까?
참고 : 기본적으로 다음 SQL Server 명령의 postgres 버전을 찾고 있습니다.
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
그러나 실제로 해당 버퍼에 무엇이 포함되어 있는지 확인하는 방법도 알고 싶습니다.
도움을 주셔서 감사합니다.
답변:
pg_buffercache 모듈을 사용하여 PostgreSQL 버퍼 캐시에 무엇이 있는지 확인할 수 있습니다. 여러분이보고있는 내용을 설명하는 " In the PostgreSQL Buffer Cache " 라는 프레젠테이션을 수행했으며 그와 함께 제공되는 정보를 해석하는 데 도움이되는 좀 더 복잡한 쿼리를 보여줍니다.
일부 시스템에서도 운영 체제 캐시를 볼 수 있습니다. 다소 대략적인 예는 [pg_osmem.py]를 참조하십시오.
캐시를 쉽게 지울 수있는 방법은 없습니다. Linux에서는 데이터베이스 서버를 중지하고 drop_caches 기능을 사용 하여 OS 캐시를 지울 수 있습니다. 먼저 동기화를 실행하려면 경고에 유의하십시오.
PostgreSQL에서 캐시를 플러시하는 명령을 보지 못했습니다. 당신이 보는 것은 디스크에서 읽고 메모리에 보관되는 정상적인 인덱스 및 데이터 캐시 일 것입니다. postgresql과 OS의 캐시 모두에 의해. 이 모든 것을 없애기 위해 내가 아는 유일한 방법 :
해야 할 일은 다음과 같습니다.
sudo service postgresql stop, sudo systemctl stop postgresql, 등)echo 3 > /proc/sys/vm/drop_caches
이렇게하면 OS 파일 / 블록 캐시가 지워집니다. 다른 OS에서이 작업을 수행하는 방법을 모르지만 매우 중요합니다. (허가가 거부 된 경우 해당 질문sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" 에서와 같이 시도하십시오. )sudo service postgresql start, sudo systemctl start postgresql)drop_caches에 대한 Greg Smith의 답변은 매우 유용했습니다. 캐시를 삭제하는 것 외에도 postgresql 서비스를 중지하고 시작해야한다는 것을 알았습니다. 트릭을 수행하는 쉘 스크립트가 있습니다. (내 환경은 Ubuntu 14.04 및 PostgreSQL 9.3입니다.)
#!/usr/bin/sudo bash
service postgresql stop
sync
echo 3 > /proc/sys/vm/drop_caches
service postgresql start
처음에는 19 초가 걸리고 후속 시도에서는 2 초 미만이 소요되는 쿼리로 테스트했습니다. 이 스크립트를 실행 한 후 쿼리에 다시 19 초가 걸렸습니다.
내 Linux 상자에서이 명령을 사용합니다.
sync; /etc/init.d/postgresql-9.0 stop; echo 1 > /proc/sys/vm/drop_caches; /etc/init.d/postgresql-9.0 start
캐시를 완전히 제거합니다.
postgresql하며 그렇지 않을 수도 있습니다.
sync있기 때문에 서버를 중지 한 직후에 완료해야 한다고 생각 drop_caches합니다.
예, postgresql에는 확실히 캐싱이 있습니다. 크기는 shared_buffers 설정에 의해 제어됩니다. . 그 외에도 이전 답변에서 언급했듯이 OS 파일 캐시도 사용됩니다.
캐시에 무엇이 있는지보고 싶다면 pg_buffercache 라는 contrib 모듈이 있습니다. 사용할 수 있습니다 (소스 트리의 contrib /, contrib RPM 또는 설치 방법에 적합한 위치). 사용 방법은 표준 PostgreSQL 문서에 나와 있습니다.
서버를 다시 시작하는 것 외에는 버퍼 캐시를 지우는 방법이 없습니다. OS가 Linux 인 경우 다른 답변에 언급 된 명령을 사용하여 OS 캐시를 삭제할 수 있습니다.
이 오류가 발생했습니다.
psql : /cygdrive/e/test_insertion.sql : 9 : 오류 : 매개 변수 53 유형 (t_stat_gardien)이 계획을 준비 할 때 (t_stat_avant)와 일치하지 않습니다.
나는 현재 계획을 플러시하고 있었고 이것을 발견했습니다.
나는 삽입물 사이에 이것을 가지고 내 문제를 해결합니다.
DISCARD PLANS;입니다. 또한 문서에 "DISCARD는 데이터베이스 세션 과 관련된 내부 리소스를 해제 합니다."라고 말합니다.
예, 공유 버퍼 postgres 캐시 와 OS 캐시를 모두 지울 수 있습니다 . 해결 방법은 Windows 용입니다. . 다른 사람들은 이미 Linux 솔루션을 제공했습니다.
많은 사람들이 이미 말했듯이 공유 버퍼를 지우려면 Postgres를 다시 시작할 수 있습니다 (서버를 다시 시작할 필요 없음). 그러나 이렇게하는 것만으로는 OS 캐시가 지워지지 않습니다.
Postgres에서 사용하는 OS 캐시를 지우려면 서비스를 중지 한 후 탁월한 RamMap ( https://technet.microsoft.com/en-us/sysinternals/rammap 런트 Sysinternals Suite에서 )을 . RamMap을 실행 한 후 메인 메뉴에서 "Empty"-> "Empty Standby List"를 클릭하십시오.
Postgres를 다시 시작하면 캐시가 전혀 없어 다음 쿼리가 느려질 것입니다.
Postgres를 닫지 않고 RamMap을 실행할 수도 있으며, 사람들이 이미 말했듯이 공유 버퍼는 일반적으로 OS 캐시에 비해 거의 영향을주지 않기 때문에 원하는 "캐시 없음"결과를 얻을 수 있습니다. 그러나 신뢰할 수있는 테스트를 위해 OS 캐시를 삭제하기 전에 Postgres를 중지하는 것이 좋습니다.
참고 : AFAIK, RamMap을 사용할 때 "대기 목록"이외의 다른 데이터를 지우지 않는 것이 좋습니다. 다른 데이터가 어떻게 든 사용 중이기 때문이며 그렇게하면 잠재적으로 문제가 발생하거나 데이터가 손실 될 수 있습니다. postgres 파일뿐만 아니라 다른 앱과 OS에서도 사용되는 메모리를 지우는 것입니다.
감사합니다. Thiago L.
캐시 pg_buffercache를 살펴볼 모듈 이 있습니다 shared_buffers. 그리고 어느 시점에서 나는 '콜드'캐시에 대한 성능 테스트를 위해 캐시를 삭제해야했기 때문에 정확히 이것을 수행 하는 pg_dropcache 확장을 작성했습니다 . 그것을 확인하시기 바랍니다.