| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Suggestions / Feedback
Thread: Warning for maintenance outtage in the client, not on the website |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 13
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The database and BOINC code use signed ints for result.id and workunit.id*. As of this morning, max(result.id) = 1,561,950,233 and max(workunit.id) = 1,554,294,365. The max value for a signed int is 2,147,483,647. At our current rate of 2,000,000 results per day, we would exhaust the id range in 292 days. Normally we wouldn't have taken action yet. However, based on the experiences of Folding@Home and Rosetta@Home we wanted to be prepared for up to an 8x increase in participation and we wanted to make sure that anything that could disrupt the experience was taken care of before the launch of the OpenPandemics - COVID19 project As a result, today's maintenance work consists of increase the database RAM and storage by 3x. It also consists of shifting the ids for result and workunit back down to 1. Today's maintenance was the last bit of work we had to do in order to prepare our infrastructure to handle the increased capacity. Now we wait and see what actually happens. * I think the current BOINC code has changed to using unsigned ints which gives more headroom in terms of these ids. We would like to move to that code but other priorities continue to move in front of that effort. Seems like a good reason to move to 64-bit..... |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: 
|
Seems like a good reason to move to 64-bit..... Depends on what you mean by that. The constraints are INT in the database https://mariadb.com/kb/en/int/ and int https://www.geeksforgeeks.org/c-data-types/ in the BOINC C++ code. To avoid this forever (or practically forever) we need to move to BIGINT in the database and "long long int" in the C++ code. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
workunit.ids were reduced by 1494147210 result.ids were reduced by 691481976 Wrote a script to match live result names for valid tasks and then inject the new ResultId/WUId in the permanent archive rather than renumbering it all. Just don't get the why lowering the number to 86nnnnnn would gain you headroom when you say to restart at 1 As a result, today's maintenance work consists of increase the database RAM and storage by 3x. It also consists of shifting the ids for result and workunit back down to 1. , but suppose these are specifically reserved for the OPN1 tasks. If so, it sure makes it easy to know how many were distributed. Anyway, thanks, problem solved for me. |
||
|
|
|