Open bloodxia opened 6 years ago
I get this often too, any fix?
Just ran into the same issue
I'm adding the line ThreadPool.SetMinThreads(Environment.ProcessorCount, 300); to Program.cs to see if it resolves the issue.
Did this solve it?
I'm testing it now with a single ASIC miner. As of this moment it resolved the issue. I'll add a few more tomorrow and let everyone know. Ideally the number 300 would be a configuration variable. With a default value of around 200.
@bonesoul Would adding a optional config variable to config.json named MinIOThreads with a default value if absent of 200 be an acceptable solution?
So here's what I did that seems to have helped greatly in reducing timeout errors.
Ideally these options would be passed in via the config.
ThreadPool.SetMaxThreads(Environment.ProcessorCount * 8, 1024);
Ideally these values would be passed in via the config.
Follow the recomendations at the top of the redis.conf regarding increasing the max somaxconn
The default is 4 I set it to 64 which resolved the issue.
Completely removing the dependency on Redis would probably be worthwhile.
Hi, what lines did you add the additional lines too?
The line number doesn't matter. Just put in some place in the main method. After line #57 would be a good place.
and is that the same for connectTimeout=30000,keepAlive=60,syncTimeout=5000,version=2.6? as I put it in the brackets? so far it has not resolved the issue
and it is redisclient.cs found here /CoiniumServ/Persistance/Providers/Redis?
it still shows (Busy=0,Free=200,Min=6,Max=200), WORKER: (Busy=600,Free=0,Min=6,Max=600) by any chance does anyone know how to change the values?
ye that's right then, still no luck... does this help resolve anything https://github.com/uliian/StackExchange.Redis.Pool?
If you can afford to run asic miners you should probably hire a developer to make some changes to coinium for you. It's current design does not scale well and is inherently unstable. Ideally the dependence on redis would be eliminated and each pool would run in a separate process independent of the web interface. The current architecture crashes often and when one processes crashes it brings down everything else.
You need to enable every possible performance related option in the redis config and run on dedicated hardware. In my opinion getting this running properly with ASIC miners will have significant costs in both hardware and necessary modifications to the software. The issues related to the current design are significant.
the miners are a mate of mine, I'm setting the pool up for him on my server .. just when he attaches just one miner that's the error we get, yet works well with standard non miner connections ... I am struggling to see why attaching the miner is maxing everything out, when surely Coinium was designed with such instances in mind? the server is 30gb ram 6cpu and 3tb so should be more than enough
I'm telling you that it can't handle modern ASIC miners without a significant amount of work. I've actually spent the time on getting this up and running with ASIC miners pointed at it and If you're not a developer and familiar with configuring redis for performance you're not going to have much luck getting this working. Once you dive into the code you'll soon discover the inherent design issues. Given the current architecture this pool will never scale beyond 50 -100 ASIC miners and even then it will not be stable.
if that's the case whats recommendations for pool software that will handle proper mining as this so far cant even handle one miner
I have just spoke to my mate it isn't even his asic attached its a self built with 6 R9 graphic cards attached :/
You likely just need to configure redis properly in that case.
here is the redis.conf ... can you see where I am going wrong?
#
#
#
#
################################## INCLUDES ###################################
#
#
#
################################## NETWORK #####################################
#
#
#
#
bind 127.0.0.1
#
#
#
#
protected-mode yes
port 6379
#
tcp-backlog 4069
#
#
timeout 0
#
#
#
#
tcp-keepalive 300
################################# GENERAL #####################################
daemonize no
supervised no
#
#
pidfile /var/run/redis_6888.pid
loglevel notice
logfile /var/log/redis/redis.log
databases 16
################################ SNAPSHOTTING ################################ #
#
#
#
#
#
#
save 900 1 save 300 10 save 60 10000
#
#
stop-writes-on-bgsave-error yes
rdbcompression yes
#
rdbchecksum yes
dbfilename poolsredis.rdb
#
#
#
dir /var/lib/redis
################################# REPLICATION #################################
#
#
#
#
#
# slave-serve-stale-data yes
#
#
slave-read-only yes
#
#
#
#
#
#
repl-diskless-sync no
#
#
repl-diskless-sync-delay 5
#
#
#
#
#
#
#
repl-disable-tcp-nodelay no
#
#
#
#
#
#
#
#
slave-priority 100
#
#
#
#
#
#
#
#
#
#
#
#
#
################################## SECURITY ###################################
#
#
# requirepass password
#
#
#
#
#
#
################################### LIMITS ####################################
#
# maxclients 10000
#
#
#
#
#
#
#
#
#
#
#
# maxmemory-samples 8
############################## APPEND ONLY MODE ###############################
#
#
#
appendonly no
appendfilename "appendonly.aof"
#
#
#
#
#
appendfsync everysec
#
#
#
no-appendfsync-on-rewrite no
#
#
#
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 1gb
#
#
#
aof-load-truncated yes
################################ LUA SCRIPTING ###############################
#
#
#
lua-time-limit 5000
################################ REDIS CLUSTER ############################### #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
################################## SLOW LOG ###################################
#
slowlog-log-slower-than 1000000
slowlog-max-len 128
################################ LATENCY MONITOR ##############################
#
#
#
latency-monitor-threshold 0
############################# EVENT NOTIFICATION ##############################
#
#
#
#
#
#
#
#
#
#
notify-keyspace-events ""
############################### ADVANCED CONFIG ###############################
hash-max-ziplist-entries 1024 hash-max-ziplist-value 512
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 1024
zset-max-ziplist-entries 512 zset-max-ziplist-value 128
#
#
hll-sparse-max-bytes 10000
#
#
#
activerehashing yes
#
#
#
#
#
#
#
#
client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60
#
#
#
hz 30
aof-rewrite-incremental-fsync yes
To start with disable write to disk and compression.
Ideally the redis dependency would be completely removed.
i understand but bonesoul has stated the redis is required for Coinium to work ... by any chance have you had Coinium working with stackexchange 1.2.6 ?
our current storage layer uses mysql + redis together; https://github.com/bonesoul/CoiniumServ/tree/develop/src/CoiniumServ/Persistance/Layers/Hybrid
though a new layer could just use mysql. just need a similar implementation like above.
I have followed the recommendations as above but this has had no resolve... how easy would it be to remove the redis dependency?
I looked into this for a client and determined that it was more work than it was worth doing given the other issues that I've mentioned with the architecture. There is a lot of good code in this project that could be borrowed but there are also significant issues that it would take several weeks of dedicated development to resolve. I estimated that it would take around 450 hours of additional development in order to make the modifications necessary to use Coiniumser as the basis for a publicly facing pool that would support 1000 or more dedicated ASIC miners.
@BenKnigge the thing is that while I developed CoiniumServ like 4 years ago, Bitcoin was the major blockchain with only copy-cat shitcoins.
Now as of 2018, there is cryptonote - monero, ethereum and a bunch other significant major blockchains and from my previous analysis, it's impossible for CoiniumServ to handle them with it's current code architecture.
Most of the bugs are reported by people trying to use it non bitcoin-complaint blockchains. Anyway some time ago i've started working on a new architecture that can support monero, bitcoin, ethereum and so, but it'll take some time to get it production ready as these days i lack the time for it.
@bonesoul You've done a tremendous amount of work on this project and I've actually gotten it working for bitcoin mining with a few asic miners pointed at it. This project has saved me hundreds of hours of development time. It isn't however a plug and play solution for a large scale private mining pool that some people seem to believe it is. There is a significant amount of work required just to get this up and running reliably for a pool with just a few dedicated asic miners mining bitcoin. It seems like there are quite a few people under the impression that they can just do a git clone, compile, and that everything will be up an running with minimal effort on their part which isn't the case.
Yea you are correct. At the time i developed this i have been running 10-15 shitcoin pools with it. In that period bitcoin was the only major blockchain project. And lots changed in the following years.
Hopefully https://github.com/bonesoul/hypepool will be more user friendly.
I use ASIC Miner,can report some error. Log: An exception occured while comitting share: Timeout performing HINCRBYFLOAT deeponion:shares:round:current, inst: 22, queue: 7, qu: 0, qs: 7, qc: 0, wr: 0, wq: 0, in: 133, ar: 0, clientName: , serverEndpoint: 127.0.0.1:6379, keyHashSlot: 15286, IOCP: (Busy=0,Free=200,Min=4,Max=200), WORKER: (Busy=33,Free=367,Min=4,Max=400) (Please take a look at this article for some common client-side issues that can cause timeouts: http://stackexchange.github.io/StackExchange.Redis/Timeouts)
It's StackExchange.Redis bug.
If use ASIC Miner.100% has this bug. can use https://github.com/uliian/StackExchange.Redis.Pool replace StackExchange.Redis?