On 04/02/2026 10:57, Ronald Klop wrote:
You could post more information about the system.
Ah, yes, sorry, should have done that!
Its an AWS c6id.8xlarge instance which is
64 gig of memory
32 cores (16 physical, with hyperthreads)
it has local SSD, on top of which is geli, and on
top of that is ZFS, compressed with ztsd, which
is where the mysql data lives. I cap the ARC at
32 gig, and it does eventually fill that over
time (or did on 14 anyway).
top of top...
CPU: 20.7% user, 0.0% nice, 31.8% system, 1.2% interrupt, 46.3% idle
Mem: 16G Active, 2551M Inact, 22G Wired, 21G Free
ARC: 18G Total, 1958M MFU, 16G MRU, 133M Anon, 231M Header, 12M Other
17G Compressed, 126G Uncompressed, 7.58:1 Ratio
Swap: 16G Total, 16G Free
Something which pops up in my mind is that it might be interesting if it
is a NUMA system.
The CPU is, apparently, a Xeon Platinum 8375C, so yes, could
well be NUMA, and though I would hope that AWS hypervisor would
put all my virtual cores onto a single real CPU, there's still
all that on-die stuff between cores... does the OS know about
that ?
Is it possible to get the output of "procstat -kk <pid-of-mysqld>" when
it is contending on these locks? That would show if it is waiting in the
kernel or not.
Certainly!
https://api.ticketswitch.com/shared/mysql.procstat.kk.txt
But - check my thinking here - a load average is the runnable
processes, right ? So if they were simply stuck waiting on
some events, they would not be runnable, and thus wouldn't add
to the load average ?
[ Actually, having typed that sentance, I am now wondering if
this is due to some improvement in 15, so processes are now
waiting less, and completing faster, and thus letting another
one which was waiting on a lock become runnable, so we see more
active processes in a 'lav' timeslot ? ]
-pete.
