Server overload plans

[Steve Sokolowski]

You need more servers, thats the real answer. A master and slave arrangement for the SQL, where you can have even numbered clients hitting server X, odd's hitting Y and the master Z is the one to whom they all update and the one from which all important decisions and calculations are made with the caveat that it will be slightly out of date.

Another option would be just getting rid of the SQL as the primary storage method in favor of a more spartan approach. If you really just need hashes, there are easier ways to do it. You could use a filesystem model which is very robust and simple and much faster with less overhead.

Then you can do an operation to create the SQL periodically from a snapshot of the filesystem for your reporting purposes that is not a bottleneck on the main mining operation.

I don't have time to talk in detail about this now, but hardware is rarely a permanent or long-term solution. Even if we ordered hardware, it wouldn't be available for a week because the server-grade hardware we need isn't the kind of stuff you buy in a store. Plus, it just postpones how long it will be until we need to make the software upgrades that are going to be necessary to support the SHA-256 load.

Like most of these issues, they need to be solved in software, not hardware. Fortunately, we are storing unnecessary data and if we delete it and stop storing it, we should be able to significantly improve performance.

[tmopar]

You need more servers, thats the real answer. A master and slave arrangement for the SQL, where you can have even numbered clients hitting server X, odd's hitting Y and the master Z is the one to whom they all update and the one from which all important decisions and calculations are made with the caveat that it will be slightly out of date.

Another option would be just getting rid of the SQL as the primary storage method in favor of a more spartan approach. If you really just need hashes, there are easier ways to do it. You could use a filesystem model which is very robust and simple and much faster with less overhead.

Then you can do an operation to create the SQL periodically from a snapshot of the filesystem for your reporting purposes that is not a bottleneck on the main mining operation.

I don't have time to talk in detail about this now, but hardware is rarely a permanent or long-term solution. Even if we ordered hardware, it wouldn't be available for a week because the server-grade hardware we need isn't the kind of stuff you buy in a store. Plus, it just postpones how long it will be until we need to make the software upgrades that are going to be necessary to support the SHA-256 load.

Like most of these issues, they need to be solved in software, not hardware. Fortunately, we are storing unnecessary data and if we delete it and stop storing it, we should be able to significantly improve performance.

I agree with you on the software. If you drop the SQL as the primary storage mechanism that would simplify everything greatly. I know it seems unorthodox but file systems were how things were done in the past and still works well today with basic tools.

To the point of hardware, machines become faster every year, and older faster machines become cheaper every year. Even if you do everything you can in software, in a year, it will be faster just by buying the latest and greatest.

The good thing about hardware is you can buy it and stack it and resell it one day too.

[n00bminer]

Can you tell us what the pool's minimum, maximum, and starting difficulties are now?

[Steve Sokolowski]

Can you tell us what the pool's minimum, maximum, and starting difficulties are now?

2^10, 2^14, and 2^20. For x11, divide by 2^16 for each of those.

We will lower the minimum difficulty again once we improve capacity. The starting difficulty will stay the same because it turns out that NiceHash prefers that starting difficulty.

[sirslayerjr]

an ideal database server should have a high core count with numa enable!!