順次実行すると、平均して完了するまでに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つだけの場合に最適ですが、多くの場合はそれより高くなります。パフォーマンスがしきい値を超えて再び低下することがあります。時にはそれは高原に達するだけです。