Sizing Replacement Servers
sbodily 100000RUAA Comment (1) Visits (4677)
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
LPARs, Stand-alone Servers, Capped MicropartitionsSize 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 MicropartitionsSize 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.