Balancing database loads across multiple servers

  • Hi all. I'm wrestling with a planning issue that I'd like some advice about.

    We are going to move the contents of two of our database servers to new instances of SQL 2012 in the future and I'm beginning to plan for it.

    I've got a couple of queries that grab stats per database, one grabs the i/o per database, the other grabs the CPU ms per database.

    One server has almost double the i/o load of the other, and it looks like this:

    Total i/o

    SQL03126776340

    SQL0425894315

    However when I look at CPU time consumed, it is drastically flipped around and looks like this:

    ServerTotal CPU msCPU Mins

    SQL0424857734045414.30

    SQL03210722122735.12

    So how might I go through the contents of these two servers and decide how to best distribute their respective databases such that I achieve a more balanced operation?

    To my way of thinking, the i/o load is probably more important than CPU usage as I/O is so much more costly than CPU cycles. Is the ratio of CPU utilization per I/O relevant and would it play a factor in determining this jazz? If so, then I'm in for some difficult times as we have some dbs (MSCRM_CONFIG) for example that performed 851 I/Os but consumed 152,751,529,488 CPU ms.

    I know that Sharepoint seems to use the tempdb space like nothing I've ever seen before...10 million I/Os versus only 2 million in the highest Sharepoint database itself.

    Should I simply forget about the CPU utilization rates completely and just try to balance out the I/O load?

    Any thoughts/ideas/suggestions or direction would be greatly appreciated.

    Thanks!

    Larry

  • I'm going to assume that the new instances will be on new hw. if so, you'll more than likely have lots of cpu to spare. IO is harder to come by, so I'd focus on that. You may want to consider how much buffer pool each DB uses as well, as more ram can make for less io.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply