AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
The variance is somewhat improved by picking the best result out of three test runs, but it is still not satisfactory. The reason for the long warm-up period is that, from experience, when InnoDB's Adaptive Hash Index is on, you will need 8 runs or so before execution times are stable.Īs I wrote above, the variance within each test run is very small, but the difference between test runs can be large. The result for each query will be the average execution times of the last 10 runs. (4 GB buffer pool for scale factor 1 and 32 GB buffer pool for scale factor 10.) The computer has 128 GB of RAM, and the InnoDB buffer pool is big enough to contain the entire database. I always bind the MySQL server to a single CPU, using taskset or numactl, and Turbo Boost is disabled. The CPUs are Intel Xeon E5-2690 (Sandy Bridge) with 8 physical cores 2.90GHz. All tests are run on a 2-socket box running Oracle Linux 7. At the end, I will also list the things I have tried that did not show any positive effects.įirst, I will describe the setup for the tests I run. I have tried a lot of stuff to get more stable runs, and in this blog post I will write about the things that I have found to have positive effects on stability. With such large variation in results, significant performance regressions may not be noticed. As an example, I got a coefficient of variation (CoV) of 0.1% for 10 repeated executions of a query on the same server, while the CoV for the average runtime of 10 such experiments was over 6%! While repeated runs of a query is very stable, I can get quite different results if I restart the server. However, I have had issues with getting stable results. I have for some years been running the queries of the DBT-3 benchmark, both to verify the effect of new query optimization features, and to detect any performance regressions that may have been introduced.
0 Comments
Read More
Leave a Reply. |