Just to warn you that the 0.5 build in the .tar.gz file doesn't work correctly.

Ius has a fix, I think it's been pushed to github but I'm not 100% sure.

question:does pushpool work with the namecoin chain ?

I suggest to not rely on listtransactions to monitor generated blocks.

The approach I use is the following :
 - track shares with upstream_result = 'Y'
 - calculate block hash directly from the share result (block header)
 - use the getblockbyhash RPC call to do the tracking and validate there's actually a block that has been generated

I think it's a much cleaner approach

Just to help anybody out there who is struggling with pushpool scaling like BTC Guild has:

The major bottleneck that you'll run into assuming your hardware is good is going to be the communications between bitcoind and pushpoold.  Every getwork and sendresult request is opening a new local socket for the communication, eventually running the server out of open sockets due to a huge number of TIME_WAITs.  Around 300-400 GH/sec, depending on the server TCP settings, you will hit a point where there are no ports available to open a new local socket.

Changing your servers tcp settings inproc/sys/net/ipv4/ to the following can help, but its only a bandaid fix, you'll still run into issues:
  tcp_fin_timeout   - Changing this to a much lower value, such as 5.
  ip_local_port_range  -  Changing this to a setting such as 10000 65000

My C/C++ skills for networking are pretty rusty, so I haven't yet been able to come up with a fix to get pushpoold/bitcoind to reuse sockets rather than open new ones yet.

more or less replying to eleuthria:

before I've updated to 0.5 I didn't have problems with the connections. But since I've updated, I'm running into these problems (With about the same GHash rate...)

Hi all,

I have no problem with TIME_WAITs at the moment. But I have a massive problem with CLOSE_WAITs from pushpoold:



If I restart pushpoold they vanish. I never saw the amount decreasing during normal operations. I'm using the current git Version. Does anybody know how to mitigate this issue?

Thank you for your answer. This explains a bit BTW I have blkmond running by fire and forget. I just start it with the configuration file as parameter and send it to the background using the job control, pipeing its output to the bit bucket. Is this the correct usage? I feel it should be a daemon which need to be restartet every time pushpoold is restartet (as it need to know the new PID)?! Or is it reading the PID from the file each loop?  However embedding it into a init-Skript is not that easy (due to the output) und thus I feel it is not intended to be startet as deamon. Am I right?

I changed you insert to delayed inserts

Modifiy ulimit -n