The fundamental problem seems to be that BOINC treats the RAM usage of each job independently; if job 1 for a given app version exceeds the RAM limit, it will suspend job 1, then run job 2 for the same app version, see that it exceeds the limit, and repeat indefinitely.
Proposal: assume that all jobs using a given app version will use as much RAM as the largest active job using that app version, and not start additional jobs in the above scenario. -- David On 10-Dec-2010 7:00 AM, Ed A wrote: > > Also would like to ask for a setting to allow limiting the number of "project > WUs" that are allowed to run concurrently. This is getting to be more and > more > of an issue as the number of processor cores increase. The longer NFS, > Lattice > and Yoyo (to name a few) can bring a multi core machine to it's knees and > there > seems to be no good way in BOINC to regulate the number of these WUs that are > run concurrently. Setting a memory limit results in a long line of suspended, > partially run WUs as BOINC keeps trying to start new instances and then > swapping > them out. Setting a low project priority on a quad for instance (20%) often > results in the project not running for a given period then trying to equalize > by > running 3 or 4 instances at once, making the machine unusable. The situation > has been a problem for quite a while and is getting worse as the number of 6 > core (and virtual 8 core) machines increase. With true 8 core machines due > any > time now this should be addressed. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
