On Sun, Dec 6, 2020 at 7:22 PM Earl Ramirez <earlaramirez@xxxxxxxxx> wrote: > For example, if I am using gedit and select File > > Open I will have to wait approximately 45 to 90 seconds before Nautilus > launch so that I can select the file. 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? >The same goes for any application > . I thought that it was because of BTRFS COW but that theory was out of > the window after I replaced BTRFS with XFS, the only noticeable > difference is with XFS it takes a few hours before I experience the > same behaviour with slightly shorter delays for Nautilus opens. 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. > My configuration > 2 x Samsung SSD 850 with RAID1 (/boot and /boot/efi is not part of the > RAID) > LVM > 1 x LVM volume group > 8 x logical volumes > 32GB RAM > 4GB ZRAM Nothing unusual there that I can see. > > I mostly use the laptop for building/testing vms and containers > therefore, I have high I/O requirements. > > I believe that I may need to increase my zram size which use to be > fully utilise when I was using BTRFS but with XFS it never passed 1GB. > Do I need to resort to the traditional SWAP or will increasing the ZRAM > pool? 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@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 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
