-4

I am maintaining a Small Business Server 2003 (x86) server, that was originally installed and configured by someone else in early 2009.

Recently, although we have never had any obvious memory-related performance issues, I have started to wonder if the virtual memory was configured optimally when it was first set up.

Should I leave the virtual memory with its existing custom settings- or is there any value in tweaking it?

What would you change the virtual memory configuration to, and why?

Here is the current configuration:

enter image description here

enter image description here

enter image description here

enter image description here

Austin ''Danger'' Powers
  • 1,180
  • 6
  • 21
  • 51

4 Answers4

2

Also, it has 4GB of RAM installed, but only 3.75GB visible to the OS.

SBS 2003 was limited to 4GB and 32-bit versions of Windows lose a little memory due to system device space - it's just a limitation.

I am not sure why the previous IT guy opted for x86 when I it has a 64-bit CPU.

There was no 64-bit version of SBS 2003.

a) Should I leave the virtual memory with its existing custom settings- or is there any value in tweaking it? What would you change the virtual memory configuration to, and why?

Set it to 'System Managed Size.

b) Also, any theories as to why the previous IT guy only put a 32-bit version of SBS 2003 on this server, despite the hardware supporting 64-bit, would be appreciated. It bugs me that not all of the memory is visible to the OS. I wonder if this was done for compatibility reasons (or because x64 is more memory-hungry and 4GB RAM wouldn't be enough to see a net benefit)- or if he basically just screwed up and should have put x64 on there to start with?

As above - you clearly don't know the basics of what you have, in fact googling for "SBS 2003 64 bit" shows this right away.

Chopper3
  • 101,299
  • 9
  • 108
  • 239
  • Thanks for clearing that up. I never thought to check if SBS 2003 was available on x64 to be honest. It never crossed my mind that a server from the same era as XP (which was available in 64-bit) would be restricted to 32-bit architecture. Forgive my ignorance. – Austin ''Danger'' Powers Jul 21 '13 at 20:19
  • 1
    Exchange was the reason that SBS 2003 was only available in x86. Exchange 2003 won't run on x64 and, at the time SBS 2003 was released, there was no 64-bit Exchange offering available. – Evan Anderson Jul 21 '13 at 20:50
1

There are three primary reasons for an admin to chose to install a 32-bit OS on hardware that can do 64-bit.

  1. They don't trust the 64-bit stuff yet. Not much of an issue these days, but definitely was as recently as 5 years ago.
  2. They don't install 64-bit on anything that can't "use" it. Where use is RAM > 4GB. This only has 4GB, therefore only install 32-bit. Again, not much of an issue these days but was one, once upon a time.
  3. There is a specific (old) application that only runs on 32-bit OSes.

Optimum VM settings are very much site-specific, and I can't tell you what optimum is for you.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • There are so many different schools of thought on virtual memory configuration. I was interested in hearing how people here reach their decision when configuring it. – Austin ''Danger'' Powers Jul 21 '13 at 20:22
1

Yeah, there are a lot of varying opinions and articles on how to size your pagefile. Here's what I do:

If the OS is Windows Server 2008, 2008R2 or Windows Server 2012 I let the OS manage the pagefile.

For Windows Server 2003 (including R2) and earlier (Windows 2000) I set the pagefile equal to the amount of physical RAM and make it static, meaning the Initial size and Maximum size are the same, which allows the OS to create a static pagefile of one size and reduces or eliminates the the incidence of pagefile fragmentation.

This is, of course, not a scientific approach by any means but it's what I've used for years.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
1

Paging files... it's the age-old question. The answer is... monitor your server over a predefined period, in which you believe it will undertake a "typical" workload.

Keep an eye on your peak commit charge, and once you've established your peak, subtract your amount of physical RAM. Use this figure to determine your total paging file size.

As for x86 vs x64, the only reason why you'd have to stay on x86 is if you can't get x64 drivers for one or more hardware components. Other than that, WOW64 (Windows-on-Windows 64bit) does a very good job of running x86 code on x64.

Simon Catlin
  • 5,232
  • 3
  • 17
  • 20
  • I have updated my question to show peak commit charge (approximately 1.2GB after 8 days' uptime). Memory visible to the OS (3.75GB) - peak commit charge (1.2GB) = 2.55GB. So, just to clarify, does "*page file size*" refer to the initial, or maximum amount of virtual memory? I'm assuming initial? – Austin ''Danger'' Powers Jul 21 '13 at 20:44
  • The value shown in System Information (msinfo32.exe) is your current paging file size. In your case, you only have one paging file, and it's on your boot/system drive, so you can check it's size from a command prompt, by typing "dir c:\pagefile.sys /as" (without the quotes). Going back to your original question, it would appear that your system isn't struggling with physical RAM. Oh, and one last point, and only to clear up something I've seen some folks get mixed up with... the 4GB limit with x86 Windows is a per process limit. – Simon Catlin Jul 21 '13 at 21:16