mdcallag

But the thing that doesn't get much discussion in public is the drama that happens from upgrades when behavior changes WRT file systems, kernels, device drivers, CPU frequency governors, etc.

It took a few weeks to figure that out for several of my servers. So I am slow to upgrade things once that gets stable -- and it has been stable for my servers for about 6 months.

Yeah, I missed that. I have ~10 servers in my test pool, all are still on 22.04. Perhaps I upgrade them later this year.

Author here. The interesting point was that RSS is much too large with glibc malloc + RocksDB/MyRocks. The performance differences aren't a big deal, but OOM because RSS is 2X or 3X larger than it should be is a big deal. Of course, that problem is workload specific, but RocksDB/MyRocks are a workload on which I focus.

I lurk on email lists for RocksDB and OOM from glibc malloc is a problem for users -- the solution is easy, use jemalloc or tcmalloc.

Blog author here.

I use the latest LTS release of Ubuntu, which is Ubuntu 22.04, and the library versions are what Ubuntu provides. So these are the libraries that most of us use when using Ubuntu LTS. Regardless, I am happy that tcmalloc and jemalloc continue to improve.

Occasionally I get "your version of X is too old" when I publish results for X, and I have had mixed results in the past when doing even more work to test the newer thing. In this case I am not going to put in that extra time. But in a few years I might revisit the topic and get newer versions of X, of course, there will be feedback that the version of X I test in 2028 is from 2026 and the story repeats.

Thanks for doing the sensitivity analysis. I struggle with that issue a lot -- how can I shorten my benchmark duration (use less data, run for less time) so I can get more work done.

README.md was interesting to read. I enjoyed learning about the history of the effort and I appreciate how much work got it to this point.

I enjoy both benchmarking and benchmarketing. Although benchmarketing is more fun when it isn't about the DBMS I am working on.

You did an awesome job on the 5.0 to 5.1 migration, especially in chasing down at least one obscure problem in InnoDB.

How many nines will managed RonDB provide when running in public clouds?

This post inpsired a lot of great discussion about the Spanner family of distributed databases. Someone asked about TiDB there, but there was no follow up. Can someone answer that question?

http://dbmsmusings.blogspot.com/2018/09/newsql-database-syst...

There are many options but most don't have to be set. We need to improve the tuning experience. See http://smalldatum.blogspot.com/2018/09/5-things-to-set-when-...

MyRocks isn't 5.6 only. It is in Percona 5.7 and MariaDB 10.3

I agree that tuning is too complex and we should do much better there. This explains where to ask for advice - http://smalldatum.blogspot.com/2018/05/where-to-ask-question...

jemalloc and tcmalloc have been much better than glibc for me, especially when it comes to avoiding fragmentation with some server workloads http://smalldatum.blogspot.com/2017/11/concurrent-large-allo... http://smalldatum.blogspot.com/2018/04/myrocks-malloc-and-fr... http://smalldatum.blogspot.com/2015/10/myrocks-versus-alloca...

Release looks great. I can't wait for MyRocks to arrive to make it even better.

Has anyone run similar tests for MariaDB? That is my blog, but I have been too busy with upstream MySQL to test MariaDB.

Regression is expected with new features. Oracle has been a great owner for MySQL. I think we, including Oracle, can make progress on this problem.

Yes, context is everything when looking at benchmark results. I am showing the worst-case for this performance regression. Thanks for mentioning that. Note, that is my blog.

I also showed the impact for IO-bound workloads, and even there the regression is larger than I want. But not as bad as the in-memory workloads.

Blog author here. I think that Oracle has been the best corporate owner for MySQL, much better than Sun and standalone MySQL.

I write these posts to document & market the problem and motivate upstream and my team to make things better. I don't think they are ruining MySQL.

MySQL has done great since Oracle acquired Sun -- regular & high-quality releases, new features, tech debt reduction.

What is coming next?

Things that can go wrong with weaker isolation is large and under-appreciated topic. People might be reluctant to share real stories.

Welcome, Bradley and Leif, to the club of people whom Howard has declared are doing it wrong. You are in fine company as I am also a member of that club. Although I do prefer snark from Turing Award winners. I don't think there is reason to pursue a discussion. It won't end well. But I do understand the desire to address the claims once.

https://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate...

Your description of what matters to many customers doesn't get enough appreciation. Its faster too often trumps it lets me sleep at night in the battle for attention.

I am a big fan of their focus on manageability for sharded databases. I am less of a fan of their db internals that might require you to use many more shards than a more performant engine. More details at http://smalldatum.blogspot.com

I love TheReg, but I am not sure I would use them as a primary source.

I guess I am free to hold both opinions. That is my blog. As I write elsewhere on this page I think Oracle has been a good steward of MySQL, but have not been perfect. Maybe they will improve?

I think Oracle has been a good steward. They haven't been perfect but they have done a great job at paying back technical debt and making the product better for modern hardware.

The test suite is still there. I have had questions about the number of new tests that are not getting published -- http://mysqlha.blogspot.com/2013/11/where-are-tests.html