Microsoft advices to use /3Gb switch in Boot.ini in order to get more memory for a process running on 32bit system.
Currently I need a lot of memory for devenv process (Visual Studio 2008) because I have a complex solution that has a lot of projects and forms and consumes a lot of resources in design time.
I would like to ask, if anybody knows, what are negative aspects of using /3Gb switch, are there any circumstances where it is not recommended to use it.
On a desktop machine, there are likely no problems. The kernel paged pool is smaller on a W2K3 / WXP machine w/ the /3GB switch set. This is probably not an issue for a desktop machine because you shouldn't be coming close to exhausting your kernel paged pool. On a server, exhausting the kernel paged pool will cause you problems, and it's much more likely you could exhaust it.
Here's some good detail about the kernel memory considerations associated with the /3GB switch. If you really want to, you can fire up the NT kernel debugger and profile your system before and after the change w/ the information in this doc: http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx
You will have less memory available to your kernel - the switch adjusts the kernel mode address space/user mode address space split, previously 2GB to 2GB, to 1GB to 3GB. Read Raymond Chen's post on /3GB, and the follow-ups, before proceeding.
Before making any changes, you should first check if the processes you want to run are linked with the LARGEADDRESSAWARE flag. With the flag, there will be no changes to how the process uses memory.
You can use the SDK Tools for this:
The headers spit out should include:
I did the check on devenv.exe and in VS2008 it does include the flag.
Plenty of drawbacks. By default, Windows will allocate a 4GB memory pool to every process, which is split 50/50 between the kernel mode processes (common to all apps) and user mode processes (unique for each app) (simplified explanation). An app running on the system therefore has 2GB of memory to play with, while the system itself has it's own 2GB. Important note: this second 2GB is the same 2GB for all apps running on the system.
The /3GB switch adjusts the split so that kernel mode gets 1GB and user mode gets 3GB.
Now consider the apps you're running. Some of them will require more kernel mode space, some will require more user mode space. As the kernel mode pool is shared, you can very quickly run out of memory there if you're running apps that put kernel mode memory under pressure. On the other hand, if your apps use lots of user mode memory, implementing /3GB will give them the headroom they require.
So it's really down to the nature of the applications you want to run. The golden rule is to consult the app vendor and read the documentation; in particular if the app vendor doesn't have a recommendation either way you should start becoming suspicious... have they properly tested their app or not? This is basic stuff that every vendor should know.
There's a pretty good discussion of it all here: http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx
In your particular case, I think switching to 64 bit and getting more RAM will be a more viable solution, as /3GB won't really get you what you want (does it even work on XP?)
We've used it on a couple of systems that were running image processing apps on lots of large images, and never noticed any problems. In any situations where you need the extra Gig of application memory, you're probably going to let the app run and not do anything else with the system, so there's probably not going to be much impact.
I have seen it interfere with video cards in odd ways. But any driver can misbehave with this switch if it's not written properly.
Sometimes these issues can be worked around with the addition of the /USERVA switch.
http://support.microsoft.com/kb/319043
http://support.microsoft.com/kb/833721
http://support.microsoft.com/kb/839490
http://support.microsoft.com/kb/316739
It only works reliably (except for debugging drivers etc) on an enterprise server OS for LARGEADDRESSAWARE binaries.
devenv is not such a binary. SQL Server and Exchange are, for example.You'd need an x64 bit OS
and VS x64edit: LARGEADDRESSAWARE is detected on x64 to break the 2GB limit.