LINUX.ORG.RU

Как проверить - дергает ли программа файл каждый раз или держит в буфере?

 , , ,


0

1

Суть - наткнулся на комментарий, где @zmc жалуется что Asterisk на исполнение одного контекста несколько раз дергает lua-файл с диалпланом:

local log, err = io.open("/tmp/pbx_lua.log","a")

if log then
  log:setvbuf("no")
  log:write('--- iteration ---\n')
  log:close()
end

extensions = { 
   lua = { 
      ["000"] = function(context, extension)
         app.Verbose("---------------- Test LUA Call -------------------------")
      end 
  }
}

Я проверил - так и есть, несколько итераций на простом контексте.

Лучше новый tcp коннект, чем такое.

Но вопрос - а точно ли он дергает каждый раз файловую систему для перечитывания скрипта? Или держит в буфере? Если второе - то вроде как и не страшно.

$ stat /etc/asterisk/extensions.lua 
  File: /etc/asterisk/extensions.lua
  Size: 2491            Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d      Inode: 4718730     Links: 1
Access: (0644/-rw-r--r--)  Uid: (  106/asterisk)   Gid: (  112/asterisk)
Access: 2023-03-14 17:36:50.566980520 +0300
Modify: 2023-03-14 17:36:46.975001482 +0300
Change: 2023-03-14 17:36:46.975001482 +0300
 Birth: 2023-03-14 17:36:46.975001482 +0300

Access вроде не менялся после `module reload pbx_lua.so’. Это доказывает что файл больше не дергается и лежит в буфере?

★★★★★

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

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

Но можно же быстро набросать скрипт, который создаст новую tmpfs закинет туда файлы и пусть asterisk оттуда читает файлы.

Только зачем это делать, если прочитанный файл и так попадает в page cache ядра и может храниться там вечно, если памяти на все хватает.

annulen ★★★★★
()

Как проверить - дергает ли программа файл каждый раз или держит в буфере?

Можно добавить в incrontab событие (запись в какой-нибудь лог) на открытие этого файла на чтение или запись.

// В детали проблемы не вникал.

CrX ★★★
()

Disclaimer: я ничего не знаю конкретно про Asterix, просто мимо проходил.

На самом деле, под «несколько раз дергает lua-файл» могут пониматься разные вещи:

  1. Файл каждый раз перечитывается путем обращения к ФС с помощью системного вызова, такого как read (после чего Lua-код компилируется и выполняется). Это можно доказать или опровергнуть, отслеживая системные вызовы приложения с помощью инструментов вроде strace, sysdig, dtruss и т.п. Повторные чтения будут с около 100% вероятностью происходить из page cache, т.е. без обращения к диску (можно проверить с помощью мониторинга major page faults приложения).
  2. Содержимое файла перечитывается из внутреннего буфера - переменной static char *config_file_data (см. код [1]). В этом случае нет никаких системных вызовов и обращений к диску или page cache. После этого происходит компиляция Lua-кода и его выполнение.
  3. Lua-код вызывается без перекомпиляции.

Печать лога «Test LUA Call» доказывает только (3), что является копеечным оверхедом и этого вряд ли можно избежать. Но, судя по коду модуля [1], авторы по какой-то причине не предусмотрели кэширование скомпилированного кода. Но какую-то проблему это может представлять только при значительном потреблении CPU приложением, в противном случае это по-любому лучше, чем «новый tcp коннект».

[1] https://github.com/asterisk/asterisk/blob/master/pbx/pbx_lua.c

annulen ★★★★★
()

Можно посмотреть события типа access/open через inotifywait для этого скрипта.

Если памяти под кеш хватает, то будет читать из кеша.

vel ★★★★★
()

Если внимательно прочитать сообщение с habr’а, то очевидно, что проблема ДАЖЕ не в том что *.lua дёргается как файл постоянно, а в том что он дёргается по нескольку раз на прохождении ОДНОГО контекста.

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

Как вам там ответили в комментах - скрипт выполняется заново для каждого gosub и hangup hook, что логично. Чтения файла заново нет, как мы тут выяснили. Поэтому ничего страшного не вижу.

Turbid ★★★★★
() автор топика