xxx@svr1:~$ sudo grep ThreadRPCServer ~/.nu/debug.log | sort | uniq -c
[sudo] password for nubits:
3369 ThreadRPCServer S method=getblock
544 ThreadRPCServer S method=getblockhash
216 ThreadRPCServer S method=getrawmempool
6776 ThreadRPCServer S method=getrawtransaction
10 ThreadRPCServer started
Iâm using even less types and memory usage is only slightly higher then with my nodes but not much.
Is there something else than just memory which would cause the OS to kill a process?
Definitely not having the restarts as often as Backpacker has, but that box has higher usage probably.
This system seems too low on memory. The daemon alone could probably run but it looks like you have other processes that use a significant amount of memory. At that moment your kernel and processes used about 5.2 GB of memory (mem used - buffers - cached + swap used).
According to your logs the daemon used 3.7 GB of memory when it was killed. Thatâs much higher than on my nodes but it matches the highest values @backpacker displayed. So the daemon likely requires that amount of memory at regular intervals (maybe to process a new block for example).
If that memory usage happens for a short period of time then what you copied probably doesnât contain it. If the daemon used 2.4 GB at that time (like during most kills of backpacker), then you should add 1.3 GB to the requirement. So Iâd say your system needs about 8 GB of RAM.
Not when it mentions âOOMâ or âout of memoryâ like in the logs you copied above. Otherwise yes there may be system processes that kill other processes for various reasons, but I canât think of any that would be configured like that by default on the main Linux distributions.
Thanks for your elaborate answer. I knew that kind of, thatâs why there is 2Gb of swap memory. Unfortunately it only emphasises that the current client is a real memory hog, mainly because of the ever growing blockchain. I started with 2Gb, moved to 4Gb 3 months ago and now I need to move to 8Gb. I believe it is becoming to expensive too fast to run clients.
I wondered what happened with the effort to decrease the memory footprint. I know there were some alphas or early betas on that (v2.1 I believe). Do you think it is worth pursuing that path again?
I made a quick experiment during initial download and it showed that the memory size increases by about 2.55 kB per block on a 64 bits Linux system. That would be 3.6 GB for the current block count so that would match the 3.7 GB requirement. So it would grow by 1.26 GB each year.
The ability of my node to run the daemon with 3 GB (+0.5 swap) is thus likely due to the fact it runs on 32 bits, where the usage would be around 1.4 kB per block.
Yes it was Nu 2.1. It was abandoned because there were other priorities back then. I think it was almost working fine after @woodstockmerkle made significant improvements (and he also improved initial download times). I think the only remaining problem was some situations where the client had a burst of memory usage to the levels we currently experience (or maybe worse). And there has been changes since then so it would requires some work to merge all that.
Probably. There may be other ways to decrease memory usage or the rate at which it increases, but this one is probably the easiest since it was not very far from being finished.
Can you provide more information? Like the amount of memory you have and what I described earlier:
I tried a vm with the following: 1, 2, 3 gig. No dice.
On a system with 16 gigs shared with other wallets. However, the more coins you have the more cpu cycle and memory it consumes as it continues to split blocks automatically. Until it gets to a point where the wallet just simply crashes.
This is indeed not enough. On Linux 64 bits the client seems to use 3.7 GB. Windows 8 64 bits seems to requires 2 GB of RAM, so I guess you would need about 6 GB.
The CPU usage is the minting process, during which thereâs indeed a split of your outputs that will increase the CPU usage 7 days later because it also increases your odds to find a block. You can disable coin splitting (splitshareoutputs=0 in the config). You can also disable minting by encrypting the wallet and keeping it locked.
It should not crash though. How does it crash? Do you have the end of debug.log at that time?
6 Gigs is way too much compared to other wallets and at this point the wallet is unusable. So the only option left is either keep restating it all the time and maybe it will stay up long enough to offload some of the coins to the exchange or get rid of it completely.
I and a group of other people are currently facing this issue.
However, by comparison for example I have a HYP wallet which is also a POS wallet with millions of blocks runs without any issues requiring very litle resources. In fact you can run it on a pi if someone really wanted to.
NuShare wallet is consistently crashing and I havenât been able to stay connected or even use it the wallet cause everytime I go and get ready to shoot over to Nushares the wallet immediately crashes. I need help to find a way to get this wallet going again. Could anyone help me out on how to get my logs on where the wallet crashes.
I agree but this is because we have a lot more data in our blockchain than other coins (mostly about votes and their results).
Can any of you provide some logs or error messages?
Do you run with less than 4 GB free memory besides what the system needs? If you canât have that amount of memory you could run with a lot of swap. If would be slow but it should work.
It works with 2 Gb swap on a 4Gb machine. But it would still crash every few days as I have showed earlier.
We should really start thinking about addressing the memory issues one way or the other. It just creates too much issues while a wallet should just work on an average PC. Else we are creating our own problem.
@sigmike the picture that @bitmaster1 posted is what i get as well. Sometimes it will run idle and when i hover the connection bars in the right corner it telling me that it catching up with the block and it has been 5 days that i havent been able to get anthing going. @sigmike ill try to switch over to the nusares wallet and then it crashes when with the pciture above.
You likely need more because of the other programs youâre running.
I can start working on merging 2.1 and finish the changes. I cannot estimate the cost though.
Can any of you retrieve the last lines of the log after it happened? That may help figuring out whatâs happening, because since I canât reproduce it I have no idea whatâs happening. And what is your OS?
Whatâs your current number of blocks? Is it increasing? (itâs displayed in the debug window from the help menu)
So it crashes when you switch to the nushares wallet? Does the crash happen only when you do that? Does it also crash randomly when youâre not interacting with it?
