You are not logged in.
Pages: 1
I started running arch a couple months ago with no major issues, but one thing has been bugging me, whenever my RAM usage gets really high my UI slows down to the point it is unusable, restarting or waiting a couple minutes solves the issues but nothing other than that... mos times switching to another virtual console is possible but the system is so slow the password authentication takes minutes, once i can reach a terminal using htop to kill whatever application is using a lot of RAM solves the issue right away. I have an absurdly large swap 32gb (the system has a 500gb nvme drive which is completely overkill for me) and 8gb of RAM. anyone has an idea how i can fix this issue other than adding more RAM?
Offline
lvm or ecrypted swap?
Offline
... I have an absurdly large swap ...
There have been a couple of posts on the forums lately noting slow performance with large swap partitions. That may be what's causing your problem, actually.
Offline
lvm or ecrypted swap?
lvm
Offline
Known issue, https://bbs.archlinux.org/viewtopic.php?id=231083 or https://bbs.archlinux.org/viewtopic.php?id=233086
Also seems to be a very long standing issue https://bbs.archlinux.org/viewtopic.php … 7#p1769007
Offline
thanks for the reference material @seth, for the time bein I just added 16gb of ram for a total of 24 (not optimal but was what i had in hand) hopefully this gets resolved eventually
Offline
Known issue, https://bbs.archlinux.org/viewtopic.php?id=231083 or https://bbs.archlinux.org/viewtopic.php?id=233086
Also seems to be a very long standing issue https://bbs.archlinux.org/viewtopic.php … 7#p1769007
setting up the swap on a different partition should solve it?
Offline
@seth disabling swap did nothing to help the issue, the hanging kept happening, i can reproduce this by simply opening 30 or so chrome tabs and the complete system hangs and doesn't come back unless I kill chromes process, same happens with whatever fills out too much RAM.
Offline
If you're running out of RAM, the system will drop file caches - at some point for libraries that are immediately due again.
A particular problem with chromium could be its vast amount of PIDs, delaying the OOM killer.
Did you alter some vm settings?
sysctl -a | grep vmAre you sure this is about RAM allocation and not generic IO?
Do you get this also with generic RAM pressure?
http://www.openkb.info/2014/05/using-c- … emory.html
Offline
no, never changed them
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.enp0s31f6.stable_secret"
sysctl: reading key "net.ipv6.conf.enp61s0u1u1.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
sysctl: reading key "net.ipv6.conf.wlp4s0.stable_secret"
vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.compact_unevictable_allowed = 1
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
vm.drop_caches = 0
vm.extfrag_threshold = 500
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256 256 32 1
vm.max_map_count = 65530
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 65536
vm.mmap_rnd_bits = 28
vm.mmap_rnd_compat_bits = 8
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.numa_stat = 1
vm.numa_zonelist_order = Node
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
vm.swappiness = 60
vm.user_reserve_kbytes = 131072
vm.vfs_cache_pressure = 100
vm.watermark_scale_factor = 10
vm.zone_reclaim_mode = 0Offline
Pages: 1