Hi Herbert,
I tried kernel 4.1.27 with patch 2.3.8.5.2.
Now the "free" command inside the guest shows the assigned amount of memory to the guest.
But know it show always the same amount, also on line "-/+ buffers/cache":
...
linux-image-4.1.27-vs2.3.8.5.2-em64t-efigpt_1_amd64
...
root@dbserver:/ # free
total used free shared buffers cached
Mem: 50331648 29124200 21207448 0 0 0
-/+ buffers/cache: 29124200 21207448
Swap: 4194304 171660 4022644
...
Now it seems that the guest uses it's hole assigned memory and this triggers my monitoring.
Thanks
Urban
Am 02.02.2016 um 10:34 schrieb Herbert Poetzl:
> On Mon, Feb 01, 2016 at 03:02:28PM +0100, Urban Loesch wrote:
>> Hi,
>
> Hey Urban!
>
>> there is a small flaw inside the guest on kernel 4.1.13-vs2.3.8.3.
>
>> The "free" command shows the full memory of a host and not the
>> assigned amount, even if the "flags" file in
>> "/etc/vservers/$VSNAME/flags" is set like this:
>> ...
>> VIRT_MEM
>> VIRT_CPU
>> VIRT_LOAD
>> ...
>
>> Some other details:
>> kernel: 4.1.13-vs2.3.8.3
>> util-vserver:
>> ii libvserver0 0.30.216-pre3120-jessie0.1-1 amd64 dynamic libraries for util-vserver
>> ii util-vserver 0.30.216-pre3120-jessie0.1-1 amd64 utilities for managing Linux-VServer guests
>> ii util-vserver-build 0.30.216-pre3120-jessie0.1-1 amd64 tools which can be used to build vservers
>> ii util-vserver-core 0.30.216-pre3120-jessie0.1-1 amd64 core utilities of util-vserver
>> ii util-vserver-sysv 0.30.216-pre3120-jessie0.1-1 amd64 initscripts for util-vserver
>
>> Host-OS: Debian Jessie
>> Guest-OS: Debian etch oder higher. Also Jessie is affected.
>
>> The "top" command shows the correct assigned cpu eg. 14-15.
>> ...
>> top - 14:59:26 up 2 days, 20:25, 0 users, load average: 0.05, 0.07, 0.02
>> Tasks: 16 total, 2 running, 14 sleeping, 0 stopped, 0 zombie
>> Cpu14 : 1.7%us, 0.0%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>> Cpu15 : 1.5%us, 0.0%sy, 0.0%ni, 98.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>> Mem: 32935924k total, 32745520k used, 190404k free, 248248k buffers
>> Swap: 7811068k total, 8620k used, 7802448k free, 0k cached
>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
>> ...
>
> Thanks for reporting, but this is known, as the relevant
> code in the 4.1.x patches has not been adapted to the
> changes in the kernel (i.e. it is disabled for now)
>
>> All limits are assigned with cgroups.
>> Have you some idea how I can fix this?
>
> By adapting the relevant code (it is still there but
> disabled for now) to the changes in the kernel.
>
>> As I just said, this is not a real error, but only a flaw
>> that bothers me.
>
> Yeah, you are probably not the only one who misses this
> feature, I will see what I can do to get it working again.
>
> All the best,
> Herbert
>
>> Thanks and regards
>> Urban
>
>
Received on Fri Aug 19 11:25:42 2016