http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c1 Benjamin Zeller changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs+opensuse@lhpmail.us, | |bzeller@suse.com Flags| |needinfo?(bugs+opensuse@lhp | |mail.us) --- Comment #1 from Benjamin Zeller --- Could you reupload the strace? I can not get any valid data out of that file, seems corrupted. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c3 --- Comment #3 from Benjamin Zeller --- Thanks for reuploading, afaics most of the lstat calls are cgroup related. LXC makes heavy use of the cgroups, which is not something zypper can influence. In your strace there are 3237133 calls to lstat of which 3209403 are cgroups related alone. The ones initiated by zypper are just a small fraction. Do you still get the high memory consumption in the new container? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c5 --- Comment #5 from Benjamin Zeller --- Must be a side effect of running inside your container. I cannot see a memory usage like that for a zypper search run on my machine directly. Can you provide the steps to reproduce your test env? Or is it just a plain OpenSUSE Tumbleweed container running in a default LXC container? Also once zypper exits there is no way it can still use up any memory since the kernel will clean up all ressources that are allocated by the process. So if the mem consumption of your container stays high even after zypper exits there is something else wrong here. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c7 --- Comment #7 from Lutchy Horace --- I like to note about lxc-download, you should do that from another machine than upload the image to /var/lib/vz/cache/templates. You probably could reproduce this in a VM. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c9 --- Comment #9 from Lutchy Horace ---

1.18user 0.16system 0:02.37elapsed 56%CPU (0avgtext+0avgdata 99868maxresident)k 0inputs+192outputs (0major+29391minor)pagefaults 0swaps

That's a lot better -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c11 --- Comment #11 from Michael Andres --- The modaliases describe the hardware and are used to resolve kmps and driver packages supplementing the system. Assuming the hardware does not change that often, you can manually collect them. Maybe better than turning them off completely:

find /sys/ -type f -name modalias -print0 | xargs -0 cat | sort -u >/tmp/modaliases ZYPP_MODALIAS_SYSFS=/tmp/modaliases

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c13 --- Comment #13 from Benjamin Zeller --- As Michael said, the hardware information is used to resolve kmps and hardware specific packages like drivers. Packages can specifiy those as a modalias entry in the package spec so the solver can select them if hardware with the same modalias is found in /sys. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c15 --- Comment #15 from Benjamin Zeller ---

I'm not disputing that, though in CT's, the Kernel package is _not_ installed. How useful are those drivers but extra bloat? I'm not sure how you guys plan to mitigate this but as for now, openSUSE under LXC on proxmox is just not really very usable.

Cheers.

I did not say we won't look into it, but figuring out a good workaround might take some time, first we need to figure out a simple example to reproduce. If your container does not use any packages that are hardware dependant you could export the variable Michael mentioned and use it as a workaround for the time being. Or you collect the sysfs once on boot into a file in /tmp and just use that for all zypper runs. I wonder if the command: "find /sys/ -type f -name modalias -print0 | xargs -0 cat | sort -u >/tmp/modaliases" produces a similar behaviour to a zypper run in your container. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c17 --- Comment #17 from Michael Andres --- https://github.com/openSUSE/libzypp/pull/167 should at least mitigate the issue (less ::lstat calls, less memory usage). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1130161 http://bugzilla.opensuse.org/show_bug.cgi?id=1130161#c19 --- Comment #19 from Lutchy Horace --- time find /sys/ -type f -name modalias -print0 | xargs -0 cat | sort -u

/tmp/modaliases find: ‘/sys/kernel/slab/:A-0000192/cgroup/cred_jar(1070883:getty@lxc-tty2.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0000192/cgroup/cred_jar(1070888:getty@lxc-tty5.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0000192/cgroup/cred_jar(1070893:getty@lxc-tty3.service)’: No such file or directory find: ‘/sys/kernel/slab/sock_inode_cache/cgroup/sock_inode_cache(1070903:getty@lxc-tty4.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0000064/cgroup/pid(1070831:pvesr.service)’: No such file or directory find: ‘/sys/kernel/slab/anon_vma/cgroup/anon_vma(1070908:getty@lxc-tty1.service)’: No such file or directory find: ‘/sys/kernel/slab/anon_vma/cgroup/anon_vma(1070913:getty@lxc-tty2.service)’: No such file or directory find: ‘/sys/kernel/slab/anon_vma/cgroup/anon_vma(1070918:getty@lxc-tty5.service)’: No such file or directory find: ‘/sys/kernel/slab/anon_vma/cgroup/anon_vma(1070923:getty@lxc-tty3.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0002112/cgroup/mm_struct(1070451:pvesr.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0002112/cgroup/mm_struct(1070928:getty@lxc-tty6.service)’: No such file or directory find: ‘/sys/kernel/slab/:0000256/cgroup/kmalloc-256(1070938:getty@lxc-tty1.service)’: No such file or directory find: ‘/sys/kernel/slab/:0000256/cgroup/kmalloc-256(1070943:getty@lxc-tty2.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0000256/cgroup/filp(1070953:getty@lxc-tty3.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0000208/cgroup/vm_area_struct(1070958:getty@lxc-tty6.service)’: No such file or directory find: ‘/sys/kernel/slab/:A-0000208/cgroup/vm_area_struct(1070963:getty@lxc-tty4.service)’: No such file or directory find: ‘/sys/kernel/slab/:aA-0000192/cgroup/dentry(1070973:getty@lxc-tty2.service)’: No such file or directory find: ‘/sys/kernel/debug’: Permission denied

real 0m35.227s user 0m18.996s sys 0m15.842s The memory balloon marginally and stayed high for a bit. I'm guessing garbage collection hasn't kicked in yet at Kernel level. Though the differences is not as drastic as Zypper. -- You are receiving this mail because: You are on the CC list for the bug.