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.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7477027/viewspace-696113/，如需转载，请注明出处，否则将追究法律责任。