Bitcoin Forum
November 06, 2024, 09:52:51 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Phoenix Miner - memory leak (pool dependent)  (Read 3908 times)
qdot (OP)
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
July 03, 2011, 08:34:28 PM
 #1

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?
PcChip
Sr. Member
****
Offline Offline

Activity: 418
Merit: 250


View Profile
July 04, 2011, 01:01:54 AM
 #2

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?

Legacy signature from 2011: 
All rates with Phoenix 1.50 / PhatK
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
sang
Sr. Member
****
Offline Offline

Activity: 282
Merit: 250


View Profile
July 04, 2011, 02:06:49 AM
 #3

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 (OP)
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
July 04, 2011, 04:43:29 AM
 #4

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
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1002



View Profile
July 04, 2011, 09:28:16 PM
 #5

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
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500


FPGA Mining LLC


View Profile WWW
July 04, 2011, 11:12:06 PM
 #6

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...

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
elitak
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
July 13, 2011, 09:27:51 PM
 #7

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
Sr. Member
****
Offline Offline

Activity: 418
Merit: 250


View Profile
July 14, 2011, 09:13:20 PM
 #8

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  Undecided

Legacy signature from 2011: 
All rates with Phoenix 1.50 / PhatK
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
c00w
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
July 29, 2011, 04:41:00 AM
 #9

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.

1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!