Message boards : Number crunching : No work from project with 89,369 queued
Previous · 1 · 2 · 3 · 4 · 5
Author | Message |
---|---|
Charles Dennett Send message Joined: 27 Sep 05 Posts: 102 Credit: 2,081,660 RAC: 513 |
The database purge has finished. Completed WU's and results should now be kept in the database for 1 week before they get purged and archived so users can view their results. WU's and results (and the credits granted) that have been purged and archived have not been lost. The credits for each user is totaled and kept in the database. The result output (structures and rmsd vs energy) can and will still be linked to users and computers for the results that have been archived. Thanks for everyone's patience!! Good work, David! Enjoy the weekend! -Charlie |
Nothing But Idle Time Send message Joined: 28 Sep 05 Posts: 209 Credit: 139,545 RAC: 0 |
The database purge has finished. Completed WU's and results should now be kept in the database for 1 week before they get purged and archived so users can view their results. WU's and results (and the credits granted) that have been purged and archived have not been lost. The credits for each user is totaled and kept in the database. The result output (structures and rmsd vs energy) can and will still be linked to users and computers for the results that have been archived. Thanks for everyone's patience!! Your message is welcomed but I feel uneasy because I would like to know if the real reason for the downtime has been permanently remedied. For the period preceding the downtime I observed what seemed to be a large number of Work Units that ran perhaps 1/4 of the usual time (tests?). If the effect was to quadruple the number of WU processed in a given time period leading to a data base overflow, could we experience this phenomenon again or has it been resolved? |
Doug Worrall Send message Joined: 19 Sep 05 Posts: 60 Credit: 58,445 RAC: 0 |
The database purge has finished. Completed WU's and results should now be kept in the database for 1 week before they get purged and archived so users can view their results. WU's and results (and the credits granted) that have been purged and archived have not been lost. The credits for each user is totaled and kept in the database. The result output (structures and rmsd vs energy) can and will still be linked to users and computers for the results that have been archived. Thanks for everyone's patience!! Dave, Very good way to do it, Database,was wondering how the changes were affecting the "Results" tab and now understand.Thanks for the help explaining this Process. Aslso have a great Weekend Doug Worrall |
rbpeake Send message Joined: 25 Sep 05 Posts: 168 Credit: 247,828 RAC: 0 |
Your message is welcomed but I feel uneasy because I would like to know if the real reason for the downtime has been permanently remedied. For the period preceding the downtime I observed what seemed to be a large number of Work Units that ran perhaps 1/4 of the usual time (tests?). If the effect was to quadruple the number of WU processed in a given time period leading to a data base overflow, could we experience this phenomenon again or has it been resolved? The database I believe had not been purged since the project started on BOINC, which included several weeks of short work units. Therefore if I may read between the lines, a weekly purge should remedy the problem, and if not I suppose the project team would make any necessary adjustments to prevent a similar "outage" in the future. This is what happened with Einstein@home, and after the first "emergency" purge the project has been running very smoothly ever since. My two cents. :) Regards, Bob P. |
David E K Volunteer moderator Project administrator Project developer Project scientist Send message Joined: 1 Jul 05 Posts: 1018 Credit: 4,334,829 RAC: 0 |
Here are the steps we are or will be taking in the near future: 1. Weekly database purge and archive to keep the wu and results tables at managable sizes. 2. Adding more memory to the database server. Memory to fill out our server will be ordered today which will at least double the current size to 8gigs (we still have to check how many slots are available but an excess will be ordered regardless). 3. We are currently looking into getting a very beafy database server. 4. The size of work units will be increased (note however that they will still depend on factors like the size of the protein and what kind of prediction is being run). We will also get any necessary hardware to handle increased demand. |
Bok Send message Joined: 17 Sep 05 Posts: 54 Credit: 3,514,973 RAC: 0 |
Sounds good David however I presume you are also going to tune mysql? Is it actually using all that memory for instance? Bok Free-DC Stats for all projects Custom Stats |
David E K Volunteer moderator Project administrator Project developer Project scientist Send message Joined: 1 Jul 05 Posts: 1018 Credit: 4,334,829 RAC: 0 |
Hi Bok, Sure will. Can't let the memory just sit there unused. |
Andrew Send message Joined: 19 Sep 05 Posts: 162 Credit: 105,512 RAC: 0 |
I'm getting "Now work..." msg again. :( |
John Send message Joined: 5 Nov 05 Posts: 1 Credit: 3,835 RAC: 0 |
After 5 failed attempts I finally got work. I'm a newbie and the signup process was a snap. I like the new BOINC 5.2.6. Email and password, now that's the way to go. |
Divide Overflow Send message Joined: 17 Sep 05 Posts: 82 Credit: 921,382 RAC: 0 |
David, Do you have any plans yet for a regular schedule for maintenance (backups, purging old results, etc.) or is this still being assessed? |
David E K Volunteer moderator Project administrator Project developer Project scientist Send message Joined: 1 Jul 05 Posts: 1018 Credit: 4,334,829 RAC: 0 |
The state of our servers and expansion for the future is still being assessed. Two dual opterons are going to be ordered today and we are considering possibly getting a 16gig server. Once we have our architecture set and stable, we will set up a regular maintenance schedule for backups, purging, cleanup..etc. Our goal is to have a system that may be capable of handling Seti-like usage. |
Message boards :
Number crunching :
No work from project with 89,369 queued
©2024 University of Washington
https://www.bakerlab.org