<?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: Choosing innodb_buffer_pool_size</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/</link>
	<description>Everything about MySQL Performance</description>
	<lastBuildDate>Wed, 10 Mar 2010 01:20:14 +0000</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Robert</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-713797</link>
		<dc:creator>Robert</dc:creator>
		<pubDate>Sun, 24 Jan 2010 17:35:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-713797</guid>
		<description>I&#039;m asking your tip to prevent another issue like the one happen to our friend.

Please note that I landed into your interesting blog because the intel mainboard of a friend &quot;died&quot; in the middle of a working day.

For an unknown reason... the crash recovery takes to nothing. Disks were raid 5 and we did a raid data recovery for him. Quite everything copied fine expecially the mysql directory...
Cool (I thought) now with a working mysql installation + the exact logs file size + all the db folders and a simple &quot;mysqld --innodb_log_file_size=xxxxxxxxx --innodb_force_recovery=6&quot; (where xxxxxxxxx is the phisical size in bytes of the logs) I can dump tables and restart them really soon... It is not like that..
Bad story... their db operations were started in jan 2007, the server died on 20 january the 2010 but dumps are extracting only up to september 2009... then mysqld crashes. I suppose there is something bad inside the ibdata file. Because it is only 50MB I copied it and gave it a look with notepad++. I see the missing records... but there is no way (at least with our knowledge) to dump them.
To be true looks like that they are &quot;in a strange position&quot; into the ibdata file compared with those that dumps before the crash.

And this is the reason because I worry about the memory and innodb files and memory setup: ib_logfiles on their and also on our server are 10MB while ibdata is 50MB, users are 6 and server was win 2003 server with 2GB RAM (xeon and a raid 5 system). Can this be the reason for a failed crash recovery?

Our server is similar.

Thank you for any tip and or answer... and also any help if you have any suggestion for the case above.

