Tails high guest CPU load

[Carmageddon]

Hey guys,

I've been running Tails (based on Debian, but don't know which version) and recently has been running into performance issues with later versions of both..

Tails 2.5 on VBox 4.3.40 - works OK (guest CPU load at around 40% which is acceptable)
Tails 2.9/2.10 on 4.3.40 - guest CPU constantly over 70%; very slow
Tails 2.5/2.9/2.10 on Vbox 5/5.10 - guest CPU constantly at 100%, unusable performance

I also did an experiment where I created a Tails 2.5 VM on VBox 4.3.40, saved and upgraded VBox to 5.0. It worked normally for some time (about 2 days) but at some point the CPU load again jumped to ~70%, and later yet to constant 100%. Furthermore, the internet connectivity also drops out randomly very often.

In the guest process monitor, there's a VBoxClient process running which is at 100% CPU. Oddly, previously when I was experimenting I have not seen this (no single process had any CPU usage when the system was idle).

On the host, the high CPU load is only apparent after I log into the guest, not immediately after the guest OS loads.

Any idea what's up?

Host: W7N Pro x64, host CPU Intel Q6600 (supports hw virtualization). I've tried to enable/disable/change all the performance-related settings including assigning more than 1 VCPU but nothing seems to have an effect.

I don't have these issues with other Linux, Unix or Windows guests.

Thanks for any ideas.

(I'd rather not post an entire log as I don't know how much stuff is in there, if it can be avoided.)

[mpack]

Please post a VM log file. With the VM fully shut down, right click and "Show Log" in the GUI, save "VBox.log" (ONLY) to a zip, and attach the zip here.

[Carmageddon]

Okay. I'm running a VM with Tails 2.5 at the moment so I created a new VM with Tails 2.10, ran it once until it booted completely into the desktop, then shut down (had to kill it at the end since it froze at wiping the memory), both the log and the hardening log are attached to the original post. As expected, the guest CPU load was at 100%.

Also, I found another strange thing yesterday. After I posted the OP (it was when the Tails 2.5 was clogged at 100% with no user programs running), I restarted the VM machine using the restart command in the guest OS; after it rebooted, the CPU was still at 100%. But when I killed it from VBox and started it again, it went to the reasonable ~40%. I'll see if it jumps up as I let it run for some time.

[Martin]

Just had time for a quick look at your first log:

00:00:02.732583 Host RAM: 6142MB total, 1698MB available
00:00:03.982208 RamSize <integer> = 0x0000000080000000 (2 147 483 648, 2 048 MB)

The guest RAM size is too big for the current memory state of your system.

[Carmageddon]

Umm no, that's not right, I freed up over 3 gigs of physical RAM by saving down another VM before running this one.

Maybe it's being reported wrong because a lot of non-VM-related stuff is being swapped on my host.

Regardless even if that was the case, Tails on startup takes up maybe 500 megs of RAM at most and if the VM runs out of physical memory, VBox will just pause it, so that has no effect on CPU usage.

[mpack]

It is right. It's not reported wrong. The first step in solving any problem is believing the evidence in front of you.

[Carmageddon]

I think I know what I'm doing with my own computer and I can look at the task manager to see how much free physical memory I have.

And even if not, the fact remains that running a Tails VM does not immediately take up the entire amount of assigned RAM. So if Tails VM uses 500 megs of RAM, then even the 1600 megs that the log (wrongly) reports would be far enough.

And even if that weren't true either and *somehow* I were able to run a 2 GB VM with insufficient memory, I still don't see how that would affect the guest CPU usage, and only on newer versions of VB and/or never versions of the guest OS?

Edit: Anyway, sorry if I came off as an ass, but when I was troubleshooting this problem, I've also tried running with a freshly booted up host, so really the memory is not a factor here.

[mpack]

I don't know if its what you mean, but the log tells us the memory status when the logged VM was started - which is also when it allocated memory - so a second VM shutting down will not have helped.

If you like you can try rebooting your host, launching this VM on its own, and then post a new log. Then we'll know that no other VMs are running and influencing the numbers.

VirtualBox doesn't subtract the two numbers and refuse to start. It will ask the host to allocate the configured amount of RAM, and if the host OS says OK then VirtualBox doesn't care where the RAM came from. Hence it is quite possible that you can start a 3GB VM when the log says (on startup) that only 2GB was available. Some hosts keep objects in memory and only discard them when something else needs the RAM. That may have happened here... but the fact remains that gobbling an oversized chunk of host RAM is often the source of stability and performance problems if not outright failures.

[Perryg]

I have to disagree that memory is not an issue here from what I have seen so far. Heavy I/O will produce a major CPU hit and swapping is almost always the cause from what I know. Swap is not a friend to virtual guests.

[Carmageddon]

We can discuss the fine details of RAM working forever but I assure you it's not an issue.

