Boinc 6.2.19 not releasing memory

Message boards : Questions and problems : Boinc 6.2.19 not releasing memory
Message board moderation

To post messages, you must log in.

AuthorMessage
Natan

Send message
Joined: 13 Nov 08
Posts: 4
Brazil
Message 21218 - Posted: 13 Nov 2008, 11:42:10 UTC

Hi.

I'm using BOINC 6.2.19 with Rosetta (win xp 32 bit) on a dual core with 1GB of RAM. I recently set it to use only 20% of RAM while I'm working, and 60% while idle.

I usually have 1 day task buffer, and that gives me about 25 task on queue anytime.

My problem is that since I set it to use 20% of RAM (200MB), BOINC starts 2 tasks, one of them uses most of the RAM and the other goes waiting for memory (each job usually requires about 150MB of RAM).

For some reason, when the job stops because of lack of memory, it doesn't close the process and keeps it there using memory. That should be ok. The problem is that BOINC then starts the next task hoping it will be able to run it, and the same thing happens.

After 1 hour, I have 20 tasks suspended by lack of memory, and 20 processes consuming 50-80MB of RAM each, and my RAM and swap goes to space.

Does anyone have the same problem or know how to avoid this? This seems like a bug to me.

Thanks
ID: 21218 · Report as offensive
Gerry Rough
Avatar

Send message
Joined: 5 May 08
Posts: 10
United States
Message 21285 - Posted: 16 Nov 2008, 19:33:06 UTC - in response to Message 21218.  

Hi.

I'm using BOINC 6.2.19 with Rosetta (win xp 32 bit) on a dual core with 1GB of RAM. I recently set it to use only 20% of RAM while I'm working, and 60% while idle.

I usually have 1 day task buffer, and that gives me about 25 task on queue anytime.

My problem is that since I set it to use 20% of RAM (200MB), BOINC starts 2 tasks, one of them uses most of the RAM and the other goes waiting for memory (each job usually requires about 150MB of RAM).

For some reason, when the job stops because of lack of memory, it doesn't close the process and keeps it there using memory. That should be ok. The problem is that BOINC then starts the next task hoping it will be able to run it, and the same thing happens.

After 1 hour, I have 20 tasks suspended by lack of memory, and 20 processes consuming 50-80MB of RAM each, and my RAM and swap goes to space.

Does anyone have the same problem or know how to avoid this? This seems like a bug to me.

Thanks


O be not fretful O man! Yours is really a common question for newcomers. The preference you need to set at the Rosetta site is called "Leave applications in memory while suspended?" You can set it to "No" and that will solve the problem for you.

But there is a better way for you to run BOINC. Don't set your preferences so low, especially for a project like Rosetta, which is stable and uses less memory than many other BOINC projects. Set your memory preferences to 95% for both idle and working. Sound like suicide? Hardly. BOINC just doesn't use that much memory anyway with that project. You should be able to run many BOINC projects without any hiccups at all with that much memory on a dual core host. I've run Rosy and other projects with less memory and never had a hiccup like yours, as long as I monitored how much memory was being used by the different projects (just to make sure I wasn't using too much memory).

Remember that BOINC is designed to run in the background, not to hog all of your resources. And because it is a low-priority application, you should never have memory problems as long as you know how much memory you have and keep your BOINC projects using something below that threshhold of memory usage. In fact, if BOINC uses too much memory it will stop running the app anyway, and your messages tab will have a message for you telling you that there is not enough memory to run your preferred project, so there are failsafes for this kind of thing.


(Click for detailed stats)
ID: 21285 · Report as offensive
Gerry Rough
Avatar

Send message
Joined: 5 May 08
Posts: 10
United States
Message 21286 - Posted: 16 Nov 2008, 19:44:55 UTC

Actually, I didn't come to these boards to answer this question, but since mine is similar I thought I would help.

My similar question is why does BOINC continue to pile up work units in memory in the first place? Should not BOINC be told to start running the next work unit waiting, and not start a new work unit without completing all waiting work units first? That would sure help keep the memory usage way down, I should think. On muti-core hosts like the one in question for this thread, there should only be at most two waiting work units on any given project.

(Click for detailed stats)
ID: 21286 · Report as offensive
Natan

Send message
Joined: 13 Nov 08
Posts: 4
Brazil
Message 21318 - Posted: 18 Nov 2008, 17:46:26 UTC - in response to Message 21285.  
Last modified: 18 Nov 2008, 17:48:21 UTC

you need to set at the Rosetta site is called "Leave applications in memory while suspended?" You can set it to "No" and that will solve the problem for you.


I checked that before coming here, this option is not set. That is why I asked if this was a bug. I have a max of 200 or 300 MB of RAM, but BOINC uses 1.5GB easily with all those processes waiting for memory.


Don't set your preferences so low, especially for a project like Rosetta, which is stable and uses less memory than many other BOINC projects. Set your memory preferences to 95% for both idle and working.


I set this option to a lower values because it was hurting my performance. But thinking now, this didn't happen before, and started after I upgraded from 5.something to 6.2.19 (yes, it was a long jump, not sure where this bug was introduced).


In fact, if BOINC uses too much memory it will stop running the app anyway, and your messages tab will have a message for you telling you that there is not enough memory to run your preferred project, so there are failsafes for this kind of thing.


That is exactly the problem. It seems that this is not working as expected.
ID: 21318 · Report as offensive

Message boards : Questions and problems : Boinc 6.2.19 not releasing memory

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.