<?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: Wasting InnoDB memory</title>
	<atom:link href="http://mituzas.lt/2008/05/29/wasting-innodb-memory/feed/" rel="self" type="application/rss+xml" />
	<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/</link>
	<description>where ideas come and die</description>
	<lastBuildDate>Fri, 26 Feb 2010 17:15:26 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0-alpha</generator>
	<item>
		<title>By: Mark Callaghan</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-154095</link>
		<dc:creator>Mark Callaghan</dc:creator>
		<pubDate>Sat, 31 May 2008 13:58:22 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-154095</guid>
		<description>Domas,

I think the fix is to shrink the size and to not have an os_event_struct per rw-mutex/mutex. This should cut the memory consumption by more than 1/3 without major surgery.</description>
		<content:encoded><![CDATA[<p>Domas,</p>
<p>I think the fix is to shrink the size and to not have an os_event_struct per rw-mutex/mutex. This should cut the memory consumption by more than 1/3 without major surgery.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Sichi</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153746</link>
		<dc:creator>John Sichi</dc:creator>
		<pubDate>Fri, 30 May 2008 20:51:23 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153746</guid>
		<description>I don&#039;t know InnoDB internals, but in general, trying to pool RW locks for buffer pool pages can be problematic.  If access methods are allowed to lock multiple pages simultaneously, then you can introduce spurious deadlocks that way.

For example, you might have access methods which are supposed to lock index pages in tree order (from root to leaf) so as to avoid deadlocks.  Let&#039;s say I&#039;ve got a three-level tree, and the hash for one of the leaves is the same as the hash for the root.  Thread 1 locks the root and then an intermediate page.  Thread 2 locks the same intermediate page and then the leaf.  Oops, deadlock.

If InnoDB doesn&#039;t use the RW locks as medium-duration physical page locks like this (or if it can handle deadlocks at some level), then it&#039;s not an issue.

Short-duration mutexes are easier.

JVS</description>
		<content:encoded><![CDATA[<p>I don&#8217;t know InnoDB internals, but in general, trying to pool RW locks for buffer pool pages can be problematic.  If access methods are allowed to lock multiple pages simultaneously, then you can introduce spurious deadlocks that way.</p>
<p>For example, you might have access methods which are supposed to lock index pages in tree order (from root to leaf) so as to avoid deadlocks.  Let&#8217;s say I&#8217;ve got a three-level tree, and the hash for one of the leaves is the same as the hash for the root.  Thread 1 locks the root and then an intermediate page.  Thread 2 locks the same intermediate page and then the leaf.  Oops, deadlock.</p>
<p>If InnoDB doesn&#8217;t use the RW locks as medium-duration physical page locks like this (or if it can handle deadlocks at some level), then it&#8217;s not an issue.</p>
<p>Short-duration mutexes are easier.</p>
<p>JVS</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Domas Mituzas</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153509</link>
		<dc:creator>Domas Mituzas</dc:creator>
		<pubDate>Fri, 30 May 2008 06:39:13 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153509</guid>
		<description>Mark, I was looking at 64-bit builds, those are the ones that tend to have big buffer pool. But yeah, reducing structure sizes is another way to help here.

Peter, thats what my patch does =)</description>
		<content:encoded><![CDATA[<p>Mark, I was looking at 64-bit builds, those are the ones that tend to have big buffer pool. But yeah, reducing structure sizes is another way to help here.</p>
<p>Peter, thats what my patch does =)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Zaitsev</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153502</link>
		<dc:creator>Peter Zaitsev</dc:creator>
		<pubDate>Fri, 30 May 2008 06:13:28 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153502</guid>
		<description>I think there is also other point - do we really need so MANY mutexes  ?

One mutex is bad - millions is not good either. Why does not Innodb get to have some hashing for the mutexes to keep balance between contention and overhead.</description>
		<content:encoded><![CDATA[<p>I think there is also other point &#8211; do we really need so MANY mutexes  ?</p>
<p>One mutex is bad &#8211; millions is not good either. Why does not Innodb get to have some hashing for the mutexes to keep balance between contention and overhead.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Callaghan</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153421</link>
		<dc:creator>Mark Callaghan</dc:creator>
		<pubDate>Fri, 30 May 2008 01:17:00 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153421</guid>
		<description>My numbers leave out the size of the os_event_struct, which is 132 bytes on my 32-bit build. Each mutex_struct and rw_lock_struct instance will have 1 os_event_struct in the patch.</description>
		<content:encoded><![CDATA[<p>My numbers leave out the size of the os_event_struct, which is 132 bytes on my 32-bit build. Each mutex_struct and rw_lock_struct instance will have 1 os_event_struct in the patch.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Callaghan</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153419</link>
		<dc:creator>Mark Callaghan</dc:creator>
		<pubDate>Fri, 30 May 2008 01:09:31 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153419</guid>
		<description>For a 32 bit build on Linux 2.6, sizeof(mutex_struct) is 104 and sizeof(rw_lock_struct) is 176. With our unreleased patch sizeof(mutex_struct) == 40 and sizeof(rw_lock_struct) = 112. I think that both can be reduced by another 10 bytes.</description>
		<content:encoded><![CDATA[<p>For a 32 bit build on Linux 2.6, sizeof(mutex_struct) is 104 and sizeof(rw_lock_struct) is 176. With our unreleased patch sizeof(mutex_struct) == 40 and sizeof(rw_lock_struct) = 112. I think that both can be reduced by another 10 bytes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Callaghan</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153415</link>
		<dc:creator>Mark Callaghan</dc:creator>
		<pubDate>Fri, 30 May 2008 01:01:17 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153415</guid>
		<description>The structs (mutex_struct, rw_lock_struct and os_event_struct) can be made smaller, especially on 64-bit servers. Look for it in the next patch and keep the good ideas coming.</description>
		<content:encoded><![CDATA[<p>The structs (mutex_struct, rw_lock_struct and os_event_struct) can be made smaller, especially on 64-bit servers. Look for it in the next patch and keep the good ideas coming.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Burton</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153397</link>
		<dc:creator>Kevin Burton</dc:creator>
		<pubDate>Fri, 30 May 2008 00:03:49 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153397</guid>
		<description>InnoDB is very elegant in some respects but totally broken in others.  

Hopefully with more people looking at the code this will be fixed.</description>
		<content:encoded><![CDATA[<p>InnoDB is very elegant in some respects but totally broken in others.  </p>
<p>Hopefully with more people looking at the code this will be fixed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aidas Kasparas</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153120</link>
		<dc:creator>Aidas Kasparas</dc:creator>
		<pubDate>Thu, 29 May 2008 11:06:01 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153120</guid>
		<description>You did not forgot that your employer is a *hardware* company, no? ;-)</description>
		<content:encoded><![CDATA[<p>You did not forgot that your employer is a *hardware* company, no? ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arjen Lentz</title>
		<link>http://mituzas.lt/2008/05/29/wasting-innodb-memory/comment-page-1/#comment-153105</link>
		<dc:creator>Arjen Lentz</dc:creator>
		<pubDate>Thu, 29 May 2008 10:09:25 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=137#comment-153105</guid>
		<description>&quot;enough memory&quot; is not an excuse for bloat, though...</description>
		<content:encoded><![CDATA[<p>&#8220;enough memory&#8221; is not an excuse for bloat, though&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
