Phoenix Miner - memory leak (pool dependent)

[qdot]

Hi!

I think I've found something that resembles a memory leak in phoenix-1.48.

I know it's not the most recent version of phoenix, but it's the one I have cooked now - people on forum seem to be complaining about it:

http://forum.bitcoin.org/index.php?topic=6458.600

So, the leak seems to be affected by the choice of the pool - which means it's unlikely something to do with the AMD SDK version (11.4 here).

Code:

root@node02:~# ps aux | grep phoenix                                                                                                                                                                               
root       368  0.6 13.6 411212 138972 pts/7   Ssl+ Jul02  12:53 /usr/bin/python ./phoenix.py -v -u http://qdot_nodeB3:supersecret@btcguild.com:8332/ -v -k phatk DEVICE=2 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32556  0.3  7.3 355028 74920 pts/4    Ssl+ Jul02   7:22 /usr/bin/python ./phoenix.py -v -u http://qdot.node2_1:supersecret@api.bitcoin.cz:8332/ -v -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32628  0.4  7.4 354804 76144 pts/5    Ssl+ Jul02   9:27 /usr/bin/python ./phoenix.py -v -u http://qdot.node2_2:supersecret@api.bitcoin.cz:8332/ -v -k phatk DEVICE=1 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32661  0.4  7.4 354804 75744 pts/6    Ssl+ Jul02   9:55 /usr/bin/python ./phoenix.py -v -u http://qdot.node2_3:supersecret@api.bitcoin.cz:8332/ -v -k phatk DEVICE=2 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32703  0.4 12.0 419708 123136 pts/9   Ssl+ Jul02   9:30 /usr/bin/python ./phoenix.py -v -u http://qdot_nodeB1:supersecret@btcguild.com:8332/ -v -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128
root     32752  0.6 13.4 424524 137260 pts/8   Ssl+ Jul02  12:31 /usr/bin/python ./phoenix.py -v -u http://qdot_nodeB2:supersecret@btcguild.com:8332/ -v -k phatk DEVICE=1 VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128

As you can see, it only leeks on btcguild - for some reason slush's pool keeps the miners immune from this issue.. any differences between the two?

[1715169832]

1715169832

[1715169832]

1715169832

[PcChip]

I use BTCGuild exclusively, and have been having the problem that when a fresh phoenix is started, the GPU usage is a straight 99% line, but over several days it turns into a sine wave from 90% - 99% , which means the GPU's are not being fully used.

Could this be related?

[sang]

I use BTCGuild exclusively, and have been having the problem that when a fresh phoenix is started, the GPU usage is a straight 99% line, but over several days it turns into a sine wave from 90% - 99% , which means the GPU's are not being fully used.

Could this be related?

Been having this issue also.

[qdot]

I use BTCGuild exclusively, and have been having the problem that when a fresh phoenix is started, the GPU usage is a straight 99% line, but over several days it turns into a sine wave from 90% - 99% , which means the GPU's are not being fully used.

Could this be related?

It could be either that or the GPU overheating and running some form of load reduction. I've seen both effects.

You can most easily test it by switching to a different pool, or by monitoring the GPU temperature and clocks. Basically, when the GPU overheats, it clocks down.

On the other hand, mining on a machine with some swap memory (paging file) could cause the same effect due to leaks - on my miners it just gets the system to kill the leaking worker, with no leak related slowdown - but that's because my miners have very little RAM, and no swap memory.

 

[jwzguy]

I use BTCGuild exclusively, and have been having the problem that when a fresh phoenix is started, the GPU usage is a straight 99% line, but over several days it turns into a sine wave from 90% - 99% , which means the GPU's are not being fully used.

Could this be related?

It could be either that or the GPU overheating and running some form of load reduction. I've seen both effects.

This doesn't seem to be the case.

I'm having the same thing happen. I'm running phoenix 1.50+ phatk, with BTCguild. I start out with a perfect steady 99% for many hours. Then over 1-2 days, the usage gets very unstable, bouncing between 96-98%. A restart (no real rest time) immediately fixes the problem.

If it was overheating, then a stop/restart with no other changes, and a fraction of a second pause wouldn't completely erase the problem for hours to come.

[TheSeven]

As you can see, it only leeks on btcguild - for some reason slush's pool keeps the miners immune from this issue.. any differences between the two?

The most obvious difference between the two is that btcguild supports long polling while slush doesn't...

[elitak]

I'm having the same thing happen. I'm running phoenix 1.50+ phatk, with BTCguild. I start out with a perfect steady 99% for many hours. Then over 1-2 days, the usage gets very unstable, bouncing between 96-98%. A restart (no real rest time) immediately fixes the problem.

If it was overheating, then a stop/restart with no other changes, and a fraction of a second pause wouldn't completely erase the problem for hours to come.

That sounds very much like the miner process is leaking memory. Your throughput percentage begins to drop as the OS begins swapping more and more virtual memory to/from disk while the process tries to push work to the GPU. My recommendation is to just restart every miner daily, if that's feasible.

I suspect that the mem leak is being caused by twisted. I've used it before and I had horrible leakage. It takes a lot of care and attention to avoid. I'd like to file & track a bug for it. Is there a page for the phoenix-miner project to do that?

[PcChip]

I found a fix to my sine-wave load usage problem, or at least cut it in half - set both phoenix.exe's to "Below Normal" process priority.  

I know it's counter-intuative, but trust me.


If you want to use it in your batch file, do this:

start /belownormal phoenix.exe <arguments>




To the OP: Sorry I kinda derailed your thread amigo 

[c00w]

I don't think the memory leak is caused by twisted. I wrote a proxy hopper using it and it doesn't leak although it is doing roughly the same operation.

Over a couple days my hoppers memory is constant while phoenix's will increase.