- Great news! Because of how so many customers have asked for two factor authentication, I told Michael I would give him a PS4 - but only if it was done before Monday. He accepted and therefore it's very likely that this option will be available to customers next week.
- Chris corrected balances for yesterday. Thanks for your patience. While customers were paid what they were owed, we lost money because the price of ETH rose between the time the money was promised and when we did the corrections. This goes back to how the worst situation for us is in times of altcoin bubbles, but ETH users should consider this their good fortune.
- I'm investigating something that happens at 6:00am that causes delayed shares at that time. It can't be payouts anymore, because we fixed that. If it's the daily VACUUM task, there isn't much we can do about it. I'll post more once I know the answer.
- This weekend, I will be improving the site to better handle delayed shares, as part of our three-week period of bugfixes and stability improvements. There will be a new "timestamp" field added to the types of live data which can be delayed. The API will remain backwards compatible, but users who pay attention to the "timestamps" can be assured that the profitability data hasn't been delayed when making rental or pool switching choices. We will never be able to completely eliminate delayed shares, but we will aim to provide better options for customers during those periods.
Status as of Saturday, June 3, 2017
Forum rules
The Development forum is for discussion of development releases of Prohashing and for feedback on the site, requests for features, etc.
While we can't promise we will be able to implement every feature request, we will give them each due consideration and do our best with the resources and staffing we have available.
For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
The Development forum is for discussion of development releases of Prohashing and for feedback on the site, requests for features, etc.
While we can't promise we will be able to implement every feature request, we will give them each due consideration and do our best with the resources and staffing we have available.
For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Status as of Saturday, June 3, 2017
Good morning!
Re: Status as of Saturday, June 3, 2017
Indeed a batch of great news!
Re: Status as of Saturday, June 3, 2017
" It can't be payouts anymore, because we fixed that. If it's the daily VACUUM task, there isn't much we can do about it. I'll post more once I know the answer."
If its the locking due to the payouts, then locking is the true enemy. This must be proven via data one way or the other otherwise you are fighting the wrong enemy.
I used MySQL and MSSQL for years and so I am familiar with these kinds of maintenance operations.
The only way you really need to run these is if your transaction IDs wrap around. If you have a 64bit unsigned integer you should be fine I would think but then again there are lots and lots of shares.
If you are not experiencing this phenomena and the performance is otherwise acceptable without running it daily then perhaps you could run it once a week thereby decreasing its impact considerably.
>>>>>
I thought of something else after the original post... assuming you do the testing and its not the locking during the payout and REALLY is the vacuum task, and the vacuum task must REALLY be ran every day, why not spawn it separate with a really high nice and low priority.
This would still enable it to run daily but only when things are progressing at a pace where it wont be noticed even if it is drawn out over most of the day.
If its the locking due to the payouts, then locking is the true enemy. This must be proven via data one way or the other otherwise you are fighting the wrong enemy.
I used MySQL and MSSQL for years and so I am familiar with these kinds of maintenance operations.
The only way you really need to run these is if your transaction IDs wrap around. If you have a 64bit unsigned integer you should be fine I would think but then again there are lots and lots of shares.
If you are not experiencing this phenomena and the performance is otherwise acceptable without running it daily then perhaps you could run it once a week thereby decreasing its impact considerably.
>>>>>
I thought of something else after the original post... assuming you do the testing and its not the locking during the payout and REALLY is the vacuum task, and the vacuum task must REALLY be ran every day, why not spawn it separate with a really high nice and low priority.
This would still enable it to run daily but only when things are progressing at a pace where it wont be noticed even if it is drawn out over most of the day.
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Status as of Saturday, June 3, 2017
The payouts don't lock anymore, so it can't be that.tmopar wrote:" It can't be payouts anymore, because we fixed that. If it's the daily VACUUM task, there isn't much we can do about it. I'll post more once I know the answer."
If its the locking due to the payouts, then locking is the true enemy. This must be proven via data one way or the other otherwise you are fighting the wrong enemy.
I used MySQL and MSSQL for years and so I am familiar with these kinds of maintenance operations.
The only way you really need to run these is if your transaction IDs wrap around. If you have a 64bit unsigned integer you should be fine I would think but then again there are lots and lots of shares.
If you are not experiencing this phenomena and the performance is otherwise acceptable without running it daily then perhaps you could run it once a week thereby decreasing its impact considerably.
>>>>>
I thought of something else after the original post... assuming you do the testing and its not the locking during the payout and REALLY is the vacuum task, and the vacuum task must REALLY be ran every day, why not spawn it separate with a really high nice and low priority.
This would still enable it to run daily but only when things are progressing at a pace where it wont be noticed even if it is drawn out over most of the day.
The vacuum task has to run because otherwise the disks would become full. Disk space is critical on the server because we aren't able to vacuum full the tables, due to it locking up the system for hours. The disk is full of trash rows and that's causing us to have to run this every day.
We recently made changes to store a lot less data on shares, which if we were ever able to vacuum full the tables would allow them to shrink to 1/10 of their current size, eliminating the need for daily vacuum operations.