Libguestfs - May 2021 - libnbd flamegraph Odd benchmark results

That might be the reason

I have 8GB(7.7) of ram I verify 7.4 available by running in
tty only mode and it gets filled pretty quickly (vmstat)
Strange thing is that this also happens at size=1G.

Command I am running is

sudo perf record -a -g --call-graph=dwarf -F 300 ./sparse-random-test.sh

``` libnbd/profiling/sparse-random-test.sh
../../nbdkit/nbdkit -U - sparse-random size=16G --run "MALLOC_CHECK_../run
nbdcopy \$uri \$uri"
```

-F doesn't affect the result much, it decreases the sampling rate to avoid
CPU/IO overload caused by perf.

On a related note, what should I fill as server requirements in the OSU
open source lab application
asking for a test server?
I was thinking that a dedicated server unit with 16-32GB, 1TB should be
enough.

Regards,
Abhay
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20210530/e19a8ffd/attachment.htm>

On Sun, May 30, 2021 at 12:13:28AM +0530, Abhay Raj Singh
wrote:
> That might be the reason
> 
> I have 8GB(7.7) of ram I verify 7.4 available by running in
> tty only mode and it gets filled pretty quickly (vmstat)
I think this comes back to something that Nir Soffer said last week
about number of requests and request size:

  https://listman.redhat.com/archives/libguestfs/2021-May/msg00121.html

I followed up with a discussion about L3 cache size vs default buffer size:

  https://listman.redhat.com/archives/libguestfs/2021-May/msg00122.html
  https://listman.redhat.com/archives/libguestfs/2021-May/msg00123.html

In short the default settings for nbdcopy are wrong and more
performance could be gained by having better settings.

The question (for you!) is how we can choose better settings, and
whether we should choose simply better defaults or have dynamic
settings.  My vision for nbdcopy is that it should work "as well as
possible" without end users needing to change the settings on the
command line.  But there may be cases where users need to or want to
tune particular settings.

But I'm not sure how to achieve that.  eg: Should we choose defaults
based on the number of cores and amount of memory detected at run
time?  Or is that too complicated, and maybe we can choose more
conservative defaults?  Really I'm looking for your answers here.

I do believe that qemu gets this wrong.  There are a bunch of command
line parameters that you have to set to get good performance, and
they're not even documented.
> Strange thing is that this also happens at size=1G.
I would imagine that the large default buffer size x number of buffers
would cause problems no matter the size of the virtual disk.

[...]
> -F doesn't affect the result much, it decreases the sampling rate to
avoid CPU/
> IO overload caused by perf.
My guess is sampling rate would not affect things very much, but I
didn't measure it so I could be wrong.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW