Аэроспайк, отнимающий много памяти - PullRequest
Новая
       9

Аэроспайк, отнимающий много памяти

0 голосов
/ 29 сентября 2018

Aerospike Community Edition build 3.12.0

У нас есть кластер из 32 узлов с одним пространством имен, имеющим несколько наборов.В журналах я вижу следующее:

29 сентября 2018 15:36:21 GMT + 0530: INFO (информация): (ticker.c: 462) {myNamespace} использование памяти: всего байт 23816040182index-bytes 3222810368 sindex-bytes 0 байтов данных 20593229814 used-pct 49.29

29 сентября 2018 15:36:21 GMT + 0530: INFO (информация): (ticker.c: 170) NODE-ID bb99a89200a0102CLUSTER-SIZE 32

29 сентября 2018 15:36:21 GMT + 0530: INFO (информация): (ticker.c: 253) системная память: свободные килобайты 5095788 free-pct 9 кучных килобайт (30851170,49358076,52596736) куча-эффективность-pct 58,7

29 сентября 2018 15:36:21 GMT + 0530: INFO (информация): (ticker.c: 267) в процессе: tsvc-q 0info-q 0 nsup-delete-q 0 rw-hash 0 proxy-hash 0 tree-gc-q 0

Итак, я понимаю, что это имеет (23816040182 + 3222810368) = 27038850550 байт т.е. 27G.У меня 52G RAM на коробке, но процесс аэроспайк использует 90% RAM: 

>ps aux  | grep asd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND    
root     28994 14.3 90.5 59059460 49552192 ?   Ssl  Jun22 20539:09 /usr/bin/asd --config-file /etc/aerospike/aerospike.conf


>free -mh
             total       used       free     shared    buffers     cached
Mem:           52G        51G       303M         0B        12M       3.7G
-/+ buffers/cache:        48G       4.0G
Swap:           0B         0B         0B

Для того же узла я вижу следующее в пользовательском интерфейсе:

enter image description here

Итак, индекс Data + составляет всего 27 ГБ, а используемая память - 49 ГБ.Не в состоянии понять это огромное различие и как избежать таких сценариев.

Мы также удалили около 120 миллионов строк, но все еще не так много улучшений с точки зрения использования памяти, кажется, только перезагружается окно. Это может бытьсвязанные с этим проблема .

1 Ответ

0 голосов
/ 29 сентября 2018

Кажется, что ваша память на самом деле фрагментирована, но давайте разберем различные числа:

1- memory-usage: total-bytes 23816040182 index-bytes 3222810368 sindex-bytes 0 data-bytes 20593229814 used-pct 49.29

Общий объем памяти составляет 23816040182 байта (~ 22,18 ГБ), чтоэто сумма того, что у вас есть в первичном индексе 3222810368 (50 356 412 записей по 64 байта каждая) и того, что представляют собой сами данные (как данные в памяти), что составляет 20593229814 (~ 19,2 ГиБ).Основная часть индекса находится в общей памяти.

2- system-memory: free-kbytes 5095788 free-pct 9 heap-kbytes (30851170,49358076,52596736) heap-efficiency-pct 58.7

Указанная свободная системная память неверна в версии 3.12.К сожалению, у вас меньше доступно (см. Fix [AER-5810] - (STATS). Тикер журнала переоценивает свободную системную память, доступную в версии 3.16.0.4).

Более интересным является использование кучи (из справочное руководство по журналу ), которое можно прочитать как:

  • куча-килобайт - по порядку: ( heap_allocated_kbytes , heap_active_kbytes heap_mapped_kbytes ).

  • куча-эффективность-pct: Обеспечивает указание фрагментации кучи jemalloc.Это представляет отношение heap_allocated_kbytes / heap_mapped_kbytes.Меньшее число указывает на более высокую скорость фрагментации.

У вас выделено 30851170 КиБ (~ 29,4 ГиБ), но в общей сложности 52596736 КиБ (сопоставлено ~ 50,1 ГиБ), и это неэффективно (58,7% эффективности), что указывает на некоторую фрагментацию.Кстати, это не относится к общей памяти.Выделение 29 ГиБ кажется немного высоким для 19 ГиБ данных.Я ожидал бы меньших накладных расходов для всех других используемых внутренних структур.

Основная проблема, однако, заключается в неэффективности фрагментации.У вас случайно включен THP?Я действительно нашел эту статью ( Понимание использования памяти Linux ), в которой также рассматриваются подробности создания отчетов по памяти и конфигурация огромных страниц, которые могут быть причиной этого.

...