NuBits v5.0.1 Release

Tasks: 78 total, 1 running, 76 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.3 us, 0.0 sy, 23.6 ni, 75.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.5 st
KiB Mem: 4061564 total, 3943656 used, 117908 free, 2336 buffers
KiB Swap: 2097148 total, 1255780 used, 841368 free, 70116 cached

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.

Also Linux 64-bits

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.

1 Like

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?

On a windows 8 system the wallet is pretty much non usable with minimum specs. Crashes even with paging enabled.

What are the minimum specs?

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.

The log is in the data directiory under the name debug.log. The data directory location is in the first table here: https://docs.nubits.com/creating-conf-file/

Please provide the 10-20 last lines after it crashed (privately if you can’t tell whether it contains private data).

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.

Currently running 16gigs shared with other wallets. Paging enable.

@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?

Please do.

1 Like

PM you some bits of the log. :slight_smile:

Hi all! Where can I download the official local wallet for NSR?

The links are in the OP.