私はDBAではない一人として謙虚にあなたにアプローチします。そして、私の質問は概念的な欠点と「それは地雷に依存します」でいっぱいだと確信しています。また、私が回答することを選択したすべての人が、私が現在提供できるよりも詳細な方法で多くのことを望んでいることもかなり確信しています。
とはいえ、私は一般的に次のシナリオに興味があります。
順次実行すると、平均して完了するまでに7分かかると思います。これは妥当ですか?
ただし、2つのクエリを同時に実行するとどうなるでしょうか。同時に2つの別々の接続。
さて、1,000個の重要なクエリを同時に実行していると、全体的に速度が低下するという直感があります。その場合、ボトルネックはどこにあると思われますか?プロセッサー?羊?ドライブ?
繰り返しますが、詳細を知らずに質問に正確に答えることはおそらく不可能であることを知っています(私は持っていません)。次の質問をするときに考慮するいくつかの一般的なガイドラインを探しています:
順次実行すると、平均して完了するまでに7分かかると思います。これは妥当ですか?
関連のないデータセットを使用している場合は、そうです。
データセットを共有し、最初のクエリのキャッシュがコールドで、クエリのほとんどがI/Oバウンドである場合、2番目のクエリはすぐに完了する可能性があります。パフォーマンス分析とクエリのタイミングを処理するときは、キャッシュの影響を考慮する必要があります。
ただし、2つのクエリを同時に実行するとどうなるでしょうか。同時に2つの別々の接続。
"場合によります"。
両方が同じテーブルのシーケンシャルスキャンを使用している場合、PostgreSQLでは、同期シーケンシャルスキャンがサポートされているため、パフォーマンスが大幅に向上します。
同じインデックスを共有している場合は、お互いにキャッシュに読み込んでいることでメリットが得られる可能性があります。
それらが独立していて、異なるデータを操作している場合、I/O帯域幅をめぐって競合する可能性があり、その場合、連続して実行する場合と同じ時間がかかる可能性があります。 I/Oサブシステムが同時実行性(より多くのクライアントでより高いネットスループット)の恩恵を受ける場合、合計時間は短くなる可能性があります。 I/Oサブシステムが並行性をうまく処理できない場合、順次実行するよりも時間がかかる可能性があります。または、それらがI/Oにバインドされていない場合もあります。その場合、それぞれに空きCPUがあれば、もう一方がまったく実行されていないかのように実行できます。
これは、ハードウェアとシステムの構成、データセット、およびクエリ自体に大きく依存します。
さて、1,000個の重要なクエリを同時に実行していると、全体的に速度が低下するという直感があります。その場合、ボトルネックはどこにあると思われますか?プロセッサー?羊?ドライブ?
はい、それは多くの理由で物事を遅くする可能性が非常に高いでしょう。
プロセス間の調整、トランザクションとロックの管理、バッファ管理などにおけるPostgreSQL自体のオーバーヘッド。これは非常に大きなコストになる可能性があり、PostgreSQLは実際には高いクライアント数向けに設計されていません- あなたが仕事をキューに入れればより良い 。
ワーキングメモリ、キャッシュなどの競争.
OSのスケジューリングオーバーヘッドは、必要なすべてのタイムスライスを処理する1000の競合プロセスを処理するためです。最近のマイナーな、最近のOSは高速スケジューラーを備えています。
I/Oスラッシング。ほとんどのI/Oシステムには、ピークパフォーマンスのクライアント数があります。 1の場合もあります。つまり、クライアントが1つだけの場合に最適ですが、多くの場合はそれよりも高くなります。パフォーマンスがしきい値を超えて再び低下することがあります。時にはそれは高原に達するだけです。