QUICK BACKGROUND
Although x64 is officially unsupported in SMS 2003 for any site components, the reality is that you CAN put the Distribution Point role on an x64 server in SMS 2003. Now, I'm sure like us some of you have tried but get all kinds of 500 level errors out of IIS. The problem is that the SMSFILEISAPI filter for SMS is 32-bit but ASP.NET is in 64-bit mode. When the DP role is installed by default, that ISAPI filter seems to get put into the SYSTEM32\INETSRV folder which on an x64 server is for 64-bit filters. Brian Mason, our SMS MVP, figured out that if you enable the 32-bit version of ASP.NET and move the SMSFILEISAPI.DLL file from SYSTEM32\INETSRV to SYSWOW64\INETSRV then BITS magically starts working. (here's his article on the subject)
THE PROBLEM WITH A 32-BIT OS ON A BUSY SMS 2003 DP
At some point, an SMS distribution point can only handle so many concurrent connections happening all at the same time. The problem isn't that Windows Server can't handle a lot of connections, because it can handle tons and tons. Instead the problem is that Windows Server can't seem to handle them all trying to connect SIMULTANEOUSLY. Let's say it's patch week (the week that Microsoft releases their critical OS and Office patches) and there's a bunch of patches that need to go out to the enterprise. Now let's say you set SMS up to distribute those patches to all of your machines at 12:00am. If Active Directory and the Windows Time Service are doing their jobs, all of your SMS client computers will be set to the exact same time. So when 12:00am comes, all of the SMS clients in the same time zone will connect to the distribution point(s) and try to download/install those patches. Again, it's not that the number of clients is too many, it's the number of clients connecting at the same time that is too many. Now I don't claim to know all of the inner workings of Windows or that I fully understand what's going on when all those clients connect simultaneously, but when we've had Microsoft look at our performance monitor logs, they've come to the conclusion that we're running out of of Kernel Paged Pool memory and Kernel Nonpaged Pool memory. My understanding is that each client chews up a little bit of memory on the server for each little connection. Because there are so many connections trying to open at the same time, the servers physically run out both paged and nonpaged memory before all requests have been met. There is no good recourse for this because the maximum pools of paged/nonpaged memory are so small in 32-bit Windows (relatively speaking). However, in 64-bit Windows, those pools have been increased to 128GB which is more than enough for all of our clients to connect. Their UNOFFICIAL recommendation was to use 64-bit Windows. Officially, it's not really supported by Microsoft, unofficially it's totally surpassed our expectations.
THE BEAUTY OF USING 64-BIT WINDOWS
So, we've just gone through a patch cycle with a rather large set of patches, at least in terms of number of bytes needed to get pushed. I wanted to see how our new distribution points are really doing now that they're x64 and now that they'll be stressed with such a nice sized patch-set. So I got out a Perfmon template that I've been using off-and-on for a while and decided to capture some statistics.
For a list of the counters I usually use to look for bottlenecks and performance, see THIS ARTICLE. It's not an absolutely ideal list of counters, but it's enough to tell you where the major bottlenecks are.
Here's a summary of what I found:
- During the peak, our busiest DP served up a solid 472Mb stream of data (that's only ~20% of the network bandwidth - 2GB teamed)
- At its busiest, there were 2094 concurrent connections
- Since moving to x64 on our DPs, they simply don't run out of paged/nonpaged pool memory, even during the 472 megabit peak.
- We can keep the DP roles off the site servers now (I know, they shouldn't be on the primaries anyway on an implementation our size, but we didn't have enough DPs. Don't judge me, it's not like you do everything by-the-book either :)
- With the SMS folder on a big multi-disk RAID 10 configuration there is simply no disk bottleneck.
- With the 2Gb network connection (teamed) we have, I think we could theoretically serve up 4 times the traffic without melting the server. That means amazing scalability numbers and, if you can pull it off, less DPs.
So, if you've got DPs that are running out of paged or nonpaged pool memory, and if you are fine with this not being supported officially by MS, then a DP on x64 may be for you. It worked OUTSTANDINGLY well for us.
Number2 (John Nelson)
MyITForum - Forum Posts
MyITForum - Blog
