Memory leak when restarting thread #106
Comments
|
Same issue here on Windows 10 |
|
Same here, it's systematically going lower and lower at each restart-inducing error, on two separate miners. Note that pressing CTRL-C, and manually restarting miner restores the memory to maximum. ==== ����������������������������������������������������������������ͻ ETH: 9 pools are specified AMD Cards available: 1 |
|
I'm starting to have this issue on all of my miners, did you guys find a workaround? |
|
I'm having same problem. Manually relaunching miner does restore memory to max.. but only runs for a few hours at best... Running 3 ASUS RX 570 ROG Strix OC with 1112 cclock and 2000 mclock; in total rig only pulling 420W so don't think this is thermal. Running Xubuntu and Claymore V10 Glad I'm not alone.. sad there doesn't seem to be a fix at the moment. |
|
I've found a workaround. My workaround is to use the -r 1 option, forcing Claymore to close. You can reboot if you wish. I invoke claymore in a bash script with a forever loop, forcing it to restart on closure. |
|
Yes, killing and restarting the process resolves the issue temporarily as the kernel frees the memory once the PID no longer needs it. However this is not a viable long-term solution as it doesn't effectively mitigate the memory leak when creating the new process. In order to resolve the memory leak problem, when the code enters a failed state, it should exit with a non-0 return value. This is standard procedure for applications that enter unrecoverable failed states. Although in my particular case the memory leak is recoverable, in other situations where the GPU is unresponsive it may not be recoverable. As such, if the situations are not capable of being handled independently, then they should be handled as the worst-case scenario (unresponsive hardware). The non-0 return value also allows the parent process (e.g. a script) to effectively handle the failure itself. |
|
Do you guys mine only eth by chance? we are having the same problem (available memory decreasing over time until i can't assign dag file). |
|
Yes ETH only... tbh switched to ethOS with exact same settings and it ran faster and completely stable... this was about two weeks ago and it's still stable on ethOS getting ready to add a couple more cards |
|
I am mining ETH only, but I suspect the leak persists across dual mining as well since it appears to be related to how ETH-mining threads are killed. It sure would be nice if @nanopool would show up in this thread. This bug should be fixable with a simple destructor update for the thread class. |
|
I have this problem on EthOS as well. |
|
Increase virtual memory to match memory of ALL cards. I have 8x 4gb and 1 8gb. Virtual memory = 40GB ( set at 45gb for Windows program cache). This worked :) |
|
This is not a virtual memory related issue, the best could be a driver or memory errors clogging up with time. Sometimes this occurs immediately after restarting a miner, and other times it takes one or two days for it to shit the bed. |
|
Have any tried the fix and repeated the error? Also, make sure you DON’T all “lock pages in memory” under group policy. This cause tons of problem across mining all kinds of coins... |
|
My fix is to prevent the hanging and restarting in the first place.. |
|
The same problem here with ETHOS Any HELP ? |
|
only way we found on ethos is to remove the dev fee with |
|
Where to type this line ? |
|
in either your local or remote config file. |
|
so after adding the line what will happen ? |
|
Going to attempt this now with fresh ethOS images; are we sure it's not supposed to be in claymore.stub.conf? |
|
this is my old config |
|
the line says, claymore only flags = (reboot 1 if crash) and (no fee to dev). the problem is that the dev fee pool keep disconnecting. that's why the memory does not get flushed. |
|
keep the regular flags line |
|
so it should be like this "flags -r 1 -nofee" or "claymore=flags -r 1 -nofee" |
|
claymore=flags -r 1 -nofee |
|
globaldriver amdgpu |
|
is this good configuration ? |
|
maxgputemp 90 #ETH POOL that's mine |
|
imperialgames: I had been running with -allpools 1 but am going to try taking that out... also had been leaving -allcoins 1 out as well... not sure if it'll help but we'll see |
|
So is there anyway to mine etherum without claymore ? |
|
Yup, Etherminer.... slower but honestly slow and steady may just win the race |
|
Dears i found something strange however i changed the user name and password of ethos however i found strange commands have been typed in the shell the followed link has been added to my pc and scripts from it ran to my system https://github.com/pooler/cpuminer do this mean that iam hacked hhhhh |
|
ETH+LBRY how to dual mine ? what to type in claymore.stub.conf ? |
|
Check the settings i posted above you do it in the local or remote.conf |
|
so what about the claymore.stub.conf ? |
|
You dont have to touch it |
|
imperialgames what is the default for claymore.stub.conf ? |
First reported here: https://www.reddit.com/r/EtherMining/comments/6yfqxg/not_enough_gpu_memory_to_place_dag_you_cannot/
When a pool connection fails, we see an error in STDOUT that the miner thread is hanging and needs to be restarted. The thread is then restarted successfully, but without reinitializing the VRAM, as shown below (ellipsized for brevity):
This same card at first initialization is detected with 8169 MB available.
Hardware:
https://pcpartpicker.com/list/f6Cyhq
Version:
0ebb105bd3a6cdd35d94663eabf245e9 Claymore.s.Dual.Ethereum.Decred_Siacoin_Lbry_Pascal.AMD.NVIDIA.GPU.Miner.v9.8.-.LINUX.tar.gza919e303d2250f2719c7a28bfebd9a79 ethdcrminer64Drivers:
AMDGPU-PRO Driver Version 17.30 for Ubuntu 16.04.3
OS:
Ubuntu 16.04.3 LTS
The text was updated successfully, but these errors were encountered: