[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD/Xen samba performance low (compared to NetBSD/amd64)
Hi Greg and others,
Am 03.08.2020 um 21:31 schrieb Greg Troxel:
Other than the 1 cpu vs ? cpus, no. I tested xen perfmorance long ago,
in 2006 with a setup
disk file in filesystem
NetBSD domU with xbd0 from the file
and found that reading with dd:
the dom0 raw disk was just about the same as bare metal
the file was maybe 5-10% slower (maybe not quite; it was noticeable but
not a big deal)
the xbd0d "raw disk" was also 5-10 % slower than reading the file in
Now, this isn't what you asked, but I find the difference you found seem
like a bug.
I would definitely do dd from the raw disk in your case 1 and 2,
followed by dd of the iso.
Also, I would repeat your tests and run "systat vmstat" during each
case, and also netstat to see if the network interface is not keeping
up. Then I would run iperf, ttcp or whatever to test network separate
from samba and disk.
many thanks to you for the helpful hints. First of all it was important
for me to get feedback if the performance losses I noticed are common.
As I understood it, this is rather not the case and a detailed
investigation is appropriate. This is what I will tackle next.
By the way, I noticed just today that even when using the "pure" NetBSD
kernel without Xen the performance is also bad in some cases. The ISO
file mentioned in the last posting is written with about 60 MByte/s.
Even if I trigger a sync every second the performance hardly drops.
However - if I (after a reboot to clean up the file cache) want to copy
the same file back via the same way (from NetBSD point of view "read") I
also only get a throughput of about 20 MByte/s. I thought that reading
should be faster than writing in any case.
But there is one detail I have just now become aware of... when I bought
these NUCs a few years ago, I installed hybrid hard disks (Seagate
Firecuda SSHD 2TB). This type has a mechanical/magnetic mass storage and
a (relatively small) SSD on the side. But from the point of view of the
operating system the device appears as a whole. The on-disk-controller
decides when and how the SSD is used. I don't know this in detail
either, only that booting from this disk works quite fast. It's quite
possible that here simply the blocks that are read first after power on
are moved to the SSD. To cut a long story short - I think I first have
to convert to either a purely mechanical hard disk or a pure SSD to
avoid measurement inaccuracies due to the unpredictable behavior of the
SSHD. Then I will approach the whole thing scientifically and consider
This week will be very exhausting and I can't assure that I will
progress quickly. But I will stay on it and write my results here as
soon as I have them.
Main Index |
Thread Index |