Page / Swap Files and you - Part 1

Hey another "part 1" article!

Okay, so I have a bad track record ... but I'm going to keep trying!

On a couple of occasions I've been asked "what should page files be set to" (I say page file because it invariably is a Windows deployment we are discussing). My answer is "depends." There are quite a few greatly detailed articles about how page files work etc so I'm not going to go over them here. Google (or Bing (ick)) them and have fun with the feeling of your head exploding. For my part lets keep it digestible and focused on virtualization.

VM level

So this most often comes up cause someone foolishly allocated 30gb to the main partition and now you're in a storage hole. Anyone who doesn't know the "60/x/x" rule needs to be educated ... but I digress. So going back the question is how much page file is needed. In the past the rule was always 1.5 x physical memory. This rule came about for various reasons but one of the main ones was that 4gb was the nominal limit for server memory. Giving it a big page file help performance (research 'commit charge' for more on that). The other reason, though less heavily used, was the fact that when a memory dump happened (BSOD) you needed a page file big enough to take it.

In this day and age of x64 and super high limits (if you can call them limits) on memory begs the question: do we stick with the rule? Short answer: yes. Long answer: well yes but if we are talking a really big amount then maybe no. Example: a file server is usually a 2/1/4 (cpus/cores/RAM) affair, this results in a page file size of 6gb. Not so bad and within reason. Now lets look at a virtualization server. Example: a XenApp server is typically a 2/2/16 which would result in a page file (using the old rule) of 24gb. Whoa!

So on the latest x64 OSes we have a quandary! Okay, not really cause there is an easy way to figure out what is really needed. Remember the first reason we noted, well that part is not needed quite as much with so much physical memory available. So the dump is the key and here's a question: how much memory is really needed for a dump. Turns out a lot less then maybe it used to need. Try 1/3 of what you might think. So here's what I'd suggest:

Physical Mem
2 to 8 GB == 1.5 x RAM
10 to 16 GB == 0.75 x RAM
18 to ? == 0.5 x RAM

It generally works and makes sure that there is enough page file for a typical kernel dump in the larger ranges. The storage foot print is reasonable so things don't get out of hand. Of course you can still use the 1.5x rule and be just fine if you have storage to burn.

In the next part we go to the host level!

Peace.

Experiences in Project Consulting

Well been a while eh? I'm still out here just been a tad busy. Thing is I've had tons to say but not much time to say it. Time to get back on that horse. I'll be posting a few things encountered and some new tips ... but what am I going to talk about today?

It's taken me days to get to this and I really wanted to post something right away but felt I needed to cool off. Good idea. So now that I have ...

As a consultant we all expect a certain amount of professional curtsy. We all believe that each of us are able to do what is needed and can handle anything thrown our way. We believe that our fellow consultants are as good as us and we are "The Team" that gets called in to fix the unfix-able, to build environments that are shining examples to all others. For the first time my faith was shaken in that regard. I guess it can't be helped, when you work at as many places as I have you're bound to find a few small minded people even in our field. It was just a shock ... but let me lay it out.

I was called in to a major project to deploy applications via ThinApp to be used in a VDI rollout. First off I'm not terribly strong in ThinApp but I'm not unskilled in it and I was assured that I was not going to be the only asset. So I go in with high hopes and looking forward to brushing up on things. From day one the outgoing Citrix "expert" took a dislike to me. I asked too many questions about the current environment it seemed. Of course that's what I was there for so you can imagine my surprise at the claims of me being snobby and sarcastic (well I'm kind of naturally sarcastic but hey). This was a first for me and usually the team works things out but this person made it their job to undermine the team dynamics.

If you hadn't already figured it out, things went south. The "expert" had the ear of the PM, that and a sudden change in marching orders gave the person an insider's edge. I was forced to move on. Again another first after so many successful projects and great teams that I've worked with.

So what do I take away from this? First off, define and gain acceptance of your place, goals, and actions in the team. Second is communication, but in a way that shows engagement and not just noise. We as independent and autonomous minded folk occasionally fail to remember that though we are working our butts off, to some it can look the opposite. Finally, and here's the hard part, if you feel the team is not in sync and/or maybe you're not a good fit, determine if you need to pass the baton. If you decide that it's not going to work, don't waste time trying to make it work, it won't and it can damage your sense of well being. In my experience I got some good time in but ultimately is was wasted effort project wise. Other projects will come along. Trying to hold on to a failing position can be a negative down the road. Take the high road when possible.

I hope it all works out for the project. The remaining team should be able to pull it off, and I'm sure that they will bring in other assets. I believe that all experiences are learning experiences and this was just another one. I still got four weeks of paid training that got me back up to speed on the latest in VMware. That was worth it alone.

So ... on to the next adventure!