On 01/10/2019 11:16 PM, Bruce Ferrell wrote:
> So, yeah, but what...  Exactly is slow?  Is the performance issue CPU? I/O
> (disk)?  Interrupts?  Let's find out.
>

First, this is a Win7 Pro Guest, fully licensed, with 2-cores (or an 8-core
proc) and 2G of RAM allocated to the guest. Host is Archlinux with AMD FX-8350
and 32G, runs at 0.1 - 0.5% utilization -- out of 800%, lightly loaded server
- basically a file server. With the vbox guess running (at idle before login),
top show:

top - 00:10:19 up 10 days, 22:57,  2 users,  load average: 0.00, 0.31, 0.43

Guest is run headless and accessed over the LAN via rdesktop from my laptop --
have done it this way for years)

What exactly is slow?... Good question.

When you open the good old "Command Prompt" (116x66), simply trying to do are
Directly listing, CPU spikes by by 42-43%, the first 5-10 files are listed,
and then when the listing reaches the bottom of the window, it is literally
like watching a DOT-Matrix printer print, one line (one file listing) at a
time slowly scrolling by.

The 'src-c\tmp` directory I keep the StackOverflow C question sources in has
172 files on this guest (a very small directory by normal standards), I
redirected the output just to emphasize, I'm just trying to get a 'dir'
listing, e.g.

C:\Users\david\Documents\dev\src-c\tmp>dir
 Volume in drive C has no label.
 Volume Serial Number is 2045-D579

 Directory of C:\Users\david\Documents\dev\src-c\tmp

01/05/2019  09:20 PM    <DIR>          .
01/05/2019  09:20 PM    <DIR>          ..
05/24/2018  09:27 PM    <DIR>          3file89
12/09/2017  04:37 AM             1,256 a1ms4.c
12/05/2017  03:02 AM             4,044 animals_bin_c89.c
06/13/2017  02:17 AM               133 args.c
11/09/2017  02:01 AM               420 argvptr2.c
11/16/2017  02:46 AM               787 array_idx_1d_as_2d.c
05/15/2018  03:27 AM             1,712 array_ptp_const_char.c
01/06/2018  04:23 AM               414 arrptrs.c
10/07/2017  11:47 PM             1,867 arsz.c
01/05/2019  09:24 PM    <DIR>          bin
03/28/2018  01:35 AM             4,119 bin2decann.c
03/28/2018  01:42 AM             4,216 bin2decszt.c
... <snip>
10/05/2016  09:40 PM             2,133 wordfreq.c
09/03/2017  12:13 AM             1,723 wordhashtest.c
09/03/2017  04:24 AM             6,883 wordhash_tbl.c
09/03/2017  04:24 AM               975 wordhash_tbl.h
06/13/2017  03:42 AM             1,724 xstrtol10.c
             176 File(s)        680,188 bytes
               9 Dir(s)  19,437,088,768 bytes free

(even trying to mousewheel back up to the top to copy the command was
painfully slow)

It took 20.5 seconds for the 176 files to list. (do you know how long 20.5
seconds is watching a directory listing....?)

The common thread between cmd.exe (and it blue-colored counter-part
PowerShell) seems to be how windows repaints the areas that change within the
command prompt, and whatever changed in virtualbox 6 that effects this.
Recall, the command prompt is painfully slow to move across the desktop as
well, leaving artifacts of where the window was and slowly repainting as you
move the window.

Now I am accessing this guest across the LAN (which has never been a problem
before), so if something changed in 6.0.0 related to how much, or how, the
headless interface is handled -- that might explain things as well.

Then only thing that makes sense based on what I am seeing is that small
window redraws (like for a line of text in the command prompt) are using far
more resources (or equivalent resources) to an entire window move in 6.0.0.
When large areas are redrawn all at once, there is not much slowdown seen. But
when you are trying to redraw 60 12 pt. font lines in the Command Prompt, the
output comes to a crawl.

I don't know if this list will let the image come through, but I took a screen
shot of the CPU spike caused just from typing 'dir' in the Command Prompt for
the directory listing above -- it spikes taking 50% CPU (from each core), just
to do the 'dir' (that's just nuts) I have the section on both CPU graphs
underlined in Red for the 'dir' command. The Command Prompt and taskmgr.exe
were the only things running. (Win7 memory usage was 597M out of 2G available,
so there is no paging issue, etc..)

This is the darndest thing I have ever seen with vbox and I'm completely stuck.


> That may give a pointer to an area of virtualbox to look in at least.
> 
> I might even get radical and grab the open source version of sysdig and
> profile the VM process, but that MAY be a bit extreme... strace on it/them 
> maybe?

(I'll leave this to the last resort if we run out of answers. top on the
server remains unchanged during this episode. (just grabbed it again)

top - 00:36:57 up 10 days, 23:24,  2 users,  load average: 0.13, 0.12, 0.18

Virtually no load on the server at all.

I give...

-- 
David C. Rankin, J.D.,P.E.
_______________________________________________
VBox-users-community mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/vbox-users-community
_______________________________________________
Unsubscribe:  
mailto:[email protected]?subject=unsubscribe

Reply via email to