On Tue, 16 Jun 2020 at 09:41, Marco Möller <talby@debianlists.mobilxpress.net> wrote:
sudo sysctl vm.swappiness=
sudo sysctl vm.vfs_cache_pressure=
sudo sysctl vm.dirty_background_bytes=
sudo sysctl vm.dirty_bytes=
Thank you Marco.
I checked my current values
---
sudo sysctl vm.swappiness
# vm.swappiness = 60
sudo sysctl vm.vfs_cache_pressure
# vm.vfs_cache_pressure = 100
sudo sysctl vm.dirty_background_bytes
# vm.dirty_background_bytes = 0
sudo sysctl vm.dirty_bytes
# vm.dirty_bytes = 0
---
but I haven't changed anything yet. Will try to change something and
let's see what is going to happen.
On Tue, 16 Jun 2020 at 10:16, Will Mengarini <seldon@eskimo.com> wrote:
30 s is suspicious for a DNS timeout, but I don't know
how to identify what's causing it.
Thank you Will. It's not exactly 30sec - sometime it's just 5-10sec,
sometime it is even longer than 30sec.
But that made me think since the container has no interfaces / no IPs
(except localhost).
In Ubuntu container I stopped and disabled systemd-resolvd and add a network
interface with static IP 10.33.44.55 and in /etc/resolv.conf I set the same IP.
Nothing it listening on 53 inside LXC so if a program requests DNS
the request should get immediately refused (no timeout).
But unfortunately that didn't help. But thank you for trying!
Meanwhile I setup testing laptop. I have identical Debian Buster setup
on multiple laptops
(all have the same issue) so I'm connecting the testing laptop from
the main laptop over SSH.
On testing laptop I'm clicking inside VSCodium to trigger the freeze
and meanwhile I'm in LXC
container (lxc-attach over SSH) from main laptop. I can confirm that
when I'm attached
the system is responsive during the freeze so it's really just GUI,
not the system.
Kind regards,
JR