Как мне найти, почему отпечаток виртуальной памяти постоянно растет с этим демоном?

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

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

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

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

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

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

Есть некоторый вывод 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 байт. Не Gb утечек.)

Есть выход 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

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