Lately, we've been getting a lot of questions related to Exchange 2007 memory consumption and why Exchange uses so much of the paging file. Well, there are some valid reasons why and some misconcepti...
Published Aug 07, 2008
Version 1.0
Blog Post
Thanks for sharing this,
Triggers me to ask the following:
I've been tought to calculate the required storage design for E2K3 and E2K7 on W2K3 or W2K8 in basically the same manner to get a better understanding of the calculator sheet developed by dev. team and to be able to validate/tune outcome. This calculation method does not really take into account the Cache Hit Ratio that reduces storage I/O requirements, during normal Exchange operation. There are good reasons for this, because we need to take into account server startup / peak load / and recovery on the storage level (raid rebuilds), etc. It is important to be able to address this "exceptional" situation (assuming your server is running normally most of the time), but this way we are essentially always overestimating the real disk I/O requirements. So, to get back to my question, does it make sense to include some kind of baseline or measured Cache Hit Ratio for Read I/O into your storage calculation (and different figures based on OS and Exchange levels/combination), to determine a more average "Host Read IOPS" requirement (Writes must always be written to disk), resulting in for example the ability to choose a cheaper storage solution? (I.e. raid 5 instead of raid 10, or slower disks) And what would the new function then really look like to determine this.
So to summarize: We say that with E2K7 we use more RAM for a good reason, we say that we can use cheaper storage solutions, because of reduced disk I/O requirements, but the calculations we use do not seem to be well enough aligned with the statement we make.
Feel free to correct me, just throwing up a ball.
Thanks again!
Triggers me to ask the following:
I've been tought to calculate the required storage design for E2K3 and E2K7 on W2K3 or W2K8 in basically the same manner to get a better understanding of the calculator sheet developed by dev. team and to be able to validate/tune outcome. This calculation method does not really take into account the Cache Hit Ratio that reduces storage I/O requirements, during normal Exchange operation. There are good reasons for this, because we need to take into account server startup / peak load / and recovery on the storage level (raid rebuilds), etc. It is important to be able to address this "exceptional" situation (assuming your server is running normally most of the time), but this way we are essentially always overestimating the real disk I/O requirements. So, to get back to my question, does it make sense to include some kind of baseline or measured Cache Hit Ratio for Read I/O into your storage calculation (and different figures based on OS and Exchange levels/combination), to determine a more average "Host Read IOPS" requirement (Writes must always be written to disk), resulting in for example the ability to choose a cheaper storage solution? (I.e. raid 5 instead of raid 10, or slower disks) And what would the new function then really look like to determine this.
So to summarize: We say that with E2K7 we use more RAM for a good reason, we say that we can use cheaper storage solutions, because of reduced disk I/O requirements, but the calculations we use do not seem to be well enough aligned with the statement we make.
Feel free to correct me, just throwing up a ball.
Thanks again!