One common question I guess is how much should I see performance improved in case I increase memory say from 16GB to 32GB. The benefit indeed can be very application dependent - if you have working set of say 30GB with uniform data access raising memory from 16GB to 32GB can improve performance order of magnitude by converting very IO bound load to CPU bound, it is well possible to see limited gains - if your working set already fits in 16GB you may not see any significant gains upgrading memory to 32GB. Interesting enough similar can happen for very large working set - for example if your main queries do full table scan of 100GB table it does not matter if you have 16GB or 32GB the load is going to be way too much IO bound anyway.

Interesting enough because of MySQL scaling issues it is also possible to see performance to go down as you increase buffer pool size. Some threads which would be safely sleeping waiting on IO completion are now finding their data in buffer pool so they start to compete on hot latches and performance go down.

Now back to original question - how do we predict the benefit from increasing the memory and so cache sizes ? I typically start by looking at the type of load we’re dealing with. If it is CPU bound and there is little IO wait we typically do not expect to gain much by increasing the memory.

This however have to be watched carefully. Performance does not always stays the same and the goal may not be optimizing average performance. It may be heavy data processing batch job which is IO bound and which runs too slow (and affects other transaction) and may be increasing memory is helpful to solve this problem.

If it is IO bound (high IO system utilization, low CPU usage) one should think about how much CPU capacity is available. If your CPU is 25% busy you will unlikely get more than 4x even if you eliminate all IO completely (unlikely because there is increased CPU overhead going IO path as well), so account for that.

Besides pure CPU based computation you should account for locking. Consider for example bunch of transactions updating single row in the table. Having such workload you would likely see no IO and a lot of CPU idle and not because of internal Innodb limits but because your application logical serialization problems.

So what if we have very IO bound application without serialization issues (say reporting slave) which is very IO bound showing 100% IO subsystem utilization on 5% of CPU usage ? This is the true challenge becomes because MySQL has no tools to analyze working set (we have per query working set in our patches but it is not enough). We have couple of ideas how to do global working set profiling but it should wait for now.

At this point I typically use my intuition to try to guess how much data application to get some ballpark figure and often it is enough.

If you would like to be more scientific there are couple of other things you can do. First - you can test by scaling down the data. If you have data for say 500.000 users on the 16GB server get it down to the half of that and you will often be close to seeing performance 32GB server would have. You however have to be careful and understand how data is used in your application. If you say have data for 10 years and load data for 5 years only to compare performance you may get misleading results if reports are typically done for last few months. Basically in such exercise your goal is load data so the working set would be half of original so it would have cache fit similar to one on the larger system you’re trying to compare to. Using this approach you also should be careful with your estimations and take IO subsystem into account - even with same cache hit ratio more data and more load means there are higher demands for IO subsystem performance.

By far the best method is trying, if you can afford it - just get memory upgrade and see how it affects performance. With many vendors you can get the memory upgrade or the whole system to try and return it back if it does not fit your needs. This approach especially works well if you have many slaves (or many shards) in which case you can see performance or capacity improvements quite easily.

Entry posted by peter | No comment

Add to: | | | |

©作者：eygle 发布在 eygle.com

《循序渐进Oracle》一书已经出版，在这里我将和本书相关的信息整理汇总，供大家参考：

1.《循序渐进Oracle》一书的章节信息
内容简介 | 第一章目录 | 第三章目录
第一章连载-之一、之二、之三、之四、之五、之六、之七、之八、之九、之十
第一章PDF完整版下载
2.《循序渐进Oracle》的其他信息
写作规划 | 代码及服务 | 购买途径 | 《循序渐进Oracle》在China-Pub | 作者简介 | 勘误表|
3.《深入浅出Oracle》的相关信息
购买方式 | 代码与服务|勘误表 |

相关文章|Related Articles

• 《循序渐进Oracle》再次重印
  
• 《循序渐进Oracle》一书重印
  
• 《循序渐进Oracle》之后写什么?
  
• 《循序渐进Oracle》一书序言
  
• 《循序渐进Oracle》在当当网上
  

