Closed rosik closed 2 years ago
Further investigations show, that it was specific to the TDG, but it can occur in other projects too. In this case, the root cause was in lots of loadstring
calls.
$ cat /tmp/jitp.out
12% /usr/share/tarantool/tdg/common/pipeline/config.lua:34
6% /usr/share/tarantool/tdg/common/model.lua:1450
4% /usr/share/tarantool/tdg/.rocks/share/tarantool/avro_schema/utils.lua:42
4% /usr/share/tarantool/tdg/common/model_flatten.lua:40
4% builtin/table.lua:13
4% /usr/share/tarantool/tdg/.rocks/share/tarantool/avro_schema/frontend.lua:61
====== /usr/share/tarantool/tdg/common/pipeline/config.lua ======
@@ 31 @@
| config_checks:assert(type(code) == 'string',
| 'functions[%s] must be a string', fn_name)
| local fn, err = load(code, fn_name, 't')
9% | config_checks:assert(fn ~= nil,
| 'functions[%s] syntax error: %s', fn_name, err)
| end
|
P.S. jit.p
missed a line, it should point to load(code)
Recently we've noticed a problem on a customers side. Applying clusterwide configuration is a rather CPU-consuming operation.