Original Message:
Sent: Wed October 04, 2023 02:55 PM
From: Mario Barbosa
Subject: dbs_partn_ mutex contention
Hello everyone. About this issue, how was it finally resolved? We have the same case in 12.10 FC4. We followed the recommendation of multiple temporary dbspaces and the problem continues. The only solution is to restart the engine but it is a production system.
Thanks for your help in advance
------------------------------
Mario Barbosa
------------------------------
Original Message:
Sent: Fri August 11, 2023 04:13 AM
From: Andreas Legner
Subject: dbs_partn_ mutex contention
I'd doubt a relation between VP mutex free list size (a per-VP cache of currently unused mutex structures) and contention on certain (used) mutexes, so, while it's true that onmode -F returns certain unused memory, in an attempt to then freeing entire shmem segments, any observed effect on mutex contention might be either some more indirect effect or coincidence only.
I'd try adding more temp dbspaces, hoping to better spread the temp table load and thus reducing the contention on each of them.
HTH,
Andreas
------------------------------
Andreas Legner
Original Message:
Sent: Fri August 11, 2023 02:25 AM
From: Dennis Melnikov
Subject: dbs_partn_ mutex contention
Yes, they are temp dbspaces. Your guess is highly likely true, many sessions are creating and dropping temp tables.
BTW, 'onmode -F' proved itself to be a fairly effective way to cut Number of mutexes on VP free lists and to eliminate the mutex contention.
------------------------------
Sincerely,
Dennis
Original Message:
Sent: Wed August 09, 2023 03:48 PM
From: Andreas Legner
Subject: dbs_partn_ mutex contention
That number in dbs_partn_<#> is a dbspace number.
Any change dbspaces #32 + #37 are (used as) temp dbspaces? Just a guess: might high amount of temp tables being created and discarded by many sessions in parallel?
------------------------------
Andreas Legner