I use the following formula to size the minimum number of cores on replacement servers. The formula is based on "used" performance on the installed servers matching "used" performance on the replacement server.

c2 = (u1)(c1)(p1) / (u2)(p2)

Where

c1 = # cores on the installed server
p1 = "performance per core" of the installed server
u1 = % utilization of the installed server

c2 = # cores on the replacement server
p2 = "performance per core" of the replacement server
u2 = % utilization of the replacement server

If consolidating multiple stand-alone servers to micropartitions, sum the replacement cores (c2) required for all the stand-alone servers.

The “performance per core” should be based on a relevant benchmark for your workload. The preferred metric is your application‘s benchmark. In absence of that information, pick an industry benchmark that approximates your work load. Historical and current benchmarks for AIX servers can be found at

http://www-03.ibm.com/systems/p/hardware/system_perf.html

In all cases, you should size for the peak utilization during your peak processing period (daily, “month end“, “seasonal peak“, etc). If the replacement server uses micropartitions, use the aggregate peak utilization. (Note: Servers peak at different times, so the aggregate peak is not the same as the sum of the individual peaks.) A good tool for determining the aggregate peak utilization is Steve Atkin‘s “NMON Consolidator Tool”:

http://www-941.haw.ibm.com/collaboration/wiki/display/WikiPtype/nmonconsolidator

Choosing the CPU “% utilization“ for the replacement server depends on whether its using LPARs or micropartitions. Here are my guidelines for the minimum sizing, with my standard disclaimer: “Your results may vary. Use your best judgement.”

LPARs, Stand-alone Servers, Capped Micropartitions

Size for the peak processing period. Target the replacement server for 90–100%. If peak processing unknown, size the replacement server for an average 30% utilization. Round up to the nearest core.

Uncapped Micropartitions

Size replacement server for the aggregate peak of the installed servers. There is some overhead associated with micropartitioning, so size the replacement server for 80–90% utilization during the aggregate peak..

If aggregate peak is unknown, size the replacement server for the average utilization of the installed servers. Target the replacement server for 50%-70% utilization so it has spare capacity for the peaks.

Round up the shared pool to the nearest core.

Final comment. Micropartitioning has two at least two sizing advantages. Typically it requires half the CPUs as LPARs. And sizing micropartitions is more forgiving. If you size incorrectly, its easy to move resources to where its needed. My experience is that I oversize half the micropartitions and undersize the other half. On the average, the sizing is OK.

Here's a link showing how to use NIM to install VIO servers

http://www-941.ibm.com/collaboration/wiki/display/LinuxP/IBM+VIOS+Installation+over+NIM

Contributed by Celeste O’Connor

Release Found: Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4

1. Click the schedules link, then the add new schedule link.
2. Enter a name for the schedule.
3. Click the Add Time Range button.
4. Select the days for which this time period is applicable.
5. Select the time period.
6. Click the Accept button.
7. To add another time range, click the Add Time Range button.
8. When all the time periods are configured, click Finished: Save Schedule.

Show me how:p>

Click here for a flash demo that outlines the whole process.

上海大拇指广场旁边的许留山，给某人畅想一下。 椰汁红豆雪蛤膏的味道确实超赞。:)

Author:NinGoo posted on NinGoo.net

折腾了一天，终于将blog系统升级到wordpress2.3中文版。下午一直在看网上的一些升级文章，wordpress2.3由于数据库改动较大，升级可能导致很多插件冲突。所以预先将目前在用的几个插件都先升级好，尤其是Google XML Sitemaps和Extended Live Archives，ELA官方没有更新，请使用网友istef修改的版本。另外，由于wordpress2.3引入了自带的tag系统，原来用的tag插件UTW将无法使用，需要卸载。原来的tag可以通过wordpress提供的导入功能导入到新系统中，方法是，在后台管理中选择管理->导入->Ultimate Tag Warrior，点几下鼠标即可。

升级过程很简单：

第一步：备份数据库。我用的dreamhost主机，最简单的备份方法，一是使用WordPress Database Backup插件备份；另外一种方法就是新建一个mysql库，然后利用dreamhost提供的phpMyadmin将原库复制一份到新库中，注意字符集的选择。

第二步，配置好wp-config.php中的数据库连接信息，然后上传wordpress2.3中文版上传到根目录下，将网站原目录改名，再将新的wordpress2.3的目录改成原来的名字。通过前两步，即使升级失败，也可以方便的切换回旧系统，万无一失。

第三步，执行/wp-admin/upgrade.php升级，点一下鼠标，一秒钟搞定。

第四步，迁移upload的文件，修改模板和插件等。

前面三步都非常简单，也没什么风险。主要是第四步要花比较多的时间。原来相关文章的功能依赖于UTW插件，而wordpress2.3自带的tag系统目前还比较弱智，一是不好管理，二是没有引入根据tag显示相关文章的插件。所以不得不为这两个功能又装上两个新的插件：Advanced Tag Entry用于管理tag，Tag Converter 4 UTW用于显示相关文章。由于tag converter 4 UTW的TC_ShowRelatedPostsForCurrentPost函数采用的直接echo输出相关文章而不是returen的方式，导致Feed中相关文章在最前面显示了，所以还得在tag converter 4 UTW中复制一个TC_ShowRelatedPostsForCurrentPost4Feed函数，将相关文章的字符串return而不是echo。

还有一个问题，就是原来使用ST_AddRelated2Feed插件给Feed输出加上了相关文章，但是这个插件也是基于UTW的，所以需要修改，使用tag convert来获得相关文章。

顺便提一下wordpress2.3自带的tag系统的两个调用函数：the_tags()用于显示某篇文章的tag，wp_tag_cloud()用于显示标签云。两个函数都有大量的参数，可以到/wp-includes/category-template.php中找到函数定义的地方了解具体的参数。

同时将模板的字体从12px调大到14px，虽然看起来没那么整齐了，对眼睛还是有好处的^_^

可能还有些没考虑到的地方，如果大家在浏览本站的时候发现问题，请留言告知，谢谢。

Related Articles

• Wordpress 2.3 Beta 1发布
• Wordpress插件：历史上的今天
• 打开wordpress压缩选项导致warning
• 模板颜色调整完毕
• Wordpress统计插件：FireStats

马来西亚在我们离开的今天开始阳光灿烂，而前两天一直是阴雨不止，昨天晚上更是暴雨倾盆，但是在香格里拉的气质阳台上听雨也确实很有情调。 这两天虽然由于天气的缘故不是玩的很尽兴，但是也仍然浑身酸软。先预留两篇吧。 马来西亚之行 - Mamutik Island 马来西亚之行 - Manukan Island 今天几乎一天的飞机回到北京，短衣短裤抵达，北京居然也在下雨，秋天了啊。