- We had three objectives during last night's brief downtime. We successfully accomplished one: releasing an upgrade to the trading engine so that it consumes less bandwidth and performs faster. The upgrade also corrected a long-standing bug that we hadn't recognized that caused incorrect pricing from Bittrex.
- We were not able to accomplish the other two objectives. We reverted the mining server upgrades, which would have reduced database writes and added additional pricing error conditions, because they caused a query to fail. We will investigate the query and try again with these tonight.
- The final objective was to restart the hypervisor to install the official LSI MegaRAID driver, which we believe will improve performance over the generic default Debian driver. We decided not to perform the restart because we wanted to spend more time working on the other two objectives.
- I was able to improve performance on Monday night by deleting unnecessary indexes on tables like shares, which contain close to 1b rows. That results in fewer writes when new rows are inserted. In a database that writes a lot of data that is never read again like this one, indexes are not desirable.
- The block explorer seems to be getting more and more complete every day. The indexer script seems to fully scan three or so blockchains a day, so more and more of the coins have data on the "explorer" page now. Chris has begun advertising the explorers for the coins that are fully indexed.
Status as of Wednesday, June 10
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 Wednesday, June 10
Here's today's status. Since it's the middle of the week, there isn't much work to report since Monday.
Re: Status as of Wednesday, June 10
Just an thought, but Western Digital Purple drives are supposd to be designed for the kind of load you're talking about; lots of writes and very few reads. They're _meant_ for digital surveillance systems, but it sounds like the demands would be pretty similar to the share tables. Might be that they'd work a bit better for that particular task?
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Status as of Wednesday, June 10
We looked at such drives, but I don't think they will be necessary. The performance we can gain through software optimization has already far exceeded the gains we could achieve from hardware. I estimate we have cut the number of writes the database is performing by half. The only reason we haven't done better is because the weekend hasn't arrived yet.
I think we can get the writes down to 10% of what they used to be pretty easily. The only reason there are so many writes is because we never paid attention to software optimization until now, since it wasn't a problem until we started indexing this block explorer.
I think we can get the writes down to 10% of what they used to be pretty easily. The only reason there are so many writes is because we never paid attention to software optimization until now, since it wasn't a problem until we started indexing this block explorer.