時々、30秒かかるPostgresクエリを実行します。その後、すぐに同じクエリを実行すると、2秒かかります。 Postgresには何らかのキャッシュがあるようです。そのキャッシュが保持しているものをどうにか見ることができますか?チューニングの目的ですべてのキャッシュを強制的にクリアできますか?
注:基本的に、次のSQL Serverコマンドのpostgresバージョンを探しています。
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
しかし、そのバッファに実際に含まれているものを確認する方法も知りたいです。
助けてくれてありがとう。
Pg_buffercacheモジュールを使用して、PostgreSQLバッファキャッシュの内容を確認できます。 「 Inside the PostgreSQL Buffer Cache 」と呼ばれるプレゼンテーションを行って、表示内容を説明し、それに伴う情報の解釈に役立つ、より複雑なクエリをいくつか示します。
一部のシステムでは、オペレーティングシステムのキャッシュも参照できます。多少粗い例については、 pg_osmem.py を参照してください。
キャッシュを簡単にクリアする方法はありません。 Linuxでは、データベースサーバーを停止し、 drop_caches 機能を使用してOSキャッシュをクリアできます。最初に同期を実行するために、そこの警告に注意してください。
PostgreSQLでキャッシュをフラッシュするコマンドを見たことはありません。表示されるのは、通常のインデックスとデータキャッシュがディスクから読み取られ、メモリに保持されているだけです。 postgresqlとOSのキャッシュの両方によって。すべてを取り除くために、私が知っている唯一の方法:
あなたがすべきことは:
私のLinuxボックスでこのコマンドを使用します。
sync; /etc/init.d/postgresql-9.0 stop; echo 1 > /proc/sys/vm/drop_caches; /etc/init.d/postgresql-9.0 start
キャッシュは完全に削除されます。
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秒かかりました。
はい、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)と一致しません
私は現在の計画をフラッシュすることを探していましたが、これが見つかりました:
私は挿入物の間にこれを持っていて、それが私の問題を解決します。
はい、共有バッファpostgresキャッシュ[〜#〜]と[〜#〜]OSキャッシュの両方をクリアできます。以下の解決策は、Windows...のためです...
多くの人がすでに言ったように、共有バッファをクリアするには、Postgresを再起動するだけです(サーバーを再起動する必要はありません)。ただし、これを行ってもOSキャッシュはクリアされません。
Postgresが使用するOSキャッシュをクリアするには、サービスを停止した後、excelentRamMap( https://technet.Microsoft.com/en-us/sysinternals/rammap )、優れたSysinternals Suiteから。 RamMapを実行したら、メインメニューで[空]-> [スタンバイリストを空にする]をクリックします。
Postgresを再起動すると、キャッシュがないため次のクエリが遅くなることがわかります。
また、Postgresを閉じずにRamMapを実行することもできます。既に述べたように、通常、共有バッファーはOSキャッシュと比較してほとんど影響を与えないため、「キャッシュなし」の結果が得られます。しかし、信頼性の高いテストのために、OSキャッシュをクリアして確認する前に、postgresをすべて停止することをお勧めします。
注:私の知る限り、RamMapを使用しているときに「スタンバイリスト」以外の項目をクリアすることはお勧めしません。他のデータが何らかの形で使用されているためです。 postgresファイルだけでなく、他のアプリやOSでも使用されているメモリをクリアしていることに注意してください。
よろしく、チアゴL.
がある pg_buffercache
を調べるモジュールshared_buffers
キャッシュ。また、ある時点でキャッシュをドロップして「コールド」キャッシュのパフォーマンステストを行う必要があったため、これを正確に行う pg_dropcache 拡張機能を作成しました。チェックアウトしてください。
これは私のショートカットです
echo 1 > /proc/sys/vm/drop_caches; echo 2 > /proc/sys/vm/drop_caches; echo 3 > /proc/sys/vm/drop_caches; rcpostgresql stop; rcpostgresql start;