Node goes down/restarts every 10-15 minutes. thread allocation error in logs

[Alexey]

@consumerbot797287

If that’s really true, then perhaps a generous docker memory limit should be recommended (ie max of 50-75% of installed RAM)

you can do it of course, however, when it would reach the limit the container will be killed by a docker daemon. Usually RAM is consumed when the disk cannot keep up though. My nodes doesn’t consume too much even on load, but my setup is simple 1 disk/1 node.

@consumerbot797287

I guess it’s because you manage to divide the test load between 3 nodes? I have 3 nodes with 3 disks, but 2 of them were full

exactly my situation, two from three are full, the third is almost full as of now (but not when I posted, however it has 1.8TB in the trash, so I guess it would have more than 13GB of free space in the allocation).

@consumerbot797287

a single ext4 partition on 2.5" SMR connected via USB.

jackpot… USB + 2.5" + SMR on top = fatality. For this case you need to have more empty nodes to split the load (if it’s possible), or use some caching on top or reduce a concurrency (unfortunately it will affect customers), not so wide choice, I’m agree.

@consumerbot797287

But instead of saying “works fine for me”, maybe you should see us as canaries in the coal mine?

Yes, this is why we have a forum to get a feedback. And I agree that “works fine for me” is not an answer, but it helps to get the missing information, like you provided above about using an USB 2,5" SMR disk. The worse case could be only to format it to BTRFS also and having only 1GB of total RAM like on Raspberry Pi3. My setup should mimic an average - Windows node, Docker for Windows nodes and I also have had a Pi3, but currently it’s not booting, an SD card is died and I have only remote access to that location.
So we are grateful for your feedback!

@consumerbot797287

But why not suggest avoiding SMR?

We suggesting this on the forum, and the possible workarounds. SMR disks can work, because not all SMR are made equally, and also if you have caching resources, it perhaps can work not worse than CMR.
We prefer to do not put limitations on hardware in our docs, each setup is individual. Thus we would try to give help on the forum.

@consumerbot797287

instead of relying on OOM killer. Interesting that you recommend this for RasPi.

the truth was that Pi just hangs otherwise, requiring a power recycling after that. So it’s better to kill the container and restart it, than switching off the grid. Especially if that is the remote location.

@consumerbot797287

but then blames SNOs when their hardware isn’t good enough to avoid encountering runaway software?

Oh, I’m sorry if you think that I mean that! We are not blaming, we states, that yes, storagenode can be run on many variations of the hardware, but if it’s not enough to run a node - then perhaps it cannot be used unfortunately.
I know that we have had nodes even on a router:

Running node on OpenWRT router?

Hi, I’m new here. I first tried storagenode on Windows 10. It was great but keeping my computer online all the time started to give me anxious and it was not optimal for a home compute. So I’ve decided to stop it for that time. Month later, I got the idea to give it a try on my router. I bought an external 2.5inch 5TB hard drive for that and my router is an WRT3200ACM where I suppose it’s far good enough for the job. My router is always on all the time unlike my computer. After that, I realized …

So, the low limits are truly low.