Re: [lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Saint Michael]

I have a lot of memory management issues using pure LXC. In my case, my box
has only one container. I use LXC to be able to move my app around, not to
squeeze performance out of hardware. What happens is my database gets
killed the OOM manager, although there are gigabytes of RAM used for cache.
The memory manager kills applications instead of reclaiming memory from
disc cache. How can this be avoided?

My config at the host is:

vm.hugepages_treat_as_movable=0
vm.hugetlb_shm_group=27
vm.nr_hugepages=2500
vm.nr_hugepages_mempolicy=2500
vm.nr_overcommit_hugepages=0
vm.overcommit_memory=0
vm.swappiness=0
vm.vfs_cache_pressure=150
vm.dirty_ratio=10
vm.dirty_background_ratio=5

This shows the issue
[9449866.130270] Node 0 hugepages_total=1250 hugepages_free=1250
hugepages_surp=0 hugepages_size=2048kB
[9449866.130271] Node 1 hugepages_total=1250 hugepages_free=1248
hugepages_surp=0 hugepages_size=2048kB
[9449866.130271] 46181 total pagecache pages
[9449866.130273] 33203 pages in swap cache
[9449866.130274] Swap cache stats: add 248571542, delete 248538339, find
69031185/100062903
[9449866.130274] Free swap  = 0kB
[9449866.130275] Total swap = 8305660kB
[9449866.130276] 20971279 pages RAM
[9449866.130276] 0 pages HighMem/MovableOnly
[9449866.130276] 348570 pages reserved
[9449866.130277] 0 pages cma reserved
[9449866.130277] 0 pages hwpoisoned
[9449866.130278] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds
swapents oom_score_adj name
[9449866.130286] [  618] 0   61887181  135 168   3
   3 0 systemd-journal
[9449866.130288] [  825] 0   82511343  130  25   3
   0 0 systemd-logind
[9449866.130289] [  830] 0   830 1642   31   8   3
   0 0 mcelog
[9449866.130290] [  832]   996   83226859   51  23   3
  47 0 chronyd
[9449866.130292] [  834] 0   834 4905  100  12   3
   0 0 irqbalance
[9449866.130293] [  835] 0   835 6289  177  15   3
   0 0 smartd
[9449866.130295] [  837]81   83728499  258  28   3
 149  -900 dbus-daemon
[9449866.130296] [  857] 0   857 1104   16   7   3
   0 0 rngd
[9449866.130298] [  859] 0   859   19246337114 224   4
 40630 0 NetworkManager
[9449866.130300] [  916] 0   91625113  229  50   3
   0 -1000 sshd
[9449866.130302] [  924] 0   924 6490   50  17   3
   0 0 atd
[9449866.130303] [  929] 0   92935327  199  20   3
 284 0 agetty
[9449866.130305] [  955] 0   95522199 3185  43   3
 312 0 dhclient
[9449866.130307] [ 1167] 0  1167 6125   88  17   3
   2 0 lxc-autostart
[9449866.130309] [ 1176] 0  117610818  275  24   3
  38 0 systemd
[9449866.130310] [ 1188] 0  118813303 1980  29   3
  36 0 systemd-journal
[9449866.130312] [ 1372]99  1372 38812  12   3
  45 0 dnsmasq
[9449866.130313] [ 1375]81  1375 6108   77  17   3
  39  -900 dbus-daemon
[9449866.130315] [ 1394] 0  1394 6175   46  15   3
 168 0 systemd-logind
[9449866.130316] [ 1395] 0  139578542 1142  69   3
   4 0 rsyslogd
[9449866.130317] [ 1397] 0  1397 1614   32   8   3
   0 0 agetty
[9449866.130319] [ 1398] 0  1398 1614   31   8   3
   0 0 agetty
[9449866.130320] [ 1400] 0  1400 1614   31   8   3
   0 0 agetty
[9449866.130321] [ 1401] 0  1401 16142   8   3
  30 0 agetty
[9449866.130322] [ 1402] 0  1402 16142   8   3
  29 0 agetty
[9449866.130324] [ 1403] 0  1403 1614   31   8   3
   0 0 agetty
