Virtualbox hogs machine

Message boards : Questions and problems : Virtualbox hogs machine
Message board moderation

To post messages, you must log in.

AuthorMessage
Peter Hucker
Avatar

Send message
Joined: 6 Oct 06
Posts: 1144
United Kingdom
Message 103800 - Posted: 2 Apr 2021, 11:01:17 UTC
Last modified: 2 Apr 2021, 11:03:53 UTC

I don't know if there's a way round this, but it's impossible for me to use all my 24 Ryzen cores on Virtualbox tasks. It slows the interface so badly I can't interact with the machine at all. I got up this morning having let it run loads at once overnight (during the day I have to limit it in app config to only FOUR CORES!!), and the machine was so slow I couldn't even enter the password to unlock the screen. It took the password, but then just kept asking for it again! I guess one part of windows got fed up of waiting for the other part of Windows to hand the password across.

So I clicked the power icon and chose restart, thinking I'd get enough time to change the app config (I have a batch file) before Boinc got going. but it misinterpreted "restart" as "hibernate"! WTF? Mouse cursor too slow and out of synch with the display? But on restart I got the chance to change app config. Then I had a thought, if I turn the power off at the wall, Boinc notices the computer is running off the UPS and immediately pauses, so that's a way out of it. But it does break some GPU non-pauseable apps.

Any suggestions to make virtualbox behave like a normal program? It does it with LHC single core tasks, LHC 8 core tasks, and Kryptos single core tasks. And I've tried process hacker to make them idle priority. No change whatsoever.
ID: 103800 · Report as offensive
Harri Liljeroos

Send message
Joined: 25 Jul 18
Posts: 22
Finland
Message 103804 - Posted: 2 Apr 2021, 12:28:10 UTC - in response to Message 103800.  

This a problem for me also. I have a 8/16 core CPU and I have limited the number of available CPUs to 14 of which 2 goes to supporting my 2 GPUs. So that's 12 of 16 CPU cores running mostly VB tasks. I keep the LHC sixtrack in the mix whenever they are available. I have removed all max_concurrent lines from my app_config to keep the cache levels in control (1+0.1 days). This setting keeps the machine mostly responsive and only occasionally I see some lag. When I have to do something on the machine I temporarily reduce the number of CPUs by 2 until I'm finished.
ID: 103804 · Report as offensive
Peter Hucker
Avatar

Send message
Joined: 6 Oct 06
Posts: 1144
United Kingdom
Message 103805 - Posted: 2 Apr 2021, 18:07:42 UTC - in response to Message 103804.  

This a problem for me also. I have a 8/16 core CPU and I have limited the number of available CPUs to 14 of which 2 goes to supporting my 2 GPUs. So that's 12 of 16 CPU cores running mostly VB tasks. I keep the LHC sixtrack in the mix whenever they are available. I have removed all max_concurrent lines from my app_config to keep the cache levels in control (1+0.1 days). This setting keeps the machine mostly responsive and only occasionally I see some lag. When I have to do something on the machine I temporarily reduce the number of CPUs by 2 until I'm finished.
That app config thing needs to be fixed. I have to limit Kryptos to 4 (of 24 cores) when I'm using the machine. If left like that 24/7, the buffer goes nuts. I've got it set to 3 hours, but it was collecting more and more, getting up to 6 days, almost the deadline for the tasks! Boinc is not checking the app config when deciding what to download:

For example I might have 100 Kryptos VB tasks in the buffer, and I'm running 4 Kryptos (limited by app config) and 20 of something else which isn't VB. The other project finishes 1 task, so there's an idle core. It can't load a 5th VB task as I said not to, so what does it do? Downloads more of them, THEN realises it needs to try elsewhere. So every time it runs out, it gets more of what it can't do before getting more of what it can do. Bug number 357 in Boinc, and I bet it's not fixed in the upcoming version 7 either.
ID: 103805 · Report as offensive
Profile Dave

Send message
Joined: 28 Jun 10
Posts: 1439
United Kingdom
Message 103806 - Posted: 2 Apr 2021, 20:12:56 UTC - in response to Message 103805.  

Some years ago when climate@home was running. (It was during a long gap in CPDN work) I ran their tasks which ran using VB. My machine would become very sluggish and slow to respond unless I made sure only one out of two cores was running. I haven't used VB but it looks like without certainly more knowledge than I had then it wasn't straightforward if you wanted to use the machine for other things. That particular project never (in my opinion) really got beyond beta or possibly alpha quality so I don't really know if the problems were project related or not. Doubtless at some point there will be a gap in CPDN work and I will have another play and see what happens. But it sounds as if similar issues are still around.
ID: 103806 · Report as offensive
Harri Liljeroos

Send message
Joined: 25 Jul 18
Posts: 22
Finland
Message 103808 - Posted: 2 Apr 2021, 21:53:14 UTC - in response to Message 103805.  

I believe that the problem is with the max_concurrent for an app. You could try project_max_concurrent as it seems to not give that king of over download effect.
ID: 103808 · Report as offensive
Profile Contact
Avatar

Send message
Joined: 29 Aug 05
Posts: 36
Canada
Message 103816 - Posted: 3 Apr 2021, 10:51:45 UTC

There are 2 project settings available on projects that are running newer server versions.
Max # of jobs for this project
Max # of CPUs for this project


Magically, these settings are available for most projects that I normally limited via app_config.xml or similar. I now use Max # settings to limit my clients appetite for Virtual Box wu's.
In my version of stress free operations I set Max # of jobs to 1 and only one task a time is downloaded and run. Choose your own stress free #.
Max # of CPUs could be handy for greedy multi-threaded apps.
The Max # settings are available at least on these projects and likely others if I were to continue checking.

✅ LHC@home preferences
✅ LHC@home dev preferences
✅ MLC@Home preferences
✅ QuChemPedIA@home preferences
✅ RakeSearch preferences
✅ YAFU preferences
✅ Kryptos@Home preferences
ID: 103816 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4545
United Kingdom
Message 103817 - Posted: 3 Apr 2021, 11:36:04 UTC - in response to Message 103816.  
Last modified: 3 Apr 2021, 11:48:28 UTC

Thanks for that. For the second time in a week, that's something that's crept into the BOINC code, and I have no memory of it. In this case, it's been in the code-base since Jul 31, 2016 - the 'dark ages' of BOINC, after Rom Walton left and nobody was left to watch over the store. I hope this one works - I had to fix the last one.

It's a slight sadness that this has been implemented at the Project level. You couldn't use it, say in the example in this thread, to limit LHC to four VBox tasks, but run sixtrack on the 20 remaining cores. You'll still have to use the app_config.xml file for that - or ask LHC to split itself into two distinct projects.

Edit - or run two separate clients on the same machine, with two different preference sets: any VBox app but 4 CPUs max, and sixtrack with 20 CPUs max.
ID: 103817 · Report as offensive
Profile Contact
Avatar

Send message
Joined: 29 Aug 05
Posts: 36
Canada
Message 103818 - Posted: 3 Apr 2021, 12:13:57 UTC - in response to Message 103817.  

Richard Haselgrove wrote:
I hope this one works
It works as I think it was intended for me where I've used it. I no longer see a list of semi-proccessed VM jobs waiting for available resources.

Richard Haselgrove wrote:
Edit - or run two separate clients on the same machine, with two different preference sets: any VBox app but 4 CPUs max, and sixtrack with 20 CPUs max
You're onto something there. That would be the way to do it. Might also come in handy for other situations that are only brewing in the back of my mind right now.
ID: 103818 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4545
United Kingdom
Message 103820 - Posted: 3 Apr 2021, 13:34:09 UTC - in response to Message 103818.  
Last modified: 3 Apr 2021, 13:35:18 UTC

I have a tried-and-tested configuration for running two clients and two separate managers to control them, if you want to borrow it. I don't use it in normal running (barely worth it on a quad core), but it's quite tricky to set up, so it's nice to have "one I prepared earlier".

Edit - Windows only, before you ask. But the principle would still apply.
ID: 103820 · Report as offensive
Profile Contact
Avatar

Send message
Joined: 29 Aug 05
Posts: 36
Canada
Message 103821 - Posted: 3 Apr 2021, 14:32:00 UTC - in response to Message 103820.  

I have a tried-and-tested configuration for running two clients and two separate managers to control them
I think that configuration is worth it's own thread but you could PM the info if you prefer. I can't say that it won't show up somewhere on the net at some point :)
ID: 103821 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4545
United Kingdom
Message 103823 - Posted: 3 Apr 2021, 15:19:36 UTC - in response to Message 103821.  
Last modified: 3 Apr 2021, 15:23:56 UTC

It's not secret - I'm sure I've posted it here before. Here goes.

First client and first manager are absolutely standard installations. My default locations are

D:/BOINC
D:/BOINCdata

- YMMV, adjust accordingly.

In the cc_config.xml file for that instance, set

<allow_multiple_clients>1</allow_multiple_clients>
in the <options> section. May need a restart, certainly at least 'read config files' - I can't remember.

To start the second client, make a one-line batch file with

D:\BOINC\rh_boinc_test --allow_multiple_clients --allow_remote_gui_rpc --redirectio --detach_console --gui_rpc_port 31418 --dir D:\BOINCdata2
and to attach a Manager to it

start D:\BOINC\boincmgr.exe /m /n 127.0.0.1 /g 31418 /p password
Those live on my test machine desktop.

Notes:
1) I have a second copy of boinc.exe in my program directory, called rh_boinc_test.exe. That lets me run two different versions at once - you could just re-use the same one.
2) I have a gui_rpc_auth.cfg password set for the first instance. The second will pick up the same password. And a copy in the second directory.
3) The gui_rpc_port has to be not 31416, but the same in both batch files.
4) The second data directory has to be kept separate from the first. Note D:\BOINCdata2
5) Remember you have two separate clients to shut down in an orderly fashion, if you need to.
ID: 103823 · Report as offensive
Profile Contact
Avatar

Send message
Joined: 29 Aug 05
Posts: 36
Canada
Message 103824 - Posted: 3 Apr 2021, 16:03:55 UTC - in response to Message 103823.  

I have a second copy of boinc.exe in my program directory, called rh_boinc_test.exe. That lets me run two different versions at once
Thanks for all this info and escpecially that part. Back of my mind is getting noisy again.
ID: 103824 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 976
United Kingdom
Message 103832 - Posted: 3 Apr 2021, 17:46:00 UTC - in response to Message 103830.  

Hit the tiny red "x" beside the reply button and tell a moderator what's wrong
ID: 103832 · Report as offensive
Peter Hucker
Avatar

Send message
Joined: 6 Oct 06
Posts: 1144
United Kingdom
Message 103833 - Posted: 3 Apr 2021, 17:55:35 UTC - in response to Message 103832.  

Hit the tiny red "x" beside the reply button and tell a moderator what's wrong
Nothing was wrong I just wanted to delete my own post. A simple function that should be there. I'd written something that had already been covered. Also quite often people make double posts when the connection is bad. Hardly worth bothering a moderator about, plus that isn't very instant.
ID: 103833 · Report as offensive

Message boards : Questions and problems : Virtualbox hogs machine

Copyright © 2021 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.