Topic: pushpool - open source pool software - page 5. (Read 120158 times)
Anyone got it to compile on freebsd yet? Any pointers?
Modifiy ulimit -n
I've been running pushpoold on my box for sometime and about every 12 hours of running or so it begins to error the error log says WARN too many open files anyone else run into any similar issues?
Please check my fork of pushpool for modified example-config and example db:
https://github.com/jine/pushpool
Regards, Jim
https://github.com/jine/pushpool
Regards, Jim
I changed you insert to delayed inserts
Umm, I can't recall for sure, but I'm 99% positive it needs to be restarted when PP is restarted and gets a new PID.
blkmond will close those. It's not a great design decision that it requires blckmond to close the tcp due to the SIG USR1 it receives when there's an LP. If blkmond fails you will eventually have too many open connections.
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?
blkmond will close those. It's not a great design decision that it requires blckmond to close the tcp due to the SIG USR1 it receives when there's an LP. If blkmond fails you will eventually have too many open connections.
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?
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?
question:does pushpool work with the namecoin chain ?
yes it does, just interface with namecoind rpc
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...)
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...)
Is it possible to set up a local server to connect to an existing pool? I'll then connect my miners to the local server, Dial up is a bitch...
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 in /proc/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.
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 in /proc/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.
thanks davout, i'll give that a try
Hi, is it possible that even if upstream_result is Y, that it's an invalid share?
I have such a case, that upstream_result is Y but nothing shows up in listtransactions :/
I suggest to not rely on listtransactions to monitor generated blocks.I have such a case, that upstream_result is Y but nothing shows up in listtransactions :/
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
Hi, is it possible that even if upstream_result is Y, that it's an invalid share?
I have such a case, that upstream_result is Y but nothing shows up in listtransactions :/
I have such a case, that upstream_result is Y but nothing shows up in listtransactions :/
question:does pushpool work with the namecoin chain ?
To clarify; the standard error logging option (-E) is broken in 0.5 Trivial fix is submitted as a pull request: https://github.com/jgarzik/pushpool/pull/27
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.
Ius has a fix, I think it's been pushed to github but I'm not 100% sure.
Version 0.5 released.
Changes:
Jeff Garzik (2):
applog: fix memory leak; check asprintf() return value
Version 0.5.
Joerie de Gram (1):
Make ntime rolling support configurable
Luke Dashjr (1):
Bugfix: libraries must be in LDADD, not LDFLAGS
MtRed (1):
memcached_get & memcached_set key length is off by 1. Double null make get
Shane Wegner (1):
Output times on STDERR in human readable format.
Changes:
Jeff Garzik (2):
applog: fix memory leak; check asprintf() return value
Version 0.5.
Joerie de Gram (1):
Make ntime rolling support configurable
Luke Dashjr (1):
Bugfix: libraries must be in LDADD, not LDFLAGS
MtRed (1):
memcached_get & memcached_set key length is off by 1. Double null make get
Shane Wegner (1):
Output times on STDERR in human readable format.
for example, multiple pushpools and multiple bitcoind? multiple pushpools and one bitcoind? other?
Multiple pushpoold's and multiple bitcoind's. The only question is about database scaling...
Jump to: