Open notlesh opened 6 years ago
Spudz76
commented
6 years ago There were a whole ton of oom-killer patches between 4.8 and 4.18, while you are running 4.15 (may have issues)
It was pretty broken around that version, either downgrade (probably best) or upgrade (might not work with maximum 17.50 drivers required by xmr-stak...)
I see you are using ethos so, I'm sorry. It's probably tough to jack the kernel around.
Spudz76
commented
6 years ago Just to clarify, it is not killing things because you're ""actually"" out of memory at all, it is just freaking out because bugs.
Some similar problem seen here
I run linux-image-4.4.0-134-generic on most Ubuntu based rigs it works good with all mining. I don't know if EthOS is Ubuntu based maybe you can wedge in that old kernel.
Spudz76
commented
6 years ago For fun, sample output of free -h from a rig on 4.4.x kernel... with all kinds of miners running. It doesn't need more than 4GB if even that much.
total used free shared buff/cache available
Mem: 7.7G 1.1G 846M 114M 5.8G 6.1G
Swap: 3.7G 5.0M 3.7G
notlesh
commented
6 years ago @Spudz76 Thanks for the quick reply. An OOM-killer that operates on false positives is a scary thing :)
I did see memory usage spike very quickly leading up to the OOM event (as observed with htop on a fast update cycle). It also refused to use any swap, it would seem. So it indeed must have been pretty broken.
I may be stuck with an old kernel until I feel like moving away from ethos...
In trying to allocate multiple CPU-side threads for my miners, I'm finding that xmr-stak will cause too much memory allocation, which in turn causes the Linux kernel to OOM-kill the process. I suspect this could be worked around by staggering any memory-intensive operations, as the steady-state memory usage is quite low. If this isn't the case, then perhaps it could handle this more gracefully.
This problem is consistent across multiple rigs. Some rigs have 4GB RAM, some have 8GB. The 8GB rigs can accommodate more CPU-side threads than the 4GB rigs.
Some info about my setup(s):
Compiled master / dev branches - same result. In one case, I can run up to 7 CPU-side threads with this config:
Notice 2 threads with index: 5. (For the record, this gets me from about 750 to 1050 H/s on a RX580). If I try to do the same with any other GPU (e.g. 2 threads for GPU index=4), I begin running into the memory problem.
Output looks like this:
And the kernel complains:
Assuming I'm not making any big mistakes, would it be possible to stagger any large memory allocations so that it would be possible to run more CPU-side threads on rigs with small amounts of RAM?
I'm happy to dig into this, especially if I can get a couple pointers as to what is actually allocating so much memory.