Prohashing Mining Pool Forums

Good morning!

• 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.

Indeed a batch of great news!

" 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.

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 payouts don't lock anymore, so it can't be that.

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.