Robert</description>
		<content:encoded><![CDATA[<p>I&#8217;m asking your tip to prevent another issue like the one happen to our friend.</p>
<p>Please note that I landed into your interesting blog because the intel mainboard of a friend &#8220;died&#8221; in the middle of a working day.</p>
<p>For an unknown reason&#8230; the crash recovery takes to nothing. Disks were raid 5 and we did a raid data recovery for him. Quite everything copied fine expecially the mysql directory&#8230;<br />
Cool (I thought) now with a working mysql installation + the exact logs file size + all the db folders and a simple &#8220;mysqld &#8211;innodb_log_file_size=xxxxxxxxx &#8211;innodb_force_recovery=6&#8243; (where xxxxxxxxx is the phisical size in bytes of the logs) I can dump tables and restart them really soon&#8230; It is not like that..<br />
Bad story&#8230; their db operations were started in jan 2007, the server died on 20 january the 2010 but dumps are extracting only up to september 2009&#8230; then mysqld crashes. I suppose there is something bad inside the ibdata file. Because it is only 50MB I copied it and gave it a look with notepad++. I see the missing records&#8230; but there is no way (at least with our knowledge) to dump them.<br />
To be true looks like that they are &#8220;in a strange position&#8221; into the ibdata file compared with those that dumps before the crash.</p>
<p>And this is the reason because I worry about the memory and innodb files and memory setup: ib_logfiles on their and also on our server are 10MB while ibdata is 50MB, users are 6 and server was win 2003 server with 2GB RAM (xeon and a raid 5 system). Can this be the reason for a failed crash recovery?</p>
<p>Our server is similar.</p>
<p>Thank you for any tip and or answer&#8230; and also any help if you have any suggestion for the case above.</p>
<p>Robert</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-713795</link>
		<dc:creator>Robert</dc:creator>
		<pubDate>Sun, 24 Jan 2010 17:22:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-713795</guid>
		<description>What about the windows environment? You said it is not critical because &quot;On Windows you do not need to do anything&quot;. Just a one kind suggestion that would be good also for commenters above SQL Dan and Cristian.
Obviously you are with your mind set on super-mega-enterprise structures 2000 users per minute and I understand you, but what about a small MySQL InnoDB database with just 20 tables and ibdata1 size (now) 70MB and a little office with less than 15 users?

Can you kindly suggest us a safe memory amount and innodb setup for that memory?

Really thank you if you have the time to tip us on a good setup for our &quot;small&quot; environments

Robert</description>
		<content:encoded><![CDATA[<p>What about the windows environment? You said it is not critical because &#8220;On Windows you do not need to do anything&#8221;. Just a one kind suggestion that would be good also for commenters above SQL Dan and Cristian.<br />
Obviously you are with your mind set on super-mega-enterprise structures 2000 users per minute and I understand you, but what about a small MySQL InnoDB database with just 20 tables and ibdata1 size (now) 70MB and a little office with less than 15 users?</p>
<p>Can you kindly suggest us a safe memory amount and innodb setup for that memory?</p>
<p>Really thank you if you have the time to tip us on a good setup for our &#8220;small&#8221; environments</p>
<p>Robert</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Detecting and Resolving LAMP Stack Problems &#8211; Scheduled Downtime &#187; Karl Katzke &#124; PHP, Puppies, and other Geekery</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-665142</link>
		<dc:creator>Detecting and Resolving LAMP Stack Problems &#8211; Scheduled Downtime &#187; Karl Katzke &#124; PHP, Puppies, and other Geekery</dc:creator>
		<pubDate>Thu, 15 Oct 2009 04:51:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-665142</guid>
		<description>[...] time, especially when some of your tables are larger than 1gb.) Don&#8217;t forget to switch to set innodb_buffer_pool_size [...]</description>
		<content:encoded><![CDATA[<p>[...] time, especially when some of your tables are larger than 1gb.) Don&#8217;t forget to switch to set innodb_buffer_pool_size [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tuning a Linux system for Database Server &#124; Random Bugs</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-614270</link>
		<dc:creator>Tuning a Linux system for Database Server &#124; Random Bugs</dc:creator>
		<pubDate>Thu, 16 Jul 2009 17:31:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-614270</guid>
		<description>[...] more info read: http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/ [...]</description>
		<content:encoded><![CDATA[<p>[...] more info read: <a href="http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/" rel="nofollow">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SQL Dan</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-584759</link>
		<dc:creator>SQL Dan</dc:creator>
		<pubDate>Sun, 14 Jun 2009 04:35:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-584759</guid>
		<description>Is the INNODB_BUFFER_POOL shared across all databases or allocated per database? I&#039;m getting ready to run a mysql server in a VMWare environment with a not very busy database. Maybe 10 concurrent users max. With about 5000 records being added per year max per database. I was thinking about running the virtual OS with 2GB of RAM.</description>
		<content:encoded><![CDATA[<p>Is the INNODB_BUFFER_POOL shared across all databases or allocated per database? I&#8217;m getting ready to run a mysql server in a VMWare environment with a not very busy database. Maybe 10 concurrent users max. With about 5000 records being added per year max per database. I was thinking about running the virtual OS with 2GB of RAM.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: [译]Innodb 性能优化基础 &#124; 白天’s Blog</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-543708</link>
		<dc:creator>[译]Innodb 性能优化基础 &#124; 白天’s Blog</dc:creator>
		<pubDate>Sun, 19 Apr 2009 14:51:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-543708</guid>
		<description>[...] UPDATE 关于它具体的查看http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/ innodb_log_file_size [...]</description>
		<content:encoded><![CDATA[<p>[...] UPDATE 关于它具体的查看http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/ innodb_log_file_size [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ［翻译］［注解］Innodb Performance Optimization Basics &#124; 白天’s Blog</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-543707</link>
		<dc:creator>［翻译］［注解］Innodb Performance Optimization Basics &#124; 白天’s Blog</dc:creator>
		<pubDate>Sun, 19 Apr 2009 14:47:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-543707</guid>
		<description>[...] innodb_buffer_pool_size 设为内存的70%-80%都是安全的。我在一个16G的服务器上把它设成12G。 UPDATE： 如果你想了解更多的细节，请查看tuning innodb buffer pool [...]</description>
		<content:encoded><![CDATA[<p>[...] innodb_buffer_pool_size 设为内存的70%-80%都是安全的。我在一个16G的服务器上把它设成12G。 UPDATE： 如果你想了解更多的细节，请查看tuning innodb buffer pool [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-524648</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Mon, 30 Mar 2009 23:14:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-524648</guid>
		<description>I now realize I know absolutely nothing about MySQL. Thanks for all the info (book and blog).</description>
		<content:encoded><![CDATA[<p>I now realize I know absolutely nothing about MySQL. Thanks for all the info (book and blog).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cristian</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-490117</link>
		<dc:creator>Cristian</dc:creator>
		<pubDate>Thu, 26 Feb 2009 10:15:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-490117</guid>
		<description>My server configuration 
2GB /intelquad 

PROBLEM : i start my sql 4.0.12 with innodb_buffer_pool_size = 128 
After starting the server my.cnf becomes my_cnf.bak. 

but randomly the configuration is reseted and all my previous config is set to the default values inlcuding innodb_buffer_pool_size which is set to 5Mb or so 

This happes only since this week. 


Do you know what to do ? 

I am kind of very stressed due to this . 

I can;t migrate now to other version of mysql.</description>
		<content:encoded><![CDATA[<p>My server configuration<br />
2GB /intelquad </p>
<p>PROBLEM : i start my sql 4.0.12 with innodb_buffer_pool_size = 128<br />
After starting the server my.cnf becomes my_cnf.bak. </p>
<p>but randomly the configuration is reseted and all my previous config is set to the default values inlcuding innodb_buffer_pool_size which is set to 5Mb or so </p>
<p>This happes only since this week. </p>
<p>Do you know what to do ? </p>
<p>I am kind of very stressed due to this . </p>
<p>I can;t migrate now to other version of mysql.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/comment-page-1/#comment-445600</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Wed, 14 Jan 2009 19:23:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/#comment-445600</guid>
		<description>I haven&#039;t seen this in the real world, but I don&#039;t disbelieve you.  If you want help solving this, I am pretty confident we can find out what is going on and either find a workaround or discuss the possibility of a patch.  You could also try a bug report via MySQL, but I don&#039;t know how urgent this is for you to solve.</description>
		<content:encoded><![CDATA[<p>I haven&#8217;t seen this in the real world, but I don&#8217;t disbelieve you.  If you want help solving this, I am pretty confident we can find out what is going on and either find a workaround or discuss the possibility of a patch.  You could also try a bug report via MySQL, but I don&#8217;t know how urgent this is for you to solve.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
