As for the virtual memory, Armory mmaps all blkXXXXX.dat files when building and scanning. No copy of that data is performed in memory though, it's basically just a caching hint for the OS.
The 4GB figure looks high. I usually don't break 1.5GB on my machine, but that's very dependent on your setup. Basically you are running into this:
https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockchainScanner.cpp#L195
In full/bare node, there is very little data to write during scans (you can check verify by looking the size of your ssh file in the database folder, it should be tiny compared to the 100GB+ worth of blockchain data), so I just went with the assumptions the writer thread would always outpace the scanner threads (i.e there would never be any write queue depth).
I could fix the write queuing in 30 min but I don't want to release DB changes this time around, as very few people have run into your kind of issue (you are probably the worst case so far). I plan on speeding up the DB a bit in a later release (gotta keep up with the ever growing blockchain), I'll deal with it then.
Quote
More info - it seems to have nothing to do with the box also running bitcoind.
I only suggested that because Core can eat up a lot of RAM (2~3GB)
