LINUX.ORG.RU
ФорумAdmin

Asterisk, slab cache

 


0

1

Быстро растет slab cache
https://poiuty.com/img/a4ff41ff2ec3afb351add476d877.png
Далее срабатывает oom kill и падает, например mysql.

Увеличивается dentry - slabtop

 Active / Total Objects (% used)    : 3820317 / 3878206 (98.5%)
 Active / Total Slabs (% used)      : 231956 / 232058 (100.0%)
 Active / Total Caches (% used)     : 131 / 245 (53.5%)
 Active / Total Size (% used)       : 859619.62K / 866908.09K (99.2%)
 Minimum / Average / Maximum Object : 0.02K / 0.22K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
3455182 3455107  99%    0.22K 203246       17    812984K dentry
156288 133890  85%    0.10K   4224       37     16896K buffer_head
 27874  27850  99%    0.55K   3982        7     15928K radix_tree_node
 25718  19105  74%    0.05K    334       77      1336K anon_vma_chain
 24864  23905  96%    0.03K    222      112       888K size-32
 22876  20664  90%    0.20K   1204       19      4816K vm_area_struct
 22698  22691  99%    1.09K   7566        3     30264K ext4_inode_cache
 20119  13218  65%    0.06K    341       59      1364K size-64
 18620  18549  99%    0.19K    931       20      3724K size-192
 15700  15627  99%    0.15K    628       25      2512K sysfs_dir_cache
 13013   8965  68%    0.05K    169       77       676K anon_vma
 10985  10948  99%    0.72K   2197        5      8788K proc_inode_cache
  7455   5098  68%    0.25K    497       15      1988K filp
  6070   5332  87%    0.38K    607       10      2428K ip_dst_cache
  5970   5216  87%    0.12K    199       30       796K size-128
  5472   5403  98%    0.65K    912        6      3648K inode_cache
  4081   4032  98%    0.07K     77       53       308K Acpi-Operand
  2612   2493  95%    1.00K    653        4      2612K size-1024
  2576   2499  97%    0.04K     28       92       112K Acpi-Namespace
  1860   1249  67%    0.19K     93       20       372K cred_jar
  1584   1485  93%    0.84K    176        9      1408K shmem_inode_cache
  1537    925  60%    0.07K     29       53       116K eventpoll_pwq
  1488   1424  95%    0.50K    186        8       744K size-512
  1380    903  65%    0.19K     69       20       276K eventpoll_epi
  1250   1066  85%    0.75K    250        5      1000K sock_inode_cache
  1200   1117  93%    0.25K     80       15       320K size-256
  1156    595  51%    0.11K     34       34       136K task_delay_info
  1060    166  15%    0.06K     20       53        80K tcp_bind_bucket
   742    265  35%    0.06K     14       53        56K fs_cache
   720    437  60%    0.12K     24       30        96K pid_2
   670    620  92%    1.75K    335        2      1340K TCP
   570    210  36%    0.12K     19       30        76K pid
   531    392  73%    0.81K     59        9       472K task_xstate
   520    506  97%    2.75K    260        2      2080K task_struct

Выяснил, что это происходит из-за запуска (по крону) скрипта /var/lib/asterisk/agi-bin/reload
Никто не сталкивался с таким? Почему slab cache не очищается и не отдает ram -> apps?
Почему используется именно slab cache? Как самому воспроизвести использование slab cache?
asterisk сборка freepbx.



Последнее исправление: poiuty (всего исправлений: 1)

Ответ на: комментарий от poiuty

попробуй echo 100000 в вышеназванный файл, но учти, это костыль и вредно для производительности, можешь поискать по stackexchange этот параметр.

вообще, похоже на баг ядра

anonymous
()
Ответ на: комментарий от anonymous

Ядро (актуальное) rhel6 с патчами openvz.
На других нодах (ovz) ни разу не встречал такого.
Отправлю репорт в freepbx и openvz.

poiuty
() автор топика
Ответ на: комментарий от zgen

стоит сборка FreePBX. Все конфиги лежат в базе. И там же обновляются. Поэтому по крону запускается скрипт для обновления/генерации файлов-конфигов астериска. Ну и есть куча параметров которые могут поменяться(пользователи меняют настройки свои), поэтому постоянно надо обновлять конфиги.

Sanasol
()
Ответ на: комментарий от Sanasol

спасибо!
--
Думаю, это какие то особенности работы в openvz

Если скрипт не изменен вручную для козьих целей, и неочевидно, что внутри него (на скриптовом поди языке) может приводить к подобному, то обновить freepbx. А потом обновить openvz.

zgen ★★★★★
()
Ответ на: комментарий от zgen

Скрипт не изменялся(он на php генерирует всё это, практически весь freepbx подключает, все модули и т.д.). Ядро FreePBX последней версии. Я хотел поотключать ненужные вещи, но код страшный, я не стал туда залезать. Проблема появилась после переезда на новый сервер, в чем разница между старым и новым наверно сказать может только poiuty. Раньше он тоже сжирал всё что есть видимо, но не до такой степени чтобы вызывать kernel panic и начать убивать процессы. --- В базе с настройками freepbx 65к записей во всех таблицах, в сумме на 6,5мб. На выходе 200 файлов астериска на 5мб. --- Я как phpшник не представляю как надо писать код чтобы он сожрал >256мб рамы и при этом создавал утечку рамы на 20-50мб после каждого запуска.

Sanasol
()
Ответ на: комментарий от Sanasol

Разницы никакой. Железо примерно такое же. CentOS 6 + OVZ ядро.
Перенос 1 в 1 => контейнер(vps, fs ploop) с первой ноды залили на вторую ноду.

Алекс, не kernel panic, а OOM kill. Кстати на прошлой ноде тоже это было, но убивало в основном php процессы.
Разница была лишь в обьеме памяти, который был доступен контейнеру.

График за несколько месяц. Когда сделали больше памяти - slab стал расти. Но и до этого он тоже рос.
https://poiuty.com/img/3f01d0b36af0cdf21a9095caa8ba.png
https://poiuty.com/img/89b75eda1d5109f6ec8c81b8ed5d.png

poiuty
() автор топика
Последнее исправление: poiuty (всего исправлений: 1)
Ответ на: комментарий от poiuty

Разницы никакой

Это называется «художественное преувеличение».
Разница есть, иначе бы вы подобных проблем не испытывали.

zgen ★★★★★
()
Ответ на: комментарий от anonymous

Проверил на другом ядре (debian 7 kernel 3.2) не в контейнере
Тот же результат.

poiuty
() автор топика
Последнее исправление: poiuty (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.