[ClusterLabs] Antw: [EXT] unexpected fenced node and promotion of the new master PAF ‑ postgres
Jehan-Guillaume de Rorthais
jgdr at dalibo.com
Thu Jul 22 09:06:20 EDT 2021
On Wed, 14 Jul 2021 07:58:14 +0200
"Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de> wrote:
> Could it be that a command saturated the network?
> Jul 13 00:39:28 ltaoperdbs02 postgres: [20-1] 2021-07-13 00:39:28.936
> UTC  LOG: duration: 660.329 ms execute <unnamed>: SELECT
> xmf.file_id, f.size, fp.full_path FROM ism_x_medium_file xmf JOIN#011
> ism_files f ON f.id_file = xmf.file_id JOIN#011 ism_files_path fp ON
> f.id_file = fp.file_id JOIN ism_online o ON o.file_id = xmf.file_id WHERE
> xmf.medium_id = 363 AND xmf.x_media_file_status_id = 1 AND
> o.online_status_id = 3 GROUP BY xmf.file_id, f.size, fp.full_path LIMIT
> 7265 ;
I doubt such a query could saturate the network. The query time itself isn't
proportional to the result set size.
Moreover, there's only three fields per row and according to their name, I
doubt the row size is really big.
Plus, imagine the result set is that big, chances are that the frontend will
not be able to cope with it as fast as the network, unless the frontend is doing
nothing really fancy with the dataset. So the frontend itself might saturate
before the network, giving some break to the later.
However, if this query time is unusual, that might illustrate some pressure on
the server by some other mean (CPU ? MEM ? IO ?). Detailed metrics would help.
More information about the Users