Chris investigating issues

AppleMiner avatar
AppleMiner
Archived posts: 715
Joined: Sep 30, 2017

Re: Chris investigating issues

by AppleMiner · · Post #12192

Need to check on it again, we havent processed a share in over 90 mins now, and I'm betting we dropped or didnt process some shares the other time the pool went down, was on target to be OK but then a slowdown and maybe some dropped shares when the pool died and needed to be reset? and if these 90 mins behind shares dont make it through they will need credited also.
Steve Sokolowski avatar
Steve Sokolowski
Archived posts: 4559
Joined: Aug 27, 2014

Re: Chris investigating issues

by Steve Sokolowski · · Post #12195

I determined what the cause of this problem is. There are locks on the balance tables that are causing other share inserters to wait for each other. This issue never occurred before, as it was always CPU-limited on the mining server. Chris is trying to see if something happened to the database server recently and will keep people updated.

No shares or money have been lost, and even if the server crashes, the separate processes will still insert the waiting shares.

He's restarting the database server now to see if doing so might fix something, as the first rule in any system is to restart.
Steve Sokolowski avatar
Steve Sokolowski
Archived posts: 4559
Joined: Aug 27, 2014

Re: Chris investigating issues

by Steve Sokolowski · · Post #12197

There was something wrong with the database server, which caused it to slow down so that transactions were always blocking each other. After Chris restarted the server, everything returned to normal. We weren't able to determine what was wrong with Postgres, other than that it hadn't been restarted in about 6 months.

Share corrections may be needed for today. Chris is probably going to have to go to sleep as soon as he verifies that everything is working fine, since he only slept 2 hours last night. He'll issue the corrections in the morning. Payouts will probably be delayed, but will still occur within the 24-hour promised window.

Until then, the "1MH/s expected payouts" chart is going to appear lower. Chris will correct it then. I apologize for his needing to sleep, and next week we will have more support once our expansion plans begin.
Last edited Tue Nov 21, 2017 03:09 AM UTC by Steve Sokolowski; edited 1 time(s).
AppleMiner avatar
AppleMiner
Archived posts: 715
Joined: Sep 30, 2017

Re: Chris investigating issues

by AppleMiner · · Post #12199

The profits for the day seemed to be going along nicely until just a bit after noonish and then they started sliding way way down, to like a third of normal or so for the 2nd part of the day. And I do not think the pool was down for 8hrs during 2nd half of the day today
Varashilo
Archived posts: 4
Joined: Nov 08, 2017

Re: Chris investigating issues

by Varashilo · · Post #12200

Steve Sokolowski wrote: No shares or money have been lost, and even if the server crashes, the separate processes will still insert the waiting shares.
Hi.
but a large portion of purchased power at nicehash is gone, what to do with it and whether assessed compensation for the lost shares?

I looked at the logs, and apparently PH is not taken into account shares from 22:30 till 23:50 Moscow time. There was about 30 orders for each spent around 0.005 btc for that period of time. Now what to do with it?
micca410evo
Archived posts: 112
Joined: Jul 26, 2017

Re: Chris investigating issues

by micca410evo · · Post #12206

skinner wrote:Some have gone again, if there are problems then a complete switch off is much better that intermittent on and off. My miners are in a commercial unit 25 minuets drive away and its 23:36 here. Would rather not have to go there and change the default pool again...

Just a thought, would it be possible to add a feature where the connection to prohashing could be rejected (dead) from the user interface on the website? A check box to add a number or letter (or both) to the username to make it invalid?
isn't a remote control server an option :roll: