<div dir="ltr"><div class="gmail_default" style="font-size:small">Very important question<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 9:18 PM, Ivan Kurnosov <span dir="ltr"><<a href="mailto:zerkms@zerkms.ru" target="_blank">zerkms@zerkms.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Hi,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">there is a server that currently runs ~100 containers.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">One of those containers is a subject of my interest.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Brief details about the container: it runs ubuntu xenial, and it's a tiny file server (samba based) with near to no traffic at all.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I have found that after you upload files to that server, the available memory size is decreased (while the "buff/cache" size stays at 0). And if you remove the just uploaded files - the memory consumption drops to the same value as it was before uploading.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Here is a output of the top (sorted by resident memory size, processes with more than 500kib rss):</div><div style="font-size:12.8px"><br></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px"><div> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND</div><div> 48 root 20 0 52048 18880 14428 S 0.0 0.9 0:10.11 /lib/systemd/systemd-journald</div><div>18609 www-data 20 0 349208 15404 7516 S 0.0 0.7 0:13.72 /usr/sbin/smbd -D</div><div> 7176 www-data 20 0 345500 10720 6720 S 6.7 0.5 0:06.91 /usr/sbin/smbd -D</div><div>25124 root 20 0 340104 9624 6744 S 0.0 0.5 0:00.12 /usr/sbin/smbd -D</div><div>37541 root 20 0 344828 8012 4520 S 0.0 0.4 0:02.36 /usr/sbin/smbd -D</div><div>15593 root 20 0 344352 6368 3444 S 0.0 0.3 0:00.39 /usr/sbin/smbd -D</div><div> 2450 root 20 0 336636 4072 1520 S 0.0 0.2 0:06.09 /usr/sbin/smbd -D</div><div>25401 root 20 0 40560 3728 3112 R 0.3 0.2 0:00.49 top</div><div> 2447 root 20 0 336636 3528 976 S 0.0 0.2 0:04.30 /usr/sbin/smbd -D</div><div>25287 root 20 0 19972 3044 2872 S 0.0 0.1 0:00.01 bash</div><div> 2476 root 20 0 238728 2944 1336 S 0.0 0.1 0:28.52 /usr/sbin/nmbd -D</div><div>25271 ivan 20 0 21328 2784 2764 S 0.0 0.1 0:00.04 -bash</div><div>24250 root 20 0 858936 2616 0 S 0.0 0.1 0:01.98 /usr/sbin/collectd</div><div> 2448 root 20 0 426848 2504 20 S 0.3 0.1 0:01.65 /usr/sbin/smbd -D</div><div> 1 root 20 0 37884 2488 1676 S 0.0 0.1 0:17.13 /sbin/init</div><div>25285 root 20 0 51660 2404 2400 S 0.0 0.1 0:00.00 sudo su</div><div>25270 ivan 20 0 95368 2172 1960 S 0.0 0.1 0:00.24 sshd: ivan@pts/0</div><div>25286 root 20 0 51008 1908 1908 S 0.0 0.1 0:00.00 su</div><div> 8041 zabbix 20 0 95520 1680 1512 S 0.0 0.1 0:02.10 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]</div><div>25240 root 20 0 95368 1620 1572 S 0.0 0.1 0:00.02 sshd: ivan [priv]</div><div> 145 message+ 20 0 42892 1164 872 S 0.0 0.1 0:01.55 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation</div><div> 6453 www-data 20 0 125348 1152 656 S 0.0 0.1 0:32.26 nginx: worker process</div><div>20811 postfix 20 0 67640 1136 656 S 0.0 0.1 0:00.86 qmgr -l -t unix -u</div><div> 8038 zabbix 20 0 95520 1084 880 S 0.0 0.1 0:01.04 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]</div><div> 8039 zabbix 20 0 95520 972 768 S 0.0 0.0 0:01.05 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]</div><div> 142 root 20 0 27732 924 636 S 0.0 0.0 0:05.32 /usr/sbin/cron -f</div><div> 8040 zabbix 20 0 95520 872 668 S 0.0 0.0 0:01.07 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]</div><div> 8037 zabbix 20 0 93444 728 628 S 0.0 0.0 0:14.57 /usr/sbin/zabbix_agentd: collector [idle 1 sec]</div><div> 6462 www-data 20 0 125348 500 0 S 0.0 0.0 0:32.14 nginx: worker process</div></blockquote><div style="font-size:12.8px"><div><br></div><div><br></div><div>As you can see - the cumulative RSS is could barely get to the 100mb.</div><div><br></div><div>While this is what `free` returns:</div><div><br></div></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px"><div># free -m</div><div> total used free shared buff/cache available</div><div>Mem: 2048 1785 261 1750 0 261</div><div>Swap: 512 14 497</div></blockquote><div style="font-size:12.8px"><div><br></div><div>So, it clearly states about 85% of ram is occupied.</div><div><br></div><div>`slabtop` (due to cgroup limitations?) does not work:</div><div><br></div></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px"><div># slabtop</div><div>fopen /proc/slabinfo: Permission denied</div></blockquote><div style="font-size:12.8px"><div><br></div><div>But if I clear the system caches on the host</div><div><br></div></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px">echo 3 > /proc/sys/vm/drop_caches </blockquote><div style="font-size:12.8px"><div><br></div><div>the container memory consumption drops to the expected <100mb.</div><div><br></div><div>So the question, how to monitor the memory consumption from the container reliably? And why does `free` count caches as used memory inside container?</div></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_-5021830146195096962gmail_signature">With best regards, Ivan Kurnosov</div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.<wbr>linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank" rel="noreferrer">http://lists.linuxcontainers.<wbr>org/listinfo/lxc-users</a><br></blockquote></div><br></div>