On Sun, Dec 6, 2020 at 7:22 PM Earl Ramirez <earlaramirez(a)gmail.com&gt; wrote: It takes 45 seconds to launch any application? This is definitely not normal no matter the file system or arrangement. Can you provide exact reproducer steps? Can you install bcc-tools and then run this command: sudo /usr/share/bcc/tools/fileslower And then reproduce the problem? Once the app launches, you can control-c to quit. Can you post the results? I think it's OK to just paste it into the email reply to list. By default it will show only IO that takes more than 10ms. It's possible it won't show anything, which would be good but still mysterious. This is what I get with 'fileslower 1' which shows IO taking more than 1ms, while launching GNOME Maps. This is on NVMe. SSD might be a touch slower, possibly high single digit latencies. https://pastebin.com/UpY5QH8x But if you're seeing higher than 100 let alone 1000 then the problem is related to files being read slowly. In that case it might also be useful to see if this is happening at the device level. sudo /usr/share/bcc/tools/biolatency 5 15 Now try to reproduce it again. These values are in usec and should be less than 64K usec I'm guessing. Again you can past that whole thing into the email reply, it's just asciiart, it'll probably be OK :D Example: https://pastebin.com/u9fbpbvw Only the worst performers are likely to be revealing of a problem. It doesn't matter to me if you include all 15 or just the ones that have the highest values. In that example, it's the third block that ends in 32768 -> 65535. Do paste in the entire block though if you get this far. Nothing unusual there that I can see. You only need to increase it if you're regularly hitting the limit, i.e. it's full as reported by swapon. I'm not sure why the file system would make any difference in swap utilization. It tends to be related to the workload. If so you can start out with: sudo nano /etc/systemd/zram-generator.conf Add to it: [zram0] max-zram-size=8192 Save and then: sudo systemctl restart swap-create(a)zram0.service The logic behind capping at 4G is just to be conservative. i.e. to avoid the small amount of extra overhead for a larger zram device that may not get used; and also the case where something starts using so much swap that it sucks up memory, even though it's compressed on the zram device. There's a good chance the cap goes to 6G or 8G in F34, i.e. the lesser of 50% RAM or 8G. There's also some idea of bumping the percentage to something like 70%. (Quite a lot of use cases run at 1:1 zram to RAM, and upstream considers 2:1 reasonable due to the compression ratio. I think in Fedora land that's too aggressive for making it the default behavior, but on a case by case basis it's reasonable not least of which is that it's easy for users to fiddle with it, if they want.) -- Chris Murphy

On Mon, 07 Dec 2020 22:14:14 +0800 Earl Ramirez wrote: I've seen this when, for example, I've got an NFS mount to a system that is not up at the moment. All the annoying file dialogs want to be "helpful" and populate the browser with every single mountpoint or even unmounted disks that appear to be attached (which is another case, since if the disk has spun down, it has to spin back up again). You could try running strace on the app just before opening a file and see if something like a stat call is hanging during the open.

On Mon, 2020-12-07 at 07:59 -0500, John Mellor wrote: It's a software RAID, I will agree that something is seriously wrong but I am unable to reproduce the same behaviour from a Live CD even if I use the Live CD for 48 hours.

Hi Jorge, I completely forgot to mention that I have a CIFS share mounted with AutoFS, this is included in the Ansible role that I use to configure after a vanilla install of Fedora computers/laptops. I disabled AutoFS and will try to see if the issue persist and keep you all posted. There are no shortcut/bookmark for the mount. It is important to mention that my wife and kids laptops do not experience the same behaviour and they are all using the exact same setup. I will investigate and report back, I do not believe that it is DNS though since the AutoFS configuration has the IP address of the CIFS server. It's any application that you can use to open a file. Which is why I believe that it can be related to the CIFS mount

On Mon, 2020-12-07 at 19:48 -0400, Jorge Fábregas wrote: You were right, the culprit is the AutoFS mount that is causing the delays. AutoFS was stopped and disabled for a day and I did not experience the issue. Started AutoFS a couple hours ago and when I tried to open a file from gedit I experienced a delay of 45 seconds. Thanks you all, Chris Murphy, John Mellor, Jorge Fabregas, and Tom Horsley.