You may probably look the whole config variables with ’show global variables’.

1) we want to see mistakes in my.cnf, rather than have them hidden by my_print_defaults. A duplicate entry is pretty common and should be fixed.

2) it’s true that there may be several .cnf files that mysqld reads from, so a single one isn’t the whole truth. But it’s also the case that variables can be set online, so the only source of truth is SHOW VARIABLES.

The other thing I didn’t mention is that some of the tools we use will do .cnf file analysis to look for duplicate/conflicting values, and values that are different inside mysql than they are in the config files.

“The stock MySQL server’s limitation of one-second granularity makes it hide problem queries that are faster than one second (which in a high-performance system is virtually every query.)”

Actually, it’s worse than that. The slow query log logs queries that take >long_query_time. Not >=long_query_time. So actually you don’t get any logging for queries that are faster than 2 seconds. (If you have data to counteract this, let me know, but I haven’t seen any…)

Michael,

The point is when *tuning*, you let the client know exactly what’s happening. If the client thinks you’re fixing something when what you’re doing is buying time, you need to explain to them that you’re buying time — not fixing a problem.

It’s certainly a common problem, as often there are tons of change management procedures regarding the code (and tests and qa to pass) and not so many regarding changing a my.cnf parameter.

For the toughest clients, use a test database, fill with sample data, make your changes (code and perhaps schema as well) and show them the difference.

You can always make an analogy, as Peter did — though you can explain that if you have lots of memory, fast cpu and lots of fast disk, and have to process 500 records, it’s faster to only have to process 50 records than 500, no matter how good your stuff is.

Knowing how Percona identified the problems in my specific system was absolutely invaluable, and saved me more time than I can imagine. Thanks guys.

There is example (quite simplified):

if application is running SELECT COUNT(*) from InnoDB_table to scan 100.000.000 rows, there is no good way to optimize it if you do not want to change application.

Our problem seems to be that we’ve done all the tuning (perhaps even provided a bandaid as such), and so no application changes are made, the only “breathing room” came from the tuning. Then, the wall of scability is hit again, loads go up, queries lag, and the question comes up “Why can’t you do what you did before?”. Obviously it’s because it’s been done before.

When the client has the fastest (excepting ssd and dedicated appliances) hardware you can buy, an already tuned infrastructure (my.cnf, hardware, kernel patches, the works), and still doesn’t “want” to change the application or doesn’t believe it’s the problem, that’s where I start to pull out my hair.

Michael

Sure we can re-write queries, re-structure the schema and all this kind of stuff. Our goal is to give the client a “menu” so they can pick what they want because business reasoning can be outside of our immediate reach. For example we may say something like we tuned your MySQL settings this should get your capacity up another 20%. You can double capacity by by adding the proper indexes and get another 50% by upgrading to faster system. But if you need more gains you need to restructuring and schema or architecture changes.

It is more complicated than that really but it gives some good insight.

You’ve completed your analysis, handed it to the client, and they were expecting that you’d provide a panacea at the server-level, solving all their “code problems”? We regularly have clients that feel that they shouldn’t need to change their application. What do you do at that point? Do you actually re-write the queries for them in your service? It was difficult to convince them to implement caching (which saved massive load on the database servers, even if some changes are still needed). Some areas need to be re-worked completely.

Michael