Как мне найти, почему отпечаток виртуальной памяти постоянно растет с этим демоном? - PullRequest
0 голосов
/ 03 октября 2018

Я создал демона, который я использую в качестве прокси для базы данных Cassandra.Я называю это snapdbproxy, так как он передает мои команды CQL от других моих серверов и инструментов.

Всякий раз, когда я получаю доступ к этому инструменту, он создает новый поток, управляет различными командами CQL, а затем я один раз чисто выхожу из потокасоединение потеряно.

Если посмотреть на объем памяти, то он очень быстро растет (самые активные системы быстро достигают Гб виртуальной памяти, и это использует некоторую подкачку памяти, которая постоянно увеличивается).около 300 МБ.

enter image description here

Программное обеспечение написано на C ++ с деструкторами, RAII, умными указателями и т. д. ... но я все еще проверял:

  1. С -fsanitizer=address (я использую g ++ под Linux), и я не получаю утечек (хорошо, очень мало ... меньше 300 байт, потому что я не могу найти, как избавиться от несколькихКрито-буферы, созданные OpenSSL)

  2. С массивом valgrind, который говорит, что я использую 4,7 мБ во время инициализации, а затем под 4 мегабайтами (я запускал один и тот же код более 1 часа и с теми же результатами!)

TherЭто некоторый вывод ms_print (я удалил стек, так как все нули).

-------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)
-------------------------------------------------------------------

  0              0                0                0             0
  1     78,110,172        4,663,704        4,275,532       388,172
  2    172,552,798        3,600,840        3,369,538       231,302
  3    269,590,806        3,611,600        3,379,648       231,952
  4    350,518,548        3,655,208        3,420,483       234,725
  5    425,873,410        3,653,856        3,419,390       234,466
...
 67  4,257,283,952        3,693,160        3,459,545       233,615
 68  4,302,665,173        3,694,624        3,460,827       233,797
 69  4,348,046,440        3,693,728        3,457,524       236,204
 70  4,393,427,319        3,685,064        3,449,697       235,367
 71  4,438,812,133        3,698,352        3,461,918       236,434

Как мы видим, после одного часа и множества обращений из различных других демонов (не менее 100 обращений,) valgrind говорит мне, что я использую только около 4 МБ памяти.Я дважды пытался подумать, что первая попытка, вероятно, не удалась.Те же результаты.

Итак ... У меня более или менее нет идей.Почему мой процесс продолжает расти с точки зрения виртуальной памяти, даже если все правильно освобождено при выходе из каждого потока - как показано в выводе массива - и всего процесса - как показано -fsanitizer=address (хорошо, яздесь не отображается вывод дезинфицирующего средства, но, поверьте мне, он меньше 300 байт. Не Гб утечек.)


Через некоторое время выводится команда watch, поскольку япросмотр состояния памяти (виртуальной памяти):

Every 1.0s: grep ^Vm /proc/1773/status       Tue Oct  2 21:36:42 2018

VmPeak:  1124060 kB   <-- starts at under 300 Mb...
VmSize:  1124060 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    108776 kB
VmRSS:    108776 kB
VmData:   963920 kB   <-- this tags along
VmStk:       132 kB
VmExe:      1936 kB
VmLib:     65396 kB
VmPTE:       888 kB   <-- this increases too (necessary to handle the large Vm)
VmPMD:        20 kB
VmSwap:        0 kB

VmPeak, VmSize и VmData увеличиваются при каждом запуске других демонов (примерно раз в 5 минут)

Однако память (malloc / free) не меняется.Сейчас я регистрирую sbrk(0) (по идее комментария 1201ProgramAlarm - моя интерпретация первой части его комментария), и этот адрес остается прежним:

sbrk() = 0x4228000

Как предложено phd,Я посмотрел на содержимое /proc/<pid>/maps с течением времени.Вот один или два шага.К сожалению, мне не сказали, что создает эти буферы.Единственное, о чем я могу думать, это мои темы ... (то есть стек и немного места для статуса потока)

--- a1  2018-10-02 21:50:21.887583577 -0700
+++ a2  2018-10-02 21:52:04.823169545 -0700
@@ -522,6 +522,10 @@
 59dd0000-5a5d0000 rw-p 00000000 00:00 0 
 5a5d0000-5a5d1000 ---p 00000000 00:00 0 
 5a5d1000-5add1000 rw-p 00000000 00:00 0 
+5add1000-5add2000 ---p 00000000 00:00 0 
+5add2000-5b5d2000 rw-p 00000000 00:00 0 
+5b5d2000-5b5d3000 ---p 00000000 00:00 0 
+5b5d3000-5bdd3000 rw-p 00000000 00:00 0 
 802001000-802b8c000 rwxp 00000000 00:00 0 
 802b8c000-802b8e000 ---p 00000000 00:00 0 
 802b8e000-802c8e000 rwxp 00000000 00:00 0 

О ... Да!Мои последние изменения от отсоединения потоков до присоединения ... фактически вообще не присоединяются к потокам.Тестирование с правильным соединением сейчас ... и это работает правильно!Мои!Плохой!

...