Comments on: Impact of logging on MySQL’s performance http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Rick James http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-796728 Rick James Tue, 01 Feb 2011 19:26:14 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-796728 The whole question is a non-issue. Turn on the slowlog, and leave it on. Why do I say that? * If the system is performing well, then, by definition, the slowlog is not hurting. * If the system is performing poorly, then you need to look back at what was causing the most pain and fix it. And the slowlog is the best way to do that. We have hundreds of systems (thousands of servers in replication setups) in production. The default is to have the slowlog on, and to set long_query_time = 2. (Some systems use higher or lower values.) When there is a meltdown, the slowlog is sometimes the best source of 'why'. The rest of the time, I find it useful to proactively look for naughty queries and propose tuning / index / schema / design changes. Anyway, thanks for confirming that the overhead is "in the noise". (I assume you are talking only about the slowlog, not the binlog, nor the general log.) The whole question is a non-issue. Turn on the slowlog, and leave it on. Why do I say that?
* If the system is performing well, then, by definition, the slowlog is not hurting.
* If the system is performing poorly, then you need to look back at what was causing the most pain and fix it. And the slowlog is the best way to do that.

We have hundreds of systems (thousands of servers in replication setups) in production. The default is to have the slowlog on, and to set long_query_time = 2. (Some systems use higher or lower values.)

When there is a meltdown, the slowlog is sometimes the best source of ‘why’. The rest of the time, I find it useful to proactively look for naughty queries and propose tuning / index / schema / design changes.

Anyway, thanks for confirming that the overhead is “in the noise”. (I assume you are talking only about the slowlog, not the binlog, nor the general log.)

]]> By: peter http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-472617 peter Thu, 12 Feb 2009 00:36:10 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-472617 Robert, Dtrace is cool. The thing is though very little of our customers runs Solaris. I worked w Sun on Dtrace support for MySQL during my time there. Robert,

Dtrace is cool. The thing is though very little of our customers runs Solaris. I worked w Sun on Dtrace support for MySQL during my time there.

]]> By: Robert Treat http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-472391 Robert Treat Wed, 11 Feb 2009 20:34:27 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-472391 This whole topic is one of the reason's we've always been so excited about dtrace. I wonder, perhaps you guys should query the mysql developers to get a copy of their dtrace probes patch for 6.0, and put it into OurDelta now. Probes are pretty non-intrusive; we've done them for both Apache and Postgres on our own (though we worked with Sun to get the Postgres ones into core for Postgres 8.4). http://labs.omniti.com/trac/project-dtrace/wiki http://lethargy.org/~jesus/index.php?serendipity%5Baction%5D=search&serendipity%5BsearchTerm%5D=dtrace&serendipity%5BsearchButton%5D=%3E This whole topic is one of the reason’s we’ve always been so excited about dtrace. I wonder, perhaps you guys should query the mysql developers to get a copy of their dtrace probes patch for 6.0, and put it into OurDelta now. Probes are pretty non-intrusive; we’ve done them for both Apache and Postgres on our own (though we worked with Sun to get the Postgres ones into core for Postgres 8.4).

http://labs.omniti.com/trac/project-dtrace/wiki
http://lethargy.org/~jesus/index.php?serendipity%5Baction%5D=search&serendipity%5BsearchTerm%5D=dtrace&serendipity%5BsearchButton%5D=%3E

]]> By: Vladimir Rusinov http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-472058 Vladimir Rusinov Wed, 11 Feb 2009 14:48:54 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-472058 What about logging queries like INSERT INTO binary_table VALUES (123, '%LARGE_BINARY_BLOB%')? I've found some time ago that for PostgreSQL logging such queries takes more time (and uses a lot of CPU) than this insert executes. What about logging queries like INSERT INTO binary_table VALUES (123, ‘%LARGE_BINARY_BLOB%’)?

I’ve found some time ago that for PostgreSQL logging such queries takes more time (and uses a lot of CPU) than this insert executes.

]]> By: peter http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-471462 peter Wed, 11 Feb 2009 05:46:51 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-471462 Interesting your point to Cary Millsap blog. I think his Book on Oracle Performance Optimization is one of the best books on performance tuning. It surely taught me a lot when... And a lot of principles are general being it Oracle or MySQL just tools (or lack of tools) is different. Interesting your point to Cary Millsap blog.

I think his Book on Oracle Performance Optimization is one of the best books on performance tuning. It surely taught me a lot when… And a lot of principles are general being it Oracle or MySQL just tools (or lack of tools) is different.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-471042 Baron Schwartz Wed, 11 Feb 2009 00:02:01 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-471042 Arjen, Exactly -- and as has been pointed out over and over, the minute you propose to people the means to figure out where their performance problems are, the first thing they do is anxiously ask "how much overhead does it have." Look at the PostgreSQL blogging world's take on this last week: http://carymillsap.blogspot.com/2009/02/on-usefulness-of-software.html http://prodlife.wordpress.com/2009/02/04/psychology-of-instrumentation/ http://tkyte.blogspot.com/2005/06/instrumentation.html I think this benchmark shows that a) in cases where you're I/O bound, which is <a href="http://www.markleith.co.uk/?p=22" rel="nofollow">exactly the time when people worry about the impact of logging</a>, it isn't measurable, and b) it's not that much overhead anyway. Arjen,

Exactly — and as has been pointed out over and over, the minute you propose to people the means to figure out where their performance problems are, the first thing they do is anxiously ask “how much overhead does it have.” Look at the PostgreSQL blogging world’s take on this last week:

http://carymillsap.blogspot.com/2009/02/on-usefulness-of-software.html
http://prodlife.wordpress.com/2009/02/04/psychology-of-instrumentation/
http://tkyte.blogspot.com/2005/06/instrumentation.html

I think this benchmark shows that a) in cases where you’re I/O bound, which is exactly the time when people worry about the impact of logging, it isn’t measurable, and b) it’s not that much overhead anyway.

]]> By: Arjen Lentz http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%e2%80%99s-performance/comment-page-1/#comment-471011 Arjen Lentz Tue, 10 Feb 2009 23:32:50 +0000 http://www.mysqlperformanceblog.com/?p=612#comment-471011 So nothing new really, but good to have the numbers. Thanks! So nothing new really, but good to have the numbers. Thanks!

]]>