As I mentioned above, even when I start the VM with freshly rebooted host with 5+ gigs of free RAM and no swap use whatsoever, this issue occurs still.

And again it's ONLY with either newer version of VBox (5/5.10) or newer version of Tails (2.9+) this occurs, and NO OTHER guest OS has this problem on my system.

Look if it makes you happy, I'll reboot my PC and post another log with more free RAM but it's a waste of time since I've already done that and the results are always the same.

//
Anyway, i still have to say that how you describe the RAM allocation is not what I've seen before. I use swapping a lot (DDR2 memory is hard to come by so I don't have much option, fortunately with my fast SSD I barely feel any hit) so sometimes it happens that I run out of free RAM. If I try to run any VM at that point, as soon as the limit of the *physical* RAM is reached, the execution of the VM is paused and VBox throws me a warning; unless I find a way to free up more physical RAM, it won't continue (sometimes it also just crashes and aborts the VM). The same happens if I run out of physical RAM while the VM is already running. VBox doesn't accept swap at all. I dunno maybe there's a setting for it because I remember older versions I used to run on XP (maybe 3.x or earlier 4.x versions) were fine with swapping, but apparently it's not the case anymore.

[Perryg]

For my part I am not trying to convince you of anything only telling you what I know. I'm just a simple person that does not have the problem you describe. Perhaps you are on to something and the real issue is the new tails, I wouldn't know since I don't use it. Anyway I have provided all I can to the discussion. Good luck and I hope you get this resolved.

[socratis]

If you want to keep believing that the VBox.log is lying, please provide evidence, statistics at the exact time that you launch the VM. I'm not completely throwing away the 0.0001% possibility that VBox.log is wrong, but you've got to prove it. And not with words or impressions, but with hardcore evidene. mpack and Perryg have eons of experience on these things, listen to them.

In the guest process monitor, there's a VBoxClient process running which is at 100% CPU.

And that's your problem, it's not Tails. That's what bogging down all the available resources. I haven't looked at the logs, but you've updated the GAs?

[Carmageddon]

If you want to keep believing that the VBox.log is lying, please provide evidence, statistics at the exact time that you launch the VM.

Well, how exactly do I provide that evidence? Yes I'm pretty sure the log is wrong and VBox is reporting the free RAM wrong. In fact if you tell me how to prove it scientifically, I'd probably report it as a bug (although I still find it questionable how exactly the log reports the free RAM, but whatever). It's for another thread anyway.

Again, I have tried running the VM with a freshly rebooted host, it makes no difference, and I don't have the issues with other guests, even those with 3+GB virtual RAM set.

Tails is a live-only distro with no way to update GA.

But (not sure how clear this is from my original description) the VBoxClient process taking up 100% in the process monitor was only on one occasion. At other times, even if the CPU load is 100%, no particular process shows it's using the CPU that much, and the VBox related processes are at 0% load. So I don't know what's up.

I'm not all that familiar with Linux to be honest, what other information from inside the guest could I provide or check?

[Perryg]

Ah Tails live, now that's another horse of a different color. It could be because the OS is running in software rendering mode that you are seeing this. This does produce a lot of hits to the CPU since it must render the desktop all from the processor. That you would need to investigate because as I said I don't use it. The RAM is an issue as well so never forget that. I do Linux and know a bit about how it works and swapping will play into this as well. Remember swap is not memory. It is a place where unused processes can be moved to free up real memory and if one of the processes that gets swapped is necessary for the operation of VirtualBox it will cause huge issues.

[Carmageddon]

It's rather likely it's running in software (but mind you, Tails DOES include the GA tho possibly not the latest), which would explain the ~ 40% CPU load on the older versions of Tails and VBox (still high but usable), but not the 100% really.

Some of the Linux distros I run obviously run in software rendering (such as Mint, at least it used to when I was using it) but they are still usable, just like Tails used to be. But with 100% load it's obviously completely clogged.

Any idea where to look for answers inside the guest OS?

//
Edit 2:

OK so I''m attaching a log from a new run of Tails 2.10 VM, with more host RAM available, this time from VBox 5.10. (Issue remains. Guest CPU constantly at 100%.)

Also I found at least one issue: drag-and-dropping files into the Tails guest (2.5/2.10) no longer works with VBox 5.0/5.10. It worked fine with VBox 4.3.

If I try to drop several files into the window, I can briefly get the progress bar 'dropping' (or something like that) but there's never any indication on the guest OS that any files are being dropped and they don't show up.

Furthermore, if I drop the files into Tails 2.5 and after that fails I try again, the VBoxClient --dragandddrop process jumps to 100% usage.

So there's certainly something about Tails that VBox 5.0+ doesn't like, and I guess something about VBox in general that newer versions of Tails don't like

I don't have time to try drag-and-dropping into other guests right now. Does it work for you guys, with VBox 5.0/5.10?