Small Datum

This is part 4 of my series on using HW counters from  Linux perf  to explain why MySQL gets slower from 5.6 to 8.0. Refer to  part 1  for an overview. What happened in MySQL 5.7 and 8.0 to put so much more stress on the memory system? tl;dr It looks like someone sprinkled magic go slower dust across most of the MySQL code because the slowdown from MySQL 5.6 to 8.0 is not isolated to a few call stacks. MySQL 8.0 uses ~1.5X more instructions/operation than 5.6. Cache activity (references, loads, misses are frequently up 1.5X or more. TLB activity (loads, misses) is frequently up 2X to 5X with the iTLB being a bigger problem than the dTLB. innodb_log_writer_threads=ON is worse than I thought. I will soon have a post on that. Too long to be a tl;dr I don't have much experience using Linux perf counters to explain performance changes. There are huge increases for data TLB, instruction TLB and L1 cache counters. From the Xeon CPU (socket2 below) the change from MySQL 5.6.21 to 8.0.34 me

This is part 3 of my series on using HW counters from  Linux perf  to explain why MySQL gets slower from 5.6 to 8.0. Refer to  part 1  for an overview. What happened in MySQL 5.7 and 8.0 to put so much more stress on the memory system? tl;dr It looks like someone sprinkled magic go slower dust across most of the MySQL code because the slowdown from MySQL 5.6 to 8.0 is not isolated to a few call stacks. MySQL 8.0 uses ~1.5X more instructions/operation than 5.6. Cache activity (references, loads, misses are frequently up 1.5X or more. TLB activity (loads, misses) is frequently up 2X to 5X with the iTLB being a bigger problem than the dTLB. innodb_log_writer_threads=ON is worse than I thought. I will soon have a post on that. Too long to be a tl;dr I don't have much experience using Linux perf counters to explain performance changes. There are huge increases for data TLB, instruction TLB and L1 cache counters. From the Xeon CPU (socket2 below) the change from MySQL 5.6.21 to 8.0.34 me