このトピックは2011年に取り上げられ、PostgreSQLをLinuxで強化するための設計上の考慮事項があるというコンセンサスが得られました。今は2015年ですが、それは変わりましたか? Windows上でPostgreSQLを遅くするものがある場合、誰かがそれらのポイントを要約できますか?
この回答で私が説明した点に注意を払えば、PostgreSQLはWindowsでもかなりうまく機能すると思います。 2011年と比べると大きな違いはありません。
私の経験から、それは主にWindowsプロセスが邪魔にならないように注意することですので、本からのこの引用 PostgreSQL 9.0 High Performace(2010 ) まだ大部分は成り立っています:
予測できないパフォーマンスとWindows
真面目なデータベース管理者は、サーバーにUNIXライクなシステムを使用することに強い歴史的偏見を持っています。ここでの最初の例は、作成されたグラフが読みやすく、したがってこのセクションの概念を紹介するのに適しているため、代わりにWindowsを使用しています。しかし、そうすることで、Windowsがそれほど多くの人々のオペレーティングシステムをホストするデータベースとして好まれない理由を思い出しました。
有用なベンチマーク結果を得るには、システムが静止している必要があります。つまり、測定対象の結果を損なうような実行中の他のプログラムがないことです。これらの結果を生成するためにWindowsVistaを起動すると、TrustedInstallerプロセスがかなりの量のCPUおよびディスクリソースを占有していることがわかりました。 Windows Updateは、次の主要なVista ServicePackをインストールする時期であると判断したことが判明しました。それはバックグラウンドでピースをダウンロードし、あらゆる機会にアップグレードに向けて私を押し進めていました。 2時間後、すべてのバックグラウンドアクティビティを完了し、処理を余儀なくされ、これらのテストを実行できるアイドル状態のシステムができました。
Windows2012のServerCoreエディションを支持することで、これを少し改善できると思うかもしれません。 MSDNの記事 Server Coreが役立つ理由 (Windows 2008について)は次のように述べています。
Server Coreの利点を確認する前に、誤解を解き明かしましょう。パフォーマンスの向上は、Windows Server2008のフルインストールではなくServerCoreを実行する利点の1つではありません。
それ以外に、メモリ処理もWindowsで異なり、直感に反する場合があります。これも2011年と同じです。shared_buffers
たとえば( PostgreSQLドキュメント-18.4。リソース消費 から):
windowsでは、shared_buffersの大きな値はそれほど効果的ではありません。設定を比較的低く保ち、代わりにオペレーティングシステムのキャッシュをより多く使用すると、より良い結果が得られる場合があります。 Windowsシステムでのshared_buffersの有効範囲は、通常64MBから512MBです。