MySQL regressions: skip_concurrency_ticket

I started to look at CPU overheads in MyRocks and upstream InnoDB. While I am happy to file bugs for MyRocks as they are likely to be fixed, I am not sure how much energy I want to put into proper bug reports for upstream InnoDB. So I will just write blog posts about them for now.

I created flamegraphs while running sysbench with cached databases (more likely to be CPU bound) and the problem here occurs on an 8-core PN53 where sysbench was run with 1 thread. Here I use perf record -e cycles to collect data for flamegraphs and then I focus on the percentage of samples in a given function (and its callees) as a proxy for CPU overhead.

The problem here is that during the scan benchymark the skip_concurrency_ticket function accounts for ~3% of CPU in 8.0.37, half that in 5.7.44 and the function doesn't exist in 5.6.51. It is called from innobase_srv_conc_enter_innodb which was a bit simpler in 5.6.

The flamegraphs (*.svg files) are here.

Also visible in those flamegraphs, the percentage of samples (CPU overhead prox) accounted for by row_sel_store_mysql_rec and callees
  • 27.20% in 5.6.51
  • 25.46% in 5.7.44
  • 31.17% in 8.0.28
  • 34.99% in 8.0.37

Comments

  1. AnonymousAugust 8, 2024 at 4:18 AM

    Can you do perf annotate row_prebuilt_t::skip_concurrency_ticket, please?
    This function seems to do just `mov`s and `test`s and `cmp*`s - which looks like one would expect from reading the C++ code which is just a bunch of ifs on various fields. Perhaps the problem is that they are difficult to predict?
    Maybe it would help to reorder the ifs and so that we get to the answer quicker?
    Can you try sampling based on mispredictions (`perf record -e branch-misses..`)?
    Alternatively, maybe the problem is with fetching one of these values from ram somehow? Can you try sampling based on cache misses (`perf record -e cache-misses...`)?

    ReplyDelete
  2. AnonymousAugust 8, 2024 at 4:22 AM

    (posting again as I can't see my previous post)
    Can you please do `perf annotate row_prebuilt_t::skip_concurrency_ticket?
    This function compiles to assembly which looks just like one would expect from C++ code: a bunch of `mov`s and `cmp*`/`test`s.
    So, perhaps the problem is with branch prediction or cache misses.
    You can try sampling with:
    perf report -e branch-misses ...
    perf report -e cache-misses ...
    One thing to try is to change the order of ifs so that we get to the most probable return quicker.

    ReplyDelete
    Replies
    1. Mark CallaghanAugust 8, 2024 at 7:59 AM

      Comments don't show up until I approve them because I don't want spam here, and I get more than I expect.

      I assume that stalls from cache and TLB are a big part of the problem. I am repeating tests to collect flame graphs for all of the supported HW counters. Alas, that will take time to finish.

      cache-references \
      cache-misses \
      branches \
      branch-misses \
      L1-dcache-loads \
      L1-dcache-load-misses \
      L1-icache-loads-misses \
      dTLB-loads \
      dTLB_load-misses \
      iTLB-load-misses \
      iTLB-loads \
      instructions \

      Delete
    2. Mark CallaghanAugust 8, 2024 at 8:03 AM

      I don't have the files needed to run "perf annotate". My helper scripts remove files after creating flamegraphs to save on disk space. Even with the removals it takes ~500M per experiment (experiment == run benchmark for one DBMS).

      I will keep this in mind (trying "perf annotate") for later.

      Delete

Post a Comment

Popular posts from this blog

Fixing bug 109595 makes MySQL almost 4X faster on the Insert Benchmark

Image
MySQL 8.0.35 includes a fix for bug 109595  and with that fix the QPS is almost 4X larger on the read+write benchmark steps compared to MySQL 8.0.34. Thank you to MySQL for fixing this quickly. I reported the bug in January of 2023. I have been aware of the performance problem for years, but didn't spend time debugging it until this year. I assume this problem was limited to InnoDB because I did not see problems with MyRocks. The chart below shows relative QPS which is (QPS for MySQL 8.0.35) / (QPS for MySQL 8.0.34). When the value is larger than 1.0 then MySQL 8.0.35 is faster than 8.0.34. And below the relative QPS is almost 4.0 on the read+write benchmark steps: q100, q500, q1000. The Insert Benchmark is explained here .
Read more

Postgres versions 11, 12, 13, 14, 15, and 16 vs sysbench with a medium server

Image
This provides additional results for Postgres versions 11 through 16 vs Sysbench on a medium server. My previous post is here . The goal is to document how performance changes over time with a focus on CPU overheads. tl;dr Postgres avoids performance regressions from old to new versions. This is excellent. Postgres 16.0 is mostly faster than 11.21 on read-only benchmark steps Postgres 16.0 and 11.21 have similar throughput on read-write and write-only benchmark steps Builds I compiled Postgres 11.21, 12.16, 13.12, 14.9, 15.2, 15.3, 15.4 and 16.0. The builds are named  o3_native_lto  which is shorthand for using: -O3 -march=native -mtune=native -flto. Benchmark I used sysbench and my usage is  explained here . Postgres was configured to cache all tables. This benchmark used a c2-standard-30 server from GCP with 15 cores, hyperthreads disabled, 120G of RAM, Ubuntu 22.04 and 1.5TB of NVMe SSD with XFS (SW RAID 0 over 4 local devices). The benchmark is run with 8 clients and 4 table with 2
Read more

Postgres vs MySQL: the impact of CPU overhead on performance

Image
This post documents how MySQL and Postgres performance has changed over time using sysbench. It compares QPS for Postgres 11.21 vs MySQL 5.6.21 and then Postgres 16.0 vs MySQL 8.0.34. The focus here is on CPU overhead and for that a workload that is low-concurrency, CPU-bound and cached is sufficient. However a full comparison would also include results for workloads with more concurrency and workloads that are IO-bound. The benchmark was explained in a series of posts - see  part 1 ,  part 2 ,  part 3 ,  part 4  and part 5  and the results here are from my small server. Usually I avoid direct comparisons between Postgres and MySQL but I am doing this because I care about the future of MySQL and the CPU regressions in it over time have become a problem. tl;dr Postgres 11.21 and MySQL 5.6.21 have similar QPS on most sysbench tests Postgres 16.0 gets much more QPS than MySQL 8.0.34 on most sysbench tests The problem for MySQL is new CPU overhead Results The spreadsheet with all of the nu
Read more