[9449866.130325] [ 1404] 0  1404 1614   32   8   3
   0 0 agetty
[9449866.130327] [ 1405] 0  1405 1614   32   8   3
   0 0 agetty
[9449866.130328] [ 1406] 0  1406 16142   8   3
  29 0 agetty
[9449866.130329] [ 1408] 0  1408 16142   8   3
  30 0 agetty
[9449866.130330] [ 1409] 0  1409 1614   30   7   3
   0 0 agetty
[9449866.130332] [18224] 0 18224264560  43   4
 404 0 VGAuthService
[9449866.130333] [18225] 0 1822561032   95  58   3
 258 0 vmtoolsd
[9449866.130335] [28660] 0 2866026372   44  54   4
 202 -1000 sshd
[9449866.130337] [18992]   998 18992   132859  876  54   3
  13 0 polkitd
[9449866.130339] [23849] 0 2384910744  370  23   3
 

Re: [lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Fajar A. Nugraha]

On Sat, Jul 15, 2017 at 10:48 PM, Ron Kelley  wrote:

> Thanks for the great replies.
>
> Marat/Fajar:  How many servers do you guys have running in production, and
> what are their characteristics (RAM, CPU, workloads, etc)?


My biggest production one was AWS r4.16xlarge (almost 500GB memory), though
nowadays I mostly use r3.8xlarge (around half the memory, but more
cost-efficient). It's running many things from small web servers to large
hadoop instances.

My smallest production system had 16GB RAM. After some struggles (including
testing if swap would help, which did not), in the end I increase its RAM
to 128GB. MUCH better.


> I am trying to see if our systems generally align to what you are
> running.  Running without swap seems rather drastic and removes the “safety
> net” in the case of a bad program.


Which is why I mentioned setting the limits beforehand.

For a memory-limited system, you should be able to follow
http://digitaloceanvps.blogspot.co.id/2014/04/best-configuration-for-512mb-1gb-ram.html
or similar. Though since you said you use nginx, instead of setting appache
you should be able to just set php-fpm to use on-demand process manager
with a small (2-4) max process.


> In the end, we must have all containers/processes running 24/7.
>

Which is EXACTLY why I disable swap. I do NOT want a misconfigured
container dragging others down. And when you configure the applications
correctly, each container should stay within its limited memory. Things
like 'sudden spike in user access' would slow it down (e.g. due to waiting
for php-fpm process becomes available) but it would not create a spike in
memory usage.


> tldr;
> 
> After digging into this a bit, it seems “top”, “top”, and “free” report
> similar swap usage, however, other tools report much less swap usage.  I
> found the following threads on the ‘net which include simple scripts to
> look in /proc and examine swap usage per process:
>
> https://stackoverflow.com/questions/479953/how-to-find-
> out-which-processes-are-swapping-in-linux
> https://www.cyberciti.biz/faq/linux-which-process-is-using-swap
>
> As some people pointed out, top/htop don’t accurately report the swap
> usage as they combine a number of memory fields together.  And, indeed,
> running the script in each container (looking at /proc) show markedly
> different results when all the numbers are added up.  For example, the
> “free” command on one of our servers reports 3G of swap in use, but the
> script that scans the /proc directory only shows 1.3G of real swap in use.
> Very odd.
>
> All that said, the real issue is to find out if one of our
> containers/processes has a memory leak (per Marat’s suggestion below).
> Unfortunately, LXD does not provide an easy way to track per-container
> stats, thus we must “roll our own” tools.
>
>
/proc/meminfo (and some other files) in the container is fake. It's created
by lxcfs, using numbers from cgroup.
cgroup would generally provide accurate info (e.g. 'how much memory is used
by processes under this cgroup'). If you're rolling your own tools, read
cgroup files directly (e.g. /sys/fs/cgroup/memory/lxc/ ...).

In any case, if your tools show memory usage in a container higher than its
configured limit, then its perfectly normal that it starts to swap. Even
when the host itself still have lots of memory.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Marat Khalili]

Marat/Fajar:  How many servers do you guys have running in production, and what 
are their characteristics (RAM, CPU, workloads, etc)?
I have to admit I'm not running a farm; I administer a few, but they are 
all different depending on task. Still, even smallest has 64GB RAM. In 
2017 the 8GB is small even for user notebook IMO.



After digging into this a bit, it seems “top”, “top”, and “free” report similar 
swap usage, however, other tools report much less swap usage.
Yes, this is known, they got confused in containers. Run them on host to 
produce more meaningful results.



All that said, the real issue is to find out if one of our containers/processes 
has a memory leak (per Marat’s suggestion below).  Unfortunately, LXD does not 
provide an easy way to track per-container stats, thus we must “roll our own” 
tools.


Here's a typical top output (on the host system with 19 LXC containers 
currently running):


top - 16:00:01 up 12 days, 10:35,  5 users,  load average: 0.67, 0.58, 
0.61

Tasks: 501 total,   2 running, 499 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.8 us,  1.4 sy,  0.0 ni, 91.5 id,  1.1 wa,  0.0 hi,  0.2 
si,  0.0 st
KiB Mem : 65853268 total,   379712 free,  8100284 used, 57373272 
buff/cache
KiB Swap: 24986931+total, 24782081+free,  2048496 used. 56852384 avail 
Mem


  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ 
COMMAND
 6671 root  20   0 5450952 3.728g   1564 S   0.3 5.9  93:14.29 
qemu-system-x86
 6670 root  20   0 5411084 2.073g   1456 S   0.0 3.3  33:32.07 
qemu-system-x86
 6979 999   20   0 5251132 244532  19436 S   0.0 0.4 101:47.88 
drwcsd.real

 4338 lxd   20   0 1968400 229004   8052 S   5.3 0.3 639:52.03 mysqld
 8135 root  20   0 6553852 198224   4280 S   0.0 0.3  41:52.66 java
 4231 root  20   0  150072  99596  99472 S   0.0 0.2   0:19.43 
