Quote from: picobit on April 07, 2015, 09:50:13 AM

Quote from: STRML on April 07, 2015, 01:56:28 AM

Anything to be done about armoryd's crazy memory usage? I'm seeing 41GB virt and about 6GB residual. It's causing other processes to start swapping. It is done scanning blocks, this is persistent memory usage. In comparison, bitcoind only uses about 55MB residual.

Restarting the process causes the memory to go down, but then armoryd starts eating up CPU and filling up again. It continually is using the lion's share of resources on the system.

When a program (such as Armory) reads a file, the file is copied into memory. As soon as Armory is done using the file, the memory is marked as available for other programs, but until another program claims the memory, you still see it as assigned to Armory because the kernel assumes that there is a chance that Armory will open that file again, and Armory's data is still there.

All modern operating systems do this, so it always look like there is very little RAM free. I do not know about Windows, but on Linux the kernel still keeps track of that memory after Armory quits, in case some other program happens to want the same file. As soon as the memory is needed for something else, it is wiped and assigned to that something else.

I don't think this is exactly true in Armory's case. We have attempted to jail Armory using cgroups but during database rebuilds it fails if the memory restrictions are too stringent (<2GB in my testing). Additionally, if there is swap on the system, it appears the system will use the swap before asking Armory to relinquish any of its used memory, causing other processes on the system to hang waiting for I/O.