<?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"
	>
<channel>
	<title>Comments on: How much overhead DRDB could cause ?</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2008/06/02/how-much-overhead-drdb-could-cause/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2008/06/02/how-much-overhead-drdb-could-cause/</link>
	<description>Everything about MySQL Performance</description>
	<pubDate>Tue, 02 Dec 2008 18:20:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2008/06/02/how-much-overhead-drdb-could-cause/#comment-308205</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Tue, 03 Jun 2008 15:20:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=409#comment-308205</guid>
		<description>Thanks Florian,

Indeed I write about latency - because this is where the problem frequently would be with MySQL running on DRBD. 
Good to see we're close to the agreement on this :)

Regarding - you would not notice unless application is write intensive - sure.  It is worth to highlight again DRBD overhead comes from Writes only.  Reads are served from local drive and have little overhead.</description>
		<content:encoded><![CDATA[<p>Thanks Florian,</p>
<p>Indeed I write about latency - because this is where the problem frequently would be with MySQL running on DRBD.<br />
Good to see we&#8217;re close to the agreement on this <img src='http://www.mysqlperformanceblog.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Regarding - you would not notice unless application is write intensive - sure.  It is worth to highlight again DRBD overhead comes from Writes only.  Reads are served from local drive and have little overhead.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Florian Haas</title>
		<link>http://www.mysqlperformanceblog.com/2008/06/02/how-much-overhead-drdb-could-cause/#comment-308083</link>
		<dc:creator>Florian Haas</dc:creator>
		<pubDate>Tue, 03 Jun 2008 11:45:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=409#comment-308083</guid>
		<description>Peter,

it is, as always, important to point out that "performance" in I/O is a combination of two distinct things that may affect applications in very different ways: throughput and latency. Your post talks mostly about latency, so that's what I am going to tackle here.

Consider a local disk with about 3ms latency for a small (one sector, 512 bytes) write request. Consider further that with Gigabit Ethernet, we get about .1 to .3ms network latency. DRBD's latency penalty amounts to roughly twice the network latency, so that would be .2 to .6ms or about 7 to 20% latency overhead.

Now when you introduce a RAID controller with battery-backed write cache to the setup (and you should), your local I/O latency decreases dramatically. Now your local writes "complete" in something like .1 to .3ms. So in relation, all of a sudden DRBD's latency penalty "jumps up" (in percentage, not in absolute terms) to perhaps 100% or 300%. And there's little you can do about this, because it's almost impossible to tune the Gigabit Ethernet-based TCP/IP stack to deliver packets significantly faster.

It should be noted that unless your application is highly write intensive, you'll probably not notice much of this. However, for extremely high write loads, DRBD currently does add comparatively large performance penalties percentage-wise. Which is subject to change when we move off Ethernet-based IP as our sole network protocol. Some of the low-latency network technologies you mention are already being worked on -- stay tuned on the drbd-user mailing list for announcements.

And just in case other readers here are interested in learning more about DRBD performance tuning considerations, I encourage you to watch my blog (http://blogs.linbit.com/florian) for a free DRBD performance tuning webinar we will be announcing shortly.

Cheers,
Florian</description>
		<content:encoded><![CDATA[<p>Peter,</p>
<p>it is, as always, important to point out that &#8220;performance&#8221; in I/O is a combination of two distinct things that may affect applications in very different ways: throughput and latency. Your post talks mostly about latency, so that&#8217;s what I am going to tackle here.</p>
<p>Consider a local disk with about 3ms latency for a small (one sector, 512 bytes) write request. Consider further that with Gigabit Ethernet, we get about .1 to .3ms network latency. DRBD&#8217;s latency penalty amounts to roughly twice the network latency, so that would be .2 to .6ms or about 7 to 20% latency overhead.</p>
<p>Now when you introduce a RAID controller with battery-backed write cache to the setup (and you should), your local I/O latency decreases dramatically. Now your local writes &#8220;complete&#8221; in something like .1 to .3ms. So in relation, all of a sudden DRBD&#8217;s latency penalty &#8220;jumps up&#8221; (in percentage, not in absolute terms) to perhaps 100% or 300%. And there&#8217;s little you can do about this, because it&#8217;s almost impossible to tune the Gigabit Ethernet-based TCP/IP stack to deliver packets significantly faster.</p>
<p>It should be noted that unless your application is highly write intensive, you&#8217;ll probably not notice much of this. However, for extremely high write loads, DRBD currently does add comparatively large performance penalties percentage-wise. Which is subject to change when we move off Ethernet-based IP as our sole network protocol. Some of the low-latency network technologies you mention are already being worked on &#8212; stay tuned on the drbd-user mailing list for announcements.</p>
<p>And just in case other readers here are interested in learning more about DRBD performance tuning considerations, I encourage you to watch my blog (http://blogs.linbit.com/florian) for a free DRBD performance tuning webinar we will be announcing shortly.</p>
<p>Cheers,<br />
Florian</p>
]]></content:encoded>
	</item>
</channel>
</rss>