systemd-journal 
It shows all processes, including those running in containers (first 5 
are). I sorted by RES/%RAM; in your case I'd also try sorting by VIRT. I 
don't know how to directly find process that occupies much swap, but 
most likely it will have high RES and VIRT values too. As soon as you 
find problem processes, it is trivial to find container they run in with 
ps -AFH or pstree -p on the host system. (Note, that user names and PIDs 
are different inside and outside of containers, don't rely on them.)


I don't have much experience with LXD, but I suppose it's same in this 
aspect.


--

With Best Regards,
Marat Khalili

On 15/07/17 18:48, Ron Kelley wrote:

Thanks for the great replies.

Marat/Fajar:  How many servers do you guys have running in production, and what 
are their characteristics (RAM, CPU, workloads, etc)?  I am trying to see if 
our systems generally align to what you are running.  Running without swap 
seems rather drastic and removes the “safety net” in the case of a bad program. 
 In the end, we must have all containers/processes running 24/7.

tldr;

After digging into this a bit, it seems “top”, “top”, and “free” report similar 
swap usage, however, other tools report much less swap usage.  I found the 
following threads on the ‘net which include simple scripts to look in /proc and 
examine swap usage per process:

https://stackoverflow.com/questions/479953/how-to-find-out-which-processes-are-swapping-in-linux
https://www.cyberciti.biz/faq/linux-which-process-is-using-swap

As some people pointed out, top/htop don’t accurately report the swap usage as 
they combine a number of memory fields together.  And, indeed, running the 
script in each container (looking at /proc) show markedly different results 
when all the numbers are added up.  For example, the “free” command on one of 
our servers reports 3G of swap in use, but the script that scans the /proc 
directory only shows 1.3G of real swap in use.  Very odd.

All that said, the real issue is to find out if one of our containers/processes 
has a memory leak (per Marat’s suggestion below).  Unfortunately, LXD does not 
provide an easy way to track per-container stats, thus we must “roll our own” 
tools.



-Ron





On Jul 15, 2017, at 5:11 AM, Marat Khalili  wrote:

I'm using LXC, and I frequently observe some unused containers get swapped out, 
even though system has plenty of RAM and no RAM limits are set. The only bad 
effect I observe is couple of seconds delay when you first log into them after 
some time. I guess it is absolutely normal since kernel tries to maximize 
amount of memory available for disk caches.

If you don't like this behavior, instead of trying to fine tune kernel 
parameters why not disable swap altogether? Many people run it this way, it's 
mostly a matter of taste these days. (But first check your software for leaks.)


For example, our “server-4” machine shows 8G total RAM, 500MB free, 2.5G 
available, and 5G of buff/cache. Yet, swap is at 5.5GB and has been slowly 
growing over the past few days. It seems something is preventing the apps from 
using the 

Re: [lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Ron Kelley]

Thanks for the great replies.  

Marat/Fajar:  How many servers do you guys have running in production, and what 
are their characteristics (RAM, CPU, workloads, etc)?  I am trying to see if 
our systems generally align to what you are running.  Running without swap 
seems rather drastic and removes the “safety net” in the case of a bad program. 
 In the end, we must have all containers/processes running 24/7.

tldr;

After digging into this a bit, it seems “top”, “top”, and “free” report similar 
swap usage, however, other tools report much less swap usage.  I found the 
following threads on the ‘net which include simple scripts to look in /proc and 
examine swap usage per process:

https://stackoverflow.com/questions/479953/how-to-find-out-which-processes-are-swapping-in-linux
https://www.cyberciti.biz/faq/linux-which-process-is-using-swap 

As some people pointed out, top/htop don’t accurately report the swap usage as 
they combine a number of memory fields together.  And, indeed, running the 
script in each container (looking at /proc) show markedly different results 
when all the numbers are added up.  For example, the “free” command on one of 
our servers reports 3G of swap in use, but the script that scans the /proc 
directory only shows 1.3G of real swap in use.  Very odd.

All that said, the real issue is to find out if one of our containers/processes 
has a memory leak (per Marat’s suggestion below).  Unfortunately, LXD does not 
provide an easy way to track per-container stats, thus we must “roll our own” 
tools.



-Ron




> On Jul 15, 2017, at 5:11 AM, Marat Khalili  wrote:
> 
> I'm using LXC, and I frequently observe some unused containers get swapped 
> out, even though system has plenty of RAM and no RAM limits are set. The only 
> bad effect I observe is couple of seconds delay when you first log into them 
> after some time. I guess it is absolutely normal since kernel tries to 
> maximize amount of memory available for disk caches.
> 
> If you don't like this behavior, instead of trying to fine tune kernel 
> parameters why not disable swap altogether? Many people run it this way, it's 
> mostly a matter of taste these days. (But first check your software for 
> leaks.)
> 
> > For example, our “server-4” machine shows 8G total RAM, 500MB free, 2.5G 
> > available, and 5G of buff/cache. Yet, swap is at 5.5GB and has been slowly 
> > growing over the past few days. It seems something is preventing the apps 
> > from using the RAM.
> 
> Did you identify what processes all this virtual memory belongs to?
> 
> > To be honest, we have been battling lots of memory/swap issues using LXD. 
> > We started with no tuning, but the app stack quickly ran out of memory. 
> 
> LXC/LXD is hardly responsible for your app stack memory usage. Either you 
> underestimated it or there's a memory leak somewhere.
> 
> > Given all the issues we have had with memory and swap using LXD, we are 
> > seriously considering moving back to the traditional VM approach until 
> > LXC/LXD is better “baked”.
> 
> Did your VMs use less memory? I don't think so. Limits could be better 
> enforced, but VMs don't magically give you infinite RAM. 
> -- 
> 
> With Best Regards,
> Marat Khalili
> 
> On July 14, 2017 9:58:57 PM GMT+03:00, Ron Kelley  
> wrote:
> Wondering if anyone else has similar issues.
> 
> We have 5x LXD 2.12 servers running (U16.04 - kernel 4.4.0-57-generic - 8G 
> RAM, 19G SWAP).  Each server is running about 50 LXD containers - Wordpress 
> w/Nginx and PHP7.  The servers have been running for about 15 days now, and 
> swap space continues to grow.  In addition, the kswapd0 process starts 
> consuming CPU until we flush the system cache via "/bin/echo 3 > 
> /proc/sys/vm/drop_caches” command.
> 
> Our LXD profile looks like this:
> -
> config:
>   limits.cpu: "2"
>   limits.memory: 512MB
>   limits.memory.swap: "true"
>   limits.memory.swap.priority: "1"
> -
> 
> 
> We also have added these to /etc/sysctl.conf
> -
> vm.swappiness=10
> vm.vfs_cache_pressure=50
> -
> 
> A quick “top” output shows plenty of available Memory and buff/cache.  But, 
> for some reason, the system continues to swap out the app.  For example, our 
> “server-4” machine shows 8G total RAM, 500MB free, 2.5G available, and 5G of 
> buff/cache.  Yet, swap is at 5.5GB and has been slowly growing over the past 
> few days.  It seems something is preventing the apps from using the RAM.
> 
> 
> To be honest, we have been battling lots of memory/swap issues using LXD.  We 
> started with no tuning, but the app stack quickly ran out of memory.  After 
> editing the profile to allow 512MB RAM per container (and restarting the 
> container), the kswapd0 issue happens.  Given all the issues we have had with 
> memory and swap using LXD, we are seriously considering moving back to the 
> traditional VM approach 

Re: [lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Marat Khalili]

I'm using LXC, and I frequently observe some unused containers get swapped out, 
even though system has plenty of RAM and no RAM limits are set. The only bad 
effect I observe is couple of seconds delay when you first log into them after 
some time. I guess it is absolutely normal since kernel tries to maximize 
amount of memory available for disk caches.

If you don't like this behavior, instead of trying to fine tune kernel 
parameters why not disable swap altogether? Many people run it this way, it's 
mostly a matter of taste these days. (But first check your software for leaks.)

> For example, our “server-4” machine shows 8G total RAM, 500MB free, 2.5G 
> available, and 5G of buff/cache. Yet, swap is at 5.5GB and has been slowly 
> growing over the past few days. It seems something is preventing the apps 
> from using the RAM.

Did you identify what processes all this virtual memory belongs to?

> To be honest, we have been battling lots of memory/swap issues using LXD. We 
> started with no tuning, but the app stack quickly ran out of memory. 

LXC/LXD is hardly responsible for your app stack memory usage. Either you 
underestimated it or there's a memory leak somewhere.

> Given all the issues we have had with memory and swap using LXD, we are 
> seriously considering moving back to the traditional VM approach until 
> LXC/LXD is better “baked”.

Did your VMs use less memory? I don't think so. Limits could be better 
enforced, but VMs don't magically give you infinite RAM. 
-- 

With Best Regards,
Marat Khalili

On July 14, 2017 9:58:57 PM GMT+03:00, Ron Kelley  wrote:
>Wondering if anyone else has similar issues.
>
>We have 5x LXD 2.12 servers running (U16.04 - kernel 4.4.0-57-generic -
>8G RAM, 19G SWAP).  Each server is running about 50 LXD containers -
>Wordpress w/Nginx and PHP7.  The servers have been running for about 15
>days now, and swap space continues to grow.  In addition, the kswapd0
>process starts consuming CPU until we flush the system cache via
>"/bin/echo 3 > /proc/sys/vm/drop_caches” command.
>
>Our LXD profile looks like this:
>-
>config:
>  limits.cpu: "2"
>  limits.memory: 512MB
>  limits.memory.swap: "true"
>  limits.memory.swap.priority: "1"
>-
>
>
>We also have added these to /etc/sysctl.conf
>-
>vm.swappiness=10
>vm.vfs_cache_pressure=50
>-
>
>A quick “top” output shows plenty of available Memory and buff/cache. 
>But, for some reason, the system continues to swap out the app.  For
>example, our “server-4” machine shows 8G total RAM, 500MB free, 2.5G
>available, and 5G of buff/cache.  Yet, swap is at 5.5GB and has been
>slowly growing over the past few days.  It seems something is
>preventing the apps from using the RAM.
>
>
>To be honest, we have been battling lots of memory/swap issues using
>LXD.  We started with no tuning, but the app stack quickly ran out of
>memory.  After editing the profile to allow 512MB RAM per container
>(and restarting the container), the kswapd0 issue happens.  Given all
>the issues we have had with memory and swap using LXD, we are seriously
>considering moving back to the traditional VM approach until LXC/LXD is
>better “baked”.
>
>
>-Ron
>___
>lxc-users mailing list
>lxc-users@lists.linuxcontainers.org
>http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Fajar A. Nugraha]

