[00:48] <keithzg> Hmm trying to figure out why a new 20.04 64-bit VM is performing so much slower for a task than the 18.04 32-bit VM . . . a script that grabs an index of MediaWiki files and downloads them all from the server used to take ~13min, now it takes ~55min! The VMs are even on the same host system! I swear I'm using identical relevant configs! I'm baffled.
[00:59] <patdk-lap> doesn't sound identical
[00:59] <patdk-lap> do you even know where the slowdown is?
[00:59] <patdk-lap> it's likely highly out of scope to diagnose this from, I know nothing to, software, kernel, driver, network, ...
[01:00] <patdk-lap> did you do a heatmap?
[01:15] <keithzg> No, the bespoke script (written by an engineer quitting soon, oof) doesn't really have any easy way to do something like that and one of the baffling things is it sure doesn't look like the VM is undergoing really any noticeable load whatsoever.
[01:16] <keithzg> I suppose I'm kinda just wondering if there's any big potential gotchas in terms of Apache2 responsiveness between 18.04 and 20.04. I can't imagine the bitness is actually the problem, although maaaybe?
[01:17] <sarnold> check dmesg? logs? journalctl?
[01:17] <sarnold> is it running into swap because pointers are bigger etc?
[01:19] <keithzg> Nothing relevant seems printed in dmesg or journalctl, no errors in the Apache logs, the Apache access logs just show each page being requested one by one. Swap seems literally unused, everything seems to be easily being done in the mere 2GB of RAM allocated to the VM.
[01:22] <sarnold> how about dns lookup errors? do all configured nameservers work to resolve the address quickly?
[01:24] <keithzg> Yeah, they really should; this is even all just on a LAN, in fact, DNS is handled by the (Ubuntu Server of course :)) router via dnsmasq, when changing from the 18.04 VM to the 20.04 VM I just updated the hosts file and that was it. That was also over a week ago so I would imagine any local caches would be invalidated by now.
[02:18] <JanC> no throttling enabled for one VM?
[02:18] <JanC> also, check if both VMs use the same type of storage (access)
[03:09] <keithzg> JanC: Ah hmm I had theoretically checked both storage and CPU settings of the respective VMs, but looking at the <devices> section of the newer VM it says <emulator>/usr/bin/qemu-system-x86_64</emulator>, while the older is <emulator>/usr/bin/kvm</emulator>...
[03:13] <keithzg> If this was all using QEMU rather than KVM and that's the entire performance difference, I'm gonna feel pretty foolish but also quite relieved haha
[03:13] <JanC> on modern systems, /usr/bin/kvm is a symlink to /usr/bin/qemu-system-x86_64 so that's fine
[03:13] <keithzg> Ah . . . well drat.
[03:14] <JanC> I was thinking more about the type of disk image or such
[03:15] <keithzg> Yeah no both are using qcow2, with virtio as the bus
=== NatSocSiD` is now known as NatSocSiD
[08:51] <lotuspsychje> sdeziel: yet another bug to add to your collection; still happens on jammy (desktop) bug #1969821
[08:51] <ubottu> Bug 1969821 in xdg-desktop-portal-gnome (Ubuntu) "File uploading sort by modified makes the window crash in browsers" [Undecided, Confirmed] https://launchpad.net/bugs/1969821
[11:42] <MaNa2k> anyone tried the new enyaq ?
[11:42] <MaNa2k> is it any good\bad ?
[11:43] <MaNa2k> ops wrong channel
[12:54] <sdeziel> lotuspsychje: that's a weird one! thanks
[12:54] <lotuspsychje> np
[13:10] <lucasmoura> Hi @rbasak, we have concluded our tests for UA release 27.10.1, since the package is already sitting on proposed for a week, I think it is okay if we release it to updates
[21:03] <teward> rbasak: around?
[21:41] <blahdeblah> Anyone able to point me to info about whether/how the compression on linux-image-generic-amd64 kernels changed between focal and jammy?
[21:41] <blahdeblah> I've got a Xen VM which I just upgraded from focal to jammy and pygrub on my Xen host won't boot the new kernel (old one works fine), claiming that the compression format isn't supported. 
[21:42] <blahdeblah> Both images claim to be the same compression format, though:
[21:42] <blahdeblah> /boot/vmlinuz-5.15.0-46-generic: Linux kernel x86 boot executable bzImage, version 5.15.0-46-generic (buildd@lcy02-amd64-115) #49-Ubuntu SMP Thu Aug 4 18:03:25 UTC 2022, RO-rootFS, swap_dev 0XA, Normal VGA
[21:42] <blahdeblah> /boot/vmlinuz-5.4.0-125-generic: Linux kernel x86 boot executable bzImage, version 5.4.0-125-generic (buildd@lcy02-amd64-083) #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022, RO-rootFS, swap_dev 0XD, Normal VGA
[22:24] <blahdeblah> Did any of my previous 5 messages come through?  (21:41-21:42 UTC)
=== coreycb_ is now known as coreycb
=== soren_ is now known as soren
=== SJrX- is now known as SJrX
=== skeer_ is now known as skeer
=== beisner_ is now known as beisner
=== Fossil_ is now known as Fossil
=== open10k8s_ is now known as open10k8s
=== falcojr1 is now known as falcojr
[22:38] <rfm> blahdeblah, there's a bug about Xen not booting the new kernel https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1956166
[22:38] <ubottu> Launchpad bug 1956166 in xen (Ubuntu Focal) "Ubuntu 22.04 doesn't boot with xen" [Medium, Fix Released]
[22:39] <rfm> blahdeblah, I don't know anything about it, I just remembered a discussion about it (maybe here?)
=== Hash is now known as OpenSource