On 14/11/2024 21:10, Joseph Salisbury wrote:
Hi Joseph,
> On 10/17/24 01:19, Cristian Prundeanu wrote:
[...]
> Hi Cristian,
>
> This is a confirmation that we are also seeing a 9% performance
> regression with the TPCC benchmark after v6.6-rc1. We narrowed down the
> regression was caused due to commit:
> 86bfbb7ce4f6 ("sched/fair: Add lag based placement")
>
> This regression was reported via this thread:
> https://lore.kernel.org/lkml/1c447727-92ed-416c-bca1-a7ca0974f0df@xxxxxxxxxx/
>
> Phil Auld suggested to try turning off the PLACE_LAG sched feature. We
> tested with NO_PLACE_LAG and can confirm it brought back 5% of the
> performance loss. We do not yet know what effect NO_PLACE_LAG will have
> on other benchmarks, but it indeed helps TPCC.
Can you try to run mysql in SCHED_BATCH when using EEVDF?
https://lkml.kernel.org/r/20241029045749.37257-1-cpru@xxxxxxxxxx
The regression went away for me when changing mysql threads to SCHED_BATCH.
You can either start mysql with 'CPUSchedulingPolicy=batch':
#cat /etc/systemd/system/mysql.service
[Service]
CPUSchedulingPolicy=batch
ExecStart=/usr/local/mysql/bin/mysqld_safe
# systemctl daemon-reload
# systemctl restart mysql
or change the policy with chrt for all mysql threads when doing
consecutive test runs starting from the 2. run ('connection' threads
have to exists already)
# chrt -b -a -p 0 $PID_MYSQL
# ps -p $PID_MYSQL -To comm,pid,tid,nice,class
COMMAND PID TID NI CLS
mysqld 4872 4872 0 B
ib_io_ibuf 4872 4878 0 B
...
xpl_accept-3 4872 4921 0 B
connection 4872 5007 0 B
...
connection 4872 5413 0 B
My hunch is that this is due to the 'connection' threads (1 per virtual
user) running in SCHED_BATCH. I yet have to confirm this by only
changing the 'connection' tasks to SCHED_BATCH.
[..]
|