评论数量(56)|Add Comments

本文网址：http://www.eygle.com/archives/2008/08/stepbs_oracle_info.html

运气不好，也就是在穷折腾。

需要rrdtool，就去下源码装，说少了pixman，下源码编译，又说少fontconfig，下载编译不通过，说有个变量或者常量没定义的，实在晕了。

索性yum install rrdtool。

cacti的WEB界面是能看到了，但还不能跑，所有加的设备状态都是未知的，SNMP倒是能取到，但没有图，貌似生成不了。用户权限都应该是正确的。

奥运之前，14个小时的现场值班，奥运保障，保障系统运行稳定。

其实也没啥好干的，应急流程也有的，即便有问题，直接走应急流程就ok了。

2008-08-08好多8呀。还有12个小时左右奥运就要开幕了。无论如何，祝福北京！虽然我觉得中国很多地方不够完善，但是相信会越来越好的。

希望能顺利开幕，也能顺利闭幕。这场奥运大戏，马上就要开锣了，让我们拭目以待！

听说昨天是中国的情人节。嗯，很好，很强大。不希望今天能听到什么新闻，没有新闻就是最好的新闻，更不希望今天白天在家睡觉会收到要走应急流程的电话。

Question: I am trying to install a third-party application on my Red Hat Enterprise Linux system but I am getting failed dependencies error messages. I know that these dependencies are native to Red Hat Enterprise Linux but I do not know which package they belong to. How do I use my up2date agent to resolve these dependencies?

Answer: I am getting similar error messages regarding module dependencies when trying to install a third-party rpm package:

error: failed dependencies:
      libcap.so    is needed by VMware
      libcap.so.1  is needed by VMware
      libcap.so.1.10  is needed by vsftpd

If these module dependencies do exist in any of the packages in Red Hat Enterprise Linux, the following command to automatically resolve these dependencies and install the appropriate packages on your system.

up2date  --solvedeps=<module1,moduleN>

Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

1、两年多来，我一直在试图更多的了解，中国互联网上的两个人：关明生、吴海。

2、这是两个其实没有干系的人。这是两个很特殊，很值得研究的人。
所谓值得，并非指他们的人本身，而是他们所做的事情。

3、关明生带着世界最先进的管理文化─GE的文化，把当时中国最土的互联网公司─阿里巴巴，从一个纯粹的泥腿子企业带上了正道。解决了“入道”问题。
吴海带着传统到不能再传统的市场营销方式，土拉吧唧的把一个由多位海归和神童/天才创办的，有着“先进文化”的互联网公司 ─ 携程，从云端拉到了地面。解决了“落地”问题。

4、据说，关明生对马云的影响极大。在他之前阿里巴巴完完整整的是一个泥腿子公司，从管理到生活，从上到下。
据说，当年携程在冬天里拿第二笔钱时，是以“收购吴海及他的商之行”为重要条件的。 N次谈判后，一边和“商之行”签收购合同，一边转脸拿到投资。

5、两人对这两个公司都有着不可替代的作用。他们是这两个企业的历史转折点。如果没有这两个人，也许阿里和携程想要走到今天的地步，会困难很多。
这是两个很好的，传统文化和互联网文化揉合的案例。

6、一直很想写篇关于他们的文章。
但，关于这两个人的信息和真实事迹在互联网上传播的很少。甚至很多人根本不知道他们。
我只是常从了解事实的人那里挖到一些信息。但信息量很少。

7、关于吴海，还有一个民间的八卦，不写出来放在肚子里总是不舒服。
传 闻：吴海当年的女朋友在携程的竞争对手公司做，季琦对此很不happy，吴海觉得人家又没跟自己结婚，凭傻要左右人家姑娘。所以双方发生一些分歧，吴海于 是索性离开了。离开之前梁建章也提到要不要保留股份，吴海拒绝了。所以这也就造就了现在传说的：“史上最值钱的女朋友”。价值一个亿…

8、欢迎知道更多相关“真实信息”的人，给我提供更多有意思的信息。  然后我们整理到一起分享。