Search results

Ok, after more reading I was wrong. While OOMkiller may be held at bay by LXC/LXD defaults of 90% ram use thresholds, it cannot evict TMPFS pages. How is buffers/cache related to TMPFS? There's a misleading 'feature' in LXCFS reporting TMPFS as 'buffers/cache' ram. So no amount of researching...

Note that doing so will clear the caches/buffers for the entire host and dump ARC if you're using ZFS. This will spike read usage on your disks, since there's no more read cache available, and it will start repopulating as blocks are read. It's a horrible solution, honestly. This is a major bug...

Workaround for now is the echo 1 > /proc/sys/vm/drop_caches (you can keep some caches by not using echo 3), but, major performance hit. This is the same issue and there's more because it's a common problem, should merge these threads...

It's not fixed in 7.1 and you cant drop caches in a CT, only for the whole host. On my 256GB host with 96GB of arc, that seems like a massive cache loss/performance hit. #echo 1 > /proc/sys/vm/drop_caches bash: /proc/sys/vm/drop_caches: Read-only file system These are basically the same...

OK! Finally caught this happening. It's NOT systemd-journal.* *EDIT: (Actually, it is, but in a non obvious way. See the further down in this thread to post-472649) I started logging mem and top on the container continuously to a log every 15 seconds or so, and this is the last top output just...

systemd-journal could also be a culprit. 50 root 20 0 284232 181392 178368 S 0.0 11.5 1:46.72 systemd-journal huge and the...

From what I understand <command> can have no options or arguments to it. Gets very complex if you want some.

#lxc-ls -fF NAME,STATE,RAM NAME STATE RAM 100 RUNNING 0.00MB 261 RUNNING 0.00MB 270 RUNNING 0.00MB proxmox-ve: 7.1-1 (running kernel: 5.13.19-4-pve) pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe) pve-kernel-helper: 7.1-12 pve-kernel-5.13: 7.1-7...

This seems related to buffers/cache filling up in the container until OOM killer runs: https://forum.proxmox.com/threads/continuously-increasing-memory-usage-until-oom-killer-kill-processes.67666

Turns out this is a VNC server implimentation failure - tightvncserver does not impliment some Xkeyboard features qt5 needs. (I never put BMC/ILO on external networks, always on RFC1918 ips, and I never route them/give them a gateway for security reasons. Instead I put a jumphost on the bmc...

There's only hotkeys in the virtual keyboard and only settings are US101 vs JP-something keyboards (I did try setting to JP and back and didnt help). Apparently a windows box attached directly to the BMC/ILO lan works just fine. Ill have to use the damn vpn (vs portforwarding to a vnc session...

Keyboard works for me here except random keystrokes are sent, including ctrl keys (for eg, i have discovered '5' = 'backspace'). I can almost get through all the menus with cut-and-pasting random stuff in (that i can change once it's installed after i ssh in with a cut-n-pasted root password...

But its easy to see the behaviour regardless -- just watch buffers on the container, and when they get to be similar size as the free ram (~70-80%) you are running into problems if your container is >20% of ram usage. Something's gotta give, and buffers arent evicted, OOM is awakened instead. I...

More examples: total used free shared buff/cache available Mem: 4194304 1883736 36 2305568 2310532 2310568 Swap: 5242880 1048532 4194348 This container is really irritating to use because it pauses all the time...

Not using tmpfs much at all in this situation. though ill keep an eye on the systemd journal in /run #df -k `grep tmpfs /proc/mounts | awk '{print $2}'` Filesystem 1K-blocks Used Available Use% Mounted on none 492 0 492 0% /dev tmpfs 65997564 0...

This is ridiculous, this container is running a simple apache and mailman with a gig of ram: total used free shared buffers cached Mem: 1048576 1048464 112 920736 0 921504 -/+ buffers/cache: 126960 921616 Swap...

There is a very serious issue with LXC and ram usage under ZFS. OOMkiller is running constantly on containers that had ram from 5.x that was just fine for them forever. Suddenly i need to add 1, 2 or even 4GB to all containers. I think caches are being accounted for to the CT's, oomkiller comes...

Namely my question is "why is there an ip networking configuration not supported in lxc/*.conf files"? Please let me know how to set SCOPE LINK in a lxc/*.conf file.

Wonder if its fixed in 6.x

I am not upgrading or restarting lxcfs.service to cause this. It seems to happen by itself. (Unless OOM pressure has killed it and it has restarted itself or something similar?) Will investigate more.