Показатель «Использована память»: Перейти инструмент pprof vs docker stats

Question

Я написал приложение golang, запущенное в каждом из моих контейнеров-докеров. Он взаимодействует друг с другом с помощью protobufs через tcp и udp, и я использую библиотеку-член Hashicorp для поиска каждого из контейнеров в моей сети. В статистике докеров я вижу, что использование памяти линейно возрастает, поэтому я пытаюсь найти какие-либо утечки в своем приложении.

Поскольку это приложение, которое продолжает работать, я использую http pprof для проверки приложения в реальном времени в любом из контейнеров. Я вижу, что runtime.MemStats.sys постоянна, хотя статистика докеров линейно возрастает. My -inuse_space составляет около 1 МБ, а -alloc_space of the course продолжает расти с течением времени. Вот образец alloc_space:

root@n3:/app# go tool pprof --alloc_space main http://localhost:8080/debug/pprof/heap                              
Fetching profile from http://localhost:8080/debug/pprof/heap 
Saved profile in /root/pprof/pprof.main.localhost:8080.alloc_objects.alloc_space.005.pb.gz 
Entering interactive mode (type "help" for commands) 
(pprof) top --cum 
1024.11kB of 10298.19kB total (9.94%) 
Dropped 8 nodes (cum <= 51.49kB) 
Showing top 10 nodes out of 34 (cum >= 1536.07kB) 
     flat flat% sum%  cum cum% 
     0  0%  0% 10298.19kB 100% runtime.goexit 
     0  0%  0% 6144.48kB 59.67% main.Listener 
     0  0%  0% 3072.20kB 29.83% github.com/golang/protobuf/proto.Unmarshal 
    512.10kB 4.97% 4.97% 3072.20kB 29.83% github.com/golang/protobuf/proto.UnmarshalMerge 
     0  0% 4.97% 2560.17kB 24.86% github.com/hashicorp/memberlist.(*Memberlist).triggerFunc 
     0  0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).Unmarshal 
     0  0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).dec_struct_message 
     0  0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).unmarshalType 
    512.01kB 4.97% 9.94% 2048.23kB 19.89% main.SaveAsFile 
     0  0% 9.94% 1536.07kB 14.92% reflect.New 
(pprof) list main.Listener 
Total: 10.06MB 
ROUTINE ======================== main.Listener in /app/listener.go 
     0  6MB (flat, cum) 59.67% of Total 
     .   .  24: l.SetReadBuffer(MaxDatagramSize) 
     .   .  25: defer l.Close() 
     .   .  26: m := new(NewMsg) 
     .   .  27: b := make([]byte, MaxDatagramSize) 
     .   .  28: for { 
     . 512.02kB  29:  n, src, err := l.ReadFromUDP(b) 
     .   .  30:  if err != nil { 
     .   .  31:   log.Fatal("ReadFromUDP failed:", err) 
     .   .  32:  } 
     . 512.02kB  33:  log.Println(n, "bytes read from", src) 
     .   .  34:  //TODO remove later. For testing Fetcher only 
     .   .  35:  if rand.Intn(100) < MCastDropPercent { 
     .   .  36:   continue 
     .   .  37:  } 
     .  3MB  38:  err = proto.Unmarshal(b[:n], m) 
     .   .  39:  if err != nil { 
     .   .  40:   log.Fatal("protobuf Unmarshal failed", err) 
     .   .  41:  } 
     .   .  42:  id := m.GetHead().GetMsgId() 
     .   .  43:  log.Println("CONFIG-UPDATE-RECEIVED { \"update_id\" =", id, "}") 
     .   .  44:  //TODO check whether value already exists in store? 
     .   .  45:  store.Add(id) 
     .  2MB  46:  SaveAsFile(id, b[:n], StoreDir) 
     .   .  47:  m.Reset() 
     .   .  48: } 
     .   .  49:} 
(pprof) 

Я был в состоянии проверить, что никакой утечки goroutine не происходит с помощью HTTP: //: 8080/отладки/pprof/goroutine отлаживать = 1

Прокомментируйте почему статистика Докер показывает другую картину (линейно возрастающую память)

CONTAINER   CPU %    MEM USAGE/LIMIT  MEM %    NET I/O    BLOCK I/O   PIDS 
n3     0.13%    19.73 MiB/31.36 GiB 0.06%    595 kB/806 B  0 B/73.73 kB  14 

Если я запускаю его в течение ночи, эта память раздувает около 250MB. Я не запускал это дольше, чем это, но я чувствую, что это должно было достичь плато, а не увеличиваться линейно.

Answer 1

Статистика докеров показывает статистику использования памяти из групп. (См: https://docs.docker.com/engine/admin/runmetrics/)

Если вы читали "устаревший, но полезный" документацию (https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt) он говорит

5.5 usage_in_bytes

Для повышения эффективности, как и другие компоненты ядра, контрольная группа памяти использует некоторые оптимизации чтобы избежать ненужного общего доступа к кешине. use_in_bytes зависит от метода и не показывает «точный» значение использования памяти (и swap), это значение fuzz для эффективного доступа . (Конечно, когда это необходимо, оно синхронизировано.) Если вы хотите, чтобы знали более точное использование памяти, вы должны использовать значение RSS + CACHE (+ SWAP) в memory.stat (см. 5.2).

Страница Кэш и RES включены в номер использования памяти_in_bytes. Поэтому, если в контейнере есть файлы ввода/вывода, статистика использования памяти будет увеличиваться. Однако для контейнера, если использование достигает максимального предела, оно восстанавливает часть неиспользуемой памяти. Следовательно, когда я добавил ограничение на память для своего контейнера, я мог заметить, что память исправлена ​​и используется при достижении предела. Контейнерные процессы не уничтожаются, если нет памяти для восстановления и происходит ошибка OOM. Для всех, кто интересуется цифрами, показанными в статистике докеров, простой способ - проверить подробные статистические данные, доступные в группах по пути:/sys/fs/cgroup/memory/docker // Это подробно показывает все показатели памяти в памяти .stats или другие файлы памяти. *.

Если вы хотите, чтобы ограничить ресурсы, используемые контейнером Docker в команде «Докер выполнения» вы можете сделать это, следуя этой ссылке: https://docs.docker.com/engine/admin/resource_constraints/

Поскольку я использую Докер-сочинять, я сделал это, добавив линия в моей докер-сочинении.YML файл под службы я хотел ограничить:

mem_limit: 32m

где т стоит мегабайт.