On Sat, Jul 15, 2017 at 1:58 AM, Ron Kelley  wrote:

> Wondering if anyone else has similar issues.
>
> We have 5x LXD 2.12 servers running (U16.04 - kernel 4.4.0-57-generic - 8G
> RAM, 19G SWAP).  Each server is running about 50 LXD containers - Wordpress
> w/Nginx and PHP7.  The servers have been running for about 15 days now, and
> swap space continues to grow.  In addition, the kswapd0 process starts
> consuming CPU until we flush the system cache via "/bin/echo 3 >
> /proc/sys/vm/drop_caches” command.
>
> Our LXD profile looks like this:
> -
> config:
>   limits.cpu: "2"
>   limits.memory: 512MB
>   limits.memory.swap: "true"
>   limits.memory.swap.priority: "1"
> -
>
>
> We also have added these to /etc/sysctl.conf
> -
> vm.swappiness=10
> vm.vfs_cache_pressure=50
> -
>
> A quick “top” output shows plenty of available Memory and buff/cache.


On the host?

What does top/htop show on the container?


> But, for some reason, the system continues to swap out the app.  For
> example, our “server-4” machine shows 8G total RAM, 500MB free, 2.5G
> available, and 5G of buff/cache.  Yet, swap is at 5.5GB and has been slowly
> growing over the past few days.  It seems something is preventing the apps
> from using the RAM.
>
>
Even if the host has ample RAM, containers won't be able to use it if their
usage is over the limit. Hence why I asked for htop in the container.


>
> To be honest, we have been battling lots of memory/swap issues using LXD.
> We started with no tuning, but the app stack quickly ran out of memory.
> After editing the profile to allow 512MB RAM per container (and restarting
> the container), the kswapd0 issue happens.  Given all the issues we have
> had with memory and swap using LXD, we are seriously considering moving
> back to the traditional VM approach until LXC/LXD is better “baked”.
>
>
>

In the end use whatever works for you.

I've had enough problems with swap in the past (non-lxc setup) that
nowadays I simply disable swap altogether, and configure my apps (e.g. set
max connection, max concurrent process, etc) to be able to live with what
they have.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] LXD 2.14 - Ubuntu 16.04 - kernel 4.4.0-57-generic - SWAP continuing to grow

[Ron Kelley]

Wondering if anyone else has similar issues.

We have 5x LXD 2.12 servers running (U16.04 - kernel 4.4.0-57-generic - 8G RAM, 
19G SWAP).  Each server is running about 50 LXD containers - Wordpress w/Nginx 
and PHP7.  The servers have been running for about 15 days now, and swap space 
continues to grow.  In addition, the kswapd0 process starts consuming CPU until 
we flush the system cache via "/bin/echo 3 > /proc/sys/vm/drop_caches” command.

Our LXD profile looks like this:
-
config:
  limits.cpu: "2"
  limits.memory: 512MB
  limits.memory.swap: "true"
  limits.memory.swap.priority: "1"
-


We also have added these to /etc/sysctl.conf
-
vm.swappiness=10
vm.vfs_cache_pressure=50
-

A quick “top” output shows plenty of available Memory and buff/cache.  But, for 
some reason, the system continues to swap out the app.  For example, our 
“server-4” machine shows 8G total RAM, 500MB free, 2.5G available, and 5G of 
buff/cache.  Yet, swap is at 5.5GB and has been slowly growing over the past 
few days.  It seems something is preventing the apps from using the RAM.


To be honest, we have been battling lots of memory/swap issues using LXD.  We 
started with no tuning, but the app stack quickly ran out of memory.  After 
editing the profile to allow 512MB RAM per container (and restarting the 
container), the kswapd0 issue happens.  Given all the issues we have had with 
memory and swap using LXD, we are seriously considering moving back to the 
traditional VM approach until LXC/LXD is better “baked”.


-Ron
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users