2013-11-20 10 views
32

Esecuzione ultima versione di finestra mobile in cima ubuntu 13,04memoria limite relativo a un contenitore di finestra mobile non funziona

[email protected]:~# docker version 
Client version: 0.6.6 
Go version (client): go1.2rc3 
Git commit (client): 6d42040 
Server version: 0.6.6 
Git commit (server): 6d42040 
Go version (server): go1.2rc3 
Last stable version: 0.6.6 

Ma quando comincio il contenitore

[email protected]:~# docker run -m=1524288 -i -t ubuntu /bin/bash 
[email protected]:/# free -m 
      total  used  free  shared buffers  cached 
Mem:   1992  608  1383   0   30  341 
-/+ buffers/cache:  237  1755 
Swap:   2047   0  2047 

non vedo alcuna limitazione da qualsiasi tipo, e il mio kernel ha limite di memoria cgroup abilitato:

kernel /boot/vmlinuz-3.8.0-33-generic ro console=tty0 root=/dev/xvda1 cgroup_enable=memory swapaccount=1 

Quale cosa ovvia mi manca qui?

+0

A follow-up di questo, sto vedendo alcune differenze interessanti tra le app dockerized su un server virtualizzato contro una scatola di metallo grezzo. Ad esempio, OOM ucciderà Java in un server ubuntu virtualizzato che esegue il servizio Java nel contenitore. Tuttavia, su metallo - Java sta rispettando i limiti di memoria impostati tramite finestra mobile. [Non so ancora abbastanza sui dettagli di implementazione tra i due per buone conclusioni, volevo solo condividere] – nerdwaller

risposta

42

free non viene mostrato come questo viene applicato tramite cgroups. Invece sull'host (al di fuori del contenitore) è possibile controllare utilizzando /sysfs e la memoria cgroup

[email protected]:~$ docker run -m=524288 -d -t busybox sleep 3600 
f03a017b174f 
[email protected]:~$ cat /sys/fs/cgroup/memory/lxc/f03a017b174ff1022e0f46bc1b307658c2d96ffef1dd97e7c1929a4ca61ab80f//memory.limit_in_bytes 
524288 

a vederlo a corto di memoria che è possibile eseguire qualcosa che utilizzerà più memoria di quanto si alloca - ad esempio:

docker run -m=524288 -d -p 8000:8000 -t ubuntu:12.10 /usr/bin/python3 -m http.server 
8480df1d2d5d 
[email protected]:~$ docker ps | grep 0f742445f839 
[email protected]:~$ docker ps -a | grep 0f742445f839 
0f742445f839  ubuntu:12.10  /usr/bin/python3 -m 16 seconds ago  Exit 137        blue_pig 

In dmesg si dovrebbe vedere il contenitore e il processo uccisi:

[ 583.447974] Pid: 1954, comm: python3 Tainted: GF   O 3.8.0-33-generiC#48~precise1-Ubuntu 
[ 583.447980] Call Trace: 
[ 583.447998] [<ffffffff816df13a>] dump_header+0x83/0xbb 
[ 583.448108] [<ffffffff816df1c7>] oom_kill_process.part.6+0x55/0x2cf 
[ 583.448124] [<ffffffff81067265>] ? has_ns_capability_noaudit+0x15/0x20 
[ 583.448137] [<ffffffff81191cc1>] ? mem_cgroup_iter+0x1b1/0x200 
[ 583.448150] [<ffffffff8113893d>] oom_kill_process+0x4d/0x50 
[ 583.448171] [<ffffffff816e1cf5>] mem_cgroup_out_of_memory+0x1f6/0x241 
[ 583.448187] [<ffffffff816e1e7f>] mem_cgroup_handle_oom+0x13f/0x24a 
[ 583.448200] [<ffffffff8119000d>] ? mem_cgroup_margin+0xad/0xb0 
[ 583.448212] [<ffffffff811949d0>] ? mem_cgroup_charge_common+0xa0/0xa0 
[ 583.448224] [<ffffffff81193ff3>] mem_cgroup_do_charge+0x143/0x170 
[ 583.448236] [<ffffffff81194125>] __mem_cgroup_try_charge+0x105/0x350 
[ 583.448249] [<ffffffff81194987>] mem_cgroup_charge_common+0x57/0xa0 
[ 583.448261] [<ffffffff8119517a>] mem_cgroup_newpage_charge+0x2a/0x30 
[ 583.448275] [<ffffffff8115b4d3>] do_anonymous_page.isra.35+0xa3/0x2f0 
[ 583.448288] [<ffffffff8115f759>] handle_pte_fault+0x209/0x230 
[ 583.448301] [<ffffffff81160bb0>] handle_mm_fault+0x2a0/0x3e0 
[ 583.448320] [<ffffffff816f844f>] __do_page_fault+0x1af/0x560 
[ 583.448341] [<ffffffffa02b0a80>] ? vfsub_read_u+0x30/0x40 [aufs] 
[ 583.448358] [<ffffffffa02ba3a7>] ? aufs_read+0x107/0x140 [aufs] 
[ 583.448371] [<ffffffff8119bb50>] ? vfs_read+0xb0/0x180 
[ 583.448384] [<ffffffff816f880e>] do_page_fault+0xe/0x10 
[ 583.448396] [<ffffffff816f4bd8>] page_fault+0x28/0x30 
[ 583.448405] Task in /lxc/0f742445f8397ee7928c56bcd5c05ac29dcc6747c6d1c3bdda80d8e688fae949 killed as a result of limit of /lxc/0f742445f8397ee7928c56bcd5c05ac29dcc6747c6d1c3bdda80d8e688fae949 
[ 583.448412] memory: usage 416kB, limit 512kB, failcnt 342 
+0

grazie ora capisco; quindi il modo migliore è controllare la memoria di cgroup per vedere l'uso corrente. – Disco

+0

Qui puoi leggere di più sulle metriche di memoria 'cgroup' qui http://blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics/ In particolare lo pseudo-file' memory.stat' . –

+0

Grazie mille. Maggiori dettagli sulla configurazione di questo su Ubuntu https://github.com/dotcloud/docker/issues/4250 – Barry

20

Collegamenti a questo nice post su stressin g Utilizzo della memoria del contenitore. Ecco il riassunto, modificato un po 'di lavorare per finestra mobile invece di LXC generico:

contenitore lancio con un limite di memoria:

$ sudo docker -m 512M -it ubuntu /bin/bash 
root# apt-get update && apt-get install -y build-essential 

Creare un file foo.c all'interno del contenitore con il seguente

#include <stdlib.h> 
#include <stdio.h> 

int main(void) { 
    int i; 
    for (i=0; i<65536; i++) { 
     char *q = malloc(65536); 
     printf ("Malloced: %ld\n", 65536*i); 
    } 
    sleep(9999999); 
} 

Compilare il file

gcc -o foo foo.c 

Aprire una nuova ter minal per monitorare l'utilizzo della memoria del contenitore:

$ cd /sys/fs/cgroup/memory/lxc/{{containerID}} 
$ while true; do echo -n "Mem Usage (mb): " && expr `cat memory.usage_in_bytes`/1024/1024; echo -n "Mem+swap Usage (mb): " && expr `cat memory.limit_in_bytes`/1024/1024; sleep 1; done 

Avviare il consumo di memoria nel contenitore

$ ./foo 

Ora guardare il vostro contenitore di massimo fuori. Nota: quando si esaurisce la memoria, l'avvio di malloc fallisce, ma in caso contrario il contenitore viene lasciato inutilizzato. Normalmente il software all'interno del contenitore si arresta in modo anomalo a causa dei malfunzionamenti dei mallocs, ma il software resiliente continuerà a funzionare

Nota finale: il flag di Docker -m non conta swap e ram separatamente. Se si utilizza -m 512M, alcuni di questi 512 verranno scambiati, non RAM. Se si desidera che la RAM solo è necessario utilizzare direttamente le opzioni LXC (il che significa che sarà necessario eseguire finestra mobile con il driver esecuzione LXC invece di libcontainer)

# Same as docker -m 512m 
sudo docker run --lxc-conf="lxc.cgroup.memory.limit_in_bytes=512M" -it ubuntu /bin/bash 

# Set total to equal max RAM (e.g. don't use swap) 
sudo docker run --lxc-conf="lxc.cgroup.memory.max_usage_in_bytes=512M" --lxc-conf="lxc.cgroup.memory.limit_in_bytes=512M" -it ubuntu /bin/bash 

C'è una notevole differenza tra l'utilizzo di swap come parte del totale e non - con swap il programma foo sopra raggiunge ~ 450M velocemente e poi consuma lentamente il resto, mentre con solo RAM salta immediatamente a 511M per me.Con lo scambio il consumo di memoria del contenitore è segnato a ~ 60M non appena inserisco il container - questo è fondamentalmente lo swap che viene conteggiato come "utilizzo". Senza scambio il mio utilizzo della memoria è < 10M quando entro il contenitore

+1

Grazie per le chiare spiegazioni! – pygabriel

+0

Stavo cercando di far funzionare collectd e docker. Tuttavia, Collectd pubblica l'utilizzo della RAM del sistema generale (host) invece della memoria limitata della finestra mobile. http://stackoverflow.com/q/37881322/1925997 Mi chiedevo se questa opzione potesse essere d'aiuto, ma quando si esegue la finestra mobile con '--lxc-conf =" lxc.cgroup.memory.limit_in_bytes = 512M "' Sto finendo con 'flag fornito ma non definito: errore --lxc-conf'. Qualche idea su come risolvere questo? –

+0

Ottima risposta !, btw penso che manchi il cimmand 'run' nella prima riga di codice di esempio' '' sudo docker * run * -m 512M -it ubuntu/bin/bash''' – gsalgadotoledo

0

Se si utilizza una versione più recente di finestra mobile, quindi il posto per cercare queste informazioni è /sys/fs/cgroup/memory/docker/<container_id>/memory.limit_in_bytes:

docker run --memory="198m" redis 
docker ps --no-trunc` # to get the container long_id 
313105b341eed869bcc355c4b3903b2ede2606a8f1b7154e64f913113db8b44a 
cat /sys/fs/cgroup/memory/docker/313105b341eed869bcc355c4b3903b2ede2606a8f1b7154e64f913113db8b44a/memory.limit_in_bytes 
207618048 # in bytes 
Problemi correlati