Why I created a blog

Its been many years since I first created this blog. It has remained true to Essbase and related information over those years. Hopefully it has answered questions and given you insight over those years. I will continue to provide my observations and comments on the ever changing world of EPM. Don't be surprised if the scope of the blog changes and brings in other Hyperion topics.


Tuesday, May 10, 2011

Sometimes less is more!

I have a client that has two Essbase instances, a test server and a production server. Both are running on VMs and use the same number of CPUs(4), the same memory (8 gig) run the same Windows 64 bit operating system, have the same cfg file, the same SAN, running at the same time with the same exact data and nothing else running on them. So why am I writing this? The test server was processing everything much faster that the production server. When I say much faster, I mean test ran a process in 7 hours while production ran in 13 hours. Neither is fast, but this system is very complicated with a lot of data loads, calculations, extracts and reloads in the process. We were dumbfounded by the differences. Something had to be different.

We checked everything we could think of and finally found it. On the test server, the virtual memory was set at 6 gig while on production it was set at 11 gig. The normal wisdom is that you set your virtual memory (system page file) at 1.5 times your actual memory. Interestingly enough, in the very old days of Essbase we used to crank up the virtual memory as high as we could. We did some experimentation and increasing the memory on test degraded performance and reducing the virtual memory on production improved performance.

Wow was this counter-intuitive! Apparently reducing the memory allowed the 64 bit operating system to handle the memory better on its own. When you use virtual memory, it is actually writing to disk, real memory has no IO associated with it. I’m guessing  when we reduced the virtual memory, it forces the OS to use more real memory since it could not write it to disk.

We thought is 6 gig is good, maybe 5 gig would be better. We were wrong. For this server 6 gig seems to be the sweet spot. Does this affect 32 bit systems? I don’t know, but I do now know this can be an impact on 64 bit systems. This just goes to show that sometimes less is more.

I know everyone who reads my blog are cool kid (That’s why I’m not allowed to read my own blog), so I wanted to remind you that KScope11 is fast approaching. As I write this it is only 47 days away. I also know you have all registered for the conference already. You didn’t? what are you waiting for? You want a deal, register and enter the code IRC and get a $100 discount on registration. Also if you are not already a member of ODTUG, you get a complimentary  membership worth $99.  That way you have access to all the cool stuff like papers, presentations and webcasts.

No comments: