Main Area and Open Discussion > General Software Discussion
Seeking experiences from people backing up relatively large personal data sets
Shades:
As far as I know Windows doesn´t allocate more than 2GByte of RAM to any process. Unless you have specially build executables (Large Address Aware) and boot your Windows system with some extra parameters.
Been there, done that, don´t recommend these tricks to anyone, unless they absolutely need it. Your system will become noticably slower after a while and will keep detoriating until it becomes too slow. Ah well, serves you right for surpassing the Windows memory manager.
Tested this setup once with Excel (2003 till 2010) in a scripting environment and I was baffled how (any) Excel is able to suck all resources from a 8GByte i7 so quickly.
JavaJones:
I'm running a 64 bit version of Windows 7. Provided the application I'm running is 64 bit, it can allocate as much memory as I have available. I don't recall whether I'm running 64 bit Java (CrashPlan is programmed in Java, unfortunately), nor whether CrashPlan itself would need to be specifically programmed to take advantage of 64 bit memory space or if simply running in 64 bit Java would do the trick (I'm guessing the latter). But in any case my memory limit in the config files is 2048MB, and it's not going over that.
- Oshyan
TaoPhoenix:
I just recently backed up about 150 gigs by hand, over a few days. I kept getting "file name too long" errors and since it was low importance data I just skipped those pieces. Do these programs copy "filename too long" files?
Shades:
Nope, Windows won't allow any process to consume more than 2 GByte. Believe me, I got a 64 GByte RAM computer that also has 64 processors to its knees, because of that.
Doesn't matter if the OS and/or the application is 32-bit or 64-bit. The Windows memory manager won't let you..unless you step in and take over from it. See KB article 833721 for startup parameter '/3GB'. Still, you are only allowed to consume to a maximum of 3 GByte RAM per process.
Only after enabling that startup parameter on a 64-bit OS and having a 64-bit compiled application you can go over the 3 GByte limit to go to a 4 GByte limit. Expect to run your system into the ground sooner than later though.
As far as I know both the 32-bit and 64-bit Windows memory manager sees that there is 4 GByte of RAM, even if your PC has less physical RAM. Whatever is not there, will be delegated to the hard disk (swap-file). 2GByte of this RAM is for non-Windows processes only, the other 2GByte is also open to Windows kernel processes.
With the /3G parameter you limit the Windows kernel to just 1 GByte and whatever non-Windows process is allowed to use 3 GByte. Nether you or the Windows memory manager is going to be pleased with this. So, if you have an application that consumes 2 GByte, that application is clearly doing something so wrong it doesn't deserve a place on your hard disk in the first place.
Yes Excel, I'm looking at you...
4wd:
Only after enabling that startup parameter on a 64-bit OS and having a 64-bit compiled application you can go over the 3 GByte limit to go to a 4 GByte limit. Expect to run your system into the ground sooner than later though.
As far as I know both the 32-bit and 64-bit Windows memory manager sees that there is 4 GByte of RAM, even if your PC has less physical RAM. Whatever is not there, will be delegated to the hard disk (swap-file). 2GByte of this RAM is for non-Windows processes only, the other 2GByte is also open to Windows kernel processes.
With the /3G parameter you limit the Windows kernel to just 1 GByte and whatever non-Windows process is allowed to use 3 GByte. Nether you or the Windows memory manager is going to be pleased with this. So, if you have an application that consumes 2 GByte, that application is clearly doing something so wrong it doesn't deserve a place on your hard disk in the first place. -Shades (November 27, 2012, 04:40 PM)
--- End quote ---
From Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003
System PTEs
A pool of system Page Table Entries (PTEs) that is used to map system pages such as I/O space, Kernel stacks, and memory descriptor lists. 64-bit programs use a 16-terabyte tuning model (8 terabytes User and 8 terabytes Kernel). 32-bit programs still use the 4-GB tuning model (2 GB User and 2 GB Kernel). This means that 32-bit processes that run on 64-bit versions of Windows run in a 4-GB tuning model (2 GB User and 2GB Kernel). 64-bit versions of Windows do not support the use of the /3GB switch in the boot options. Theoretically, a 64-bit pointer could address up to 16 exabytes. 64-bit versions of Windows have currently implemented up to 16 terabytes of address space.
--- End quote ---
From RAM allocation for applications in Windows 7 x64/ Where is the 3GB switch for x86 apps?
Memory allocation is set automatically.
If a 32-bit application is compiled with the IMAGE_FILE_LARGE_ADDRESS_AWARE switch set it is allocated a 4GB address space in 64-bit Windows. If not, it is allocated 2GB.
For 64-bit applications, if IMAGE_FILE_LARGE_ADDRESS_AWARE is set when compiled - the default is set - it can use up to 8TB. If IMAGE_FILE_LARGE_ADDRESS_AWARE is cleared it can use up to 2GB.
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version