Good:
Database is running more smoothly than ever, daemons (transitioner, assimilator, validator) are working through their backlogs, scheduler seems to send out work.
Bad:
All related to ABP1 is currently offline, because for some reason the connection to Hannover isn't stable. For some other reason the S5R5 workunit generator is running too slow to keep up with work requests, so the project might run out of work some time over the weekend, unless someone fixed these issues.
But after some 12 hours of hard work Oliver and I are too tired to take much care of this, we'll possibly do more damage than good. Need to get some sleep.
I think that's a very wise, and well-earned, decision. If there's not a ready supply of ready-prepared work, so what? It can wait until next week, when hopefully the solution will seem more obvious.
But after some 12 hours of hard work Oliver and I are too tired to take much care of this, we'll possibly do more damage than good. Need to get some sleep.
BM
I only want to say thank you for your hard work and I'm happy that were back in business again!
But after some 12 hours of hard work Oliver and I are too tired to take much care of this, we'll possibly do more damage than good. Need to get some sleep.
BM
I only want to say thank you for your hard work and I'm happy that were back in business again!
/Holmis
Ditto. I can only vaguely imagine the hard work you've been doing. We're all thankful the project is up and running again.
But after some 12 hours of hard work Oliver and I are too tired to take much care of this, we'll possibly do more damage than good. Need to get some sleep.
BM
Thank you (and oliver) for you hard work to get the project back up. Work is flowing again. Once again thanks guys.
I think any growing project sooner or later will faces with such a problem. The problem of growing table size is so common that it is time to think about a new ways to manage data. Purging and indexing the table more and more will not get a fix for it. It'll be better to decide how to divide big tables into subarrays which size will be sufficiently smaller to not reach the access speed limit in the near future. One of the most popular program in Russia is 1C:Accounting 1C:Accounting because of lot of accounting laws and enourmous number of taxes. This program already prove itself as an excellent database manager - it can struggle agains gigabyte-size databases without any huge requests to a hardware. Moreover some old versions did work with *.dbf tables and it was not terrible - it works these days on many millions computers allover the Russia, Ukraine, Belarus etc for years and it is not slowing down. Of course today they build already new versions that works with MySQL or MS-SQL, but this is the fact - this version is still works and is supported by the developers yet.
So, this time we faced the problem that says us: you may rely on sql technologies, but you surely must remember how did you worked with this data about 10 years ago - those technologies are not dead yet.
Guess, this should help a bit :)
* We found a workaround for the problems with the S5R5 WUG (WU Generator), so we probably won't run out of work in the near future.
* We also found a workaround to run the ABP1 validator and assimilator, the WUG is still causing some headache.
* We needed a couple of workarounds to bring the project back online, which will probably require a scheduled downtime for a few hours some time next month to remove them. But for now we're getting back on track.
* We needed a couple of workarounds to bring the project back online, which will probably require a scheduled downtime for a few hours some time next month to remove them. But for now we're getting back on track.
BM
Does that remaining work include communications / connection to say : boincstats.com and statsnstones.tswb.org ?
I've noticed that they haven't been updating Einstein data for a while now. So when can we expect that to happen ?
Or am I wrong and it isn't an Einstein issue but something related to mentioned statistics sites ?
* We needed a couple of workarounds to bring the project back online, which will probably require a scheduled downtime for a few hours some time next month to remove them. But for now we're getting back on track.
BM
Does that remaining work include communications / connection to say : boincstats.com and statsnstones.tswb.org ?
I've noticed that they haven't been updating Einstein data for a while now. So when can we expect that to happen ?
Or am I wrong and it isn't an Einstein issue but something related to mentioned statistics sites ?
regards Vagn
Most projects provide a 'feed' of the stats, if one independent site gets them then they all can. Some independent sites are not real good about tracking when they do not get the stats and it can take a few days to figure out where they went if the project moves their 'feed'.
Status: Good: Database is
)
Status:
Good:
Database is running more smoothly than ever, daemons (transitioner, assimilator, validator) are working through their backlogs, scheduler seems to send out work.
Bad:
All related to ABP1 is currently offline, because for some reason the connection to Hannover isn't stable. For some other reason the S5R5 workunit generator is running too slow to keep up with work requests, so the project might run out of work some time over the weekend, unless someone fixed these issues.
But after some 12 hours of hard work Oliver and I are too tired to take much care of this, we'll possibly do more damage than good. Need to get some sleep.
BM
BM
I think that's a very wise,
)
I think that's a very wise, and well-earned, decision. If there's not a ready supply of ready-prepared work, so what? It can wait until next week, when hopefully the solution will seem more obvious.
Welp, my towers are going
)
Welp, my towers are going back to work fully-loaded...
My thanks to BM and the Einstein team for getting the project up and running again...
And not forgetting those who'd keep the forum alive... :P
RE: But after some 12
)
I only want to say thank you for your hard work and I'm happy that were back in business again!
/Holmis
RE: RE: But after some
)
Ditto. I can only vaguely imagine the hard work you've been doing. We're all thankful the project is up and running again.
prairie69
RE: But after some 12 hours
)
Thank you (and oliver) for you hard work to get the project back up. Work is flowing again. Once again thanks guys.
BOINC blog
I think any growing project
)
I think any growing project sooner or later will faces with such a problem. The problem of growing table size is so common that it is time to think about a new ways to manage data. Purging and indexing the table more and more will not get a fix for it. It'll be better to decide how to divide big tables into subarrays which size will be sufficiently smaller to not reach the access speed limit in the near future. One of the most popular program in Russia is 1C:Accounting 1C:Accounting because of lot of accounting laws and enourmous number of taxes. This program already prove itself as an excellent database manager - it can struggle agains gigabyte-size databases without any huge requests to a hardware. Moreover some old versions did work with *.dbf tables and it was not terrible - it works these days on many millions computers allover the Russia, Ukraine, Belarus etc for years and it is not slowing down. Of course today they build already new versions that works with MySQL or MS-SQL, but this is the fact - this version is still works and is supported by the developers yet.
So, this time we faced the problem that says us: you may rely on sql technologies, but you surely must remember how did you worked with this data about 10 years ago - those technologies are not dead yet.
Guess, this should help a bit :)
Update: * We found a
)
Update:
* We found a workaround for the problems with the S5R5 WUG (WU Generator), so we probably won't run out of work in the near future.
* We also found a workaround to run the ABP1 validator and assimilator, the WUG is still causing some headache.
* We needed a couple of workarounds to bring the project back online, which will probably require a scheduled downtime for a few hours some time next month to remove them. But for now we're getting back on track.
BM
BM
RE: Update: * We needed a
)
Does that remaining work include communications / connection to say : boincstats.com and statsnstones.tswb.org ?
I've noticed that they haven't been updating Einstein data for a while now. So when can we expect that to happen ?
Or am I wrong and it isn't an Einstein issue but something related to mentioned statistics sites ?
regards
Vagn
RE: RE: Update: * We
)
Most projects provide a 'feed' of the stats, if one independent site gets them then they all can. Some independent sites are not real good about tracking when they do not get the stats and it can take a few days to figure out where they went if the project moves their 'feed'.