<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Analyzing the distribution of InnoDB log file writes</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/</link>
	<description>Percona&#039;s MySQL &#38; InnoDB performance and scalability blog</description>
	<lastBuildDate>Sat, 11 Feb 2012 16:45:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: tom_fans</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/comment-page-1/#comment-771784</link>
		<dc:creator>tom_fans</dc:creator>
		<pubDate>Thu, 19 Aug 2010 02:31:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3361#comment-771784</guid>
		<description>truth be told, i intend to translate your article at first, but it&#039;s difficult for me to read your english article. so give up now !</description>
		<content:encoded><![CDATA[<p>truth be told, i intend to translate your article at first, but it&#8217;s difficult for me to read your english article. so give up now !</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/comment-page-1/#comment-769625</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Mon, 19 Jul 2010 13:01:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3361#comment-769625</guid>
		<description>Rob, I think you are right.  I have never liked that it&#039;s not really possible to control the logs and data files independently.  The legacy configuration options for innodb_flush_method are a hodgepodge of things that don&#039;t give enough choices; some of the combinations make me scratch my head and wonder why anyone would ever want that.</description>
		<content:encoded><![CDATA[<p>Rob, I think you are right.  I have never liked that it&#8217;s not really possible to control the logs and data files independently.  The legacy configuration options for innodb_flush_method are a hodgepodge of things that don&#8217;t give enough choices; some of the combinations make me scratch my head and wonder why anyone would ever want that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/comment-page-1/#comment-769624</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Mon, 19 Jul 2010 12:59:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3361#comment-769624</guid>
		<description>Pierre, there was no benchmark, this was on a live system.  The results from iostat would be meaningless, as the IO to the log files is mixed with the IO to the data files.  It is possible that writes in mode 2 would be merged, but the small writes will still result in read-around writes, in theory.  In mode 1, merges should not only be unlikely, but guaranteed not to happen, unless there are multiple calls to pwrite() before an fsync().  I have not investigated whether this is the case.  All of these points are rather more difficult to measure than the data I did measure, and would require more research.  Aggregated statistics such as those provided by the kernel are hard to use.</description>
		<content:encoded><![CDATA[<p>Pierre, there was no benchmark, this was on a live system.  The results from iostat would be meaningless, as the IO to the log files is mixed with the IO to the data files.  It is possible that writes in mode 2 would be merged, but the small writes will still result in read-around writes, in theory.  In mode 1, merges should not only be unlikely, but guaranteed not to happen, unless there are multiple calls to pwrite() before an fsync().  I have not investigated whether this is the case.  All of these points are rather more difficult to measure than the data I did measure, and would require more research.  Aggregated statistics such as those provided by the kernel are hard to use.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pierre Beck</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/comment-page-1/#comment-769509</link>
		<dc:creator>Pierre Beck</dc:creator>
		<pubDate>Sat, 17 Jul 2010 10:54:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3361#comment-769509</guid>
		<description>Given the sequential nature of logs, most of the writes should be merged by the kernel. Possibly many merges in both innodb_flush_log_at_trx_commit mode 0 and 2. In mode 1, merges are very unlikely. Could you add merge counts to the benchmark? e.g. iostat -x -d 30, let it run for 30 secs, watch column wrqm/s.</description>
		<content:encoded><![CDATA[<p>Given the sequential nature of logs, most of the writes should be merged by the kernel. Possibly many merges in both innodb_flush_log_at_trx_commit mode 0 and 2. In mode 1, merges are very unlikely. Could you add merge counts to the benchmark? e.g. iostat -x -d 30, let it run for 30 secs, watch column wrqm/s.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Wultsch</title>
		<link>http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/comment-page-1/#comment-769499</link>
		<dc:creator>Rob Wultsch</dc:creator>
		<pubDate>Sat, 17 Jul 2010 07:26:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=3361#comment-769499</guid>
		<description>IIRC the current facebook patch set includes the ability to set innodb log writes to O_DIRECT.  It seem like the flushing behavior of log writes should follow the behavior set by innodb_flush_method.</description>
		<content:encoded><![CDATA[<p>IIRC the current facebook patch set includes the ability to set innodb log writes to O_DIRECT.  It seem like the flushing behavior of log writes should follow the behavior set by innodb_flush_method.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

