Zen

Source string Source string

452/10000 · 452
English Actions
struct luam_Metrics { /* the names described earlier for Lua */ }

LUAMISC_API void luaM_metrics(lua_State *L, struct luam_Metrics *metrics);
The names of ``struct luam_Metrics`` members are the same as Lua's :ref:`getmetrics table values <luajit_getmetrics_tablevalues>` names. The data types of ``struct luam_Metrics`` members are all ``size_t``. The ``luaM_metrics()`` function will fill the ``*metrics`` structure with the metrics related to the Lua state anchored to the ``L`` coroutine.
**Example with a C program**
Go through the :ref:`C stored procedures <f_c_tutorial-c_stored_procedures>` tutorial. Replace the easy.c example with
#include "module.h"
#include <lmisclib.h>

int easy(box_function_ctx_t *ctx, const char *args, const char *args_end)
{
lua_State *ls = luaT_state();
struct luam_Metrics m;
luaM_metrics(ls, &m);
printf("allocated memory = %lu\n", m.gc_allocated);
return 0;
}
Now when you go back to the client and execute the requests up to and including the line ``capi_connection:call('easy')`` you will see that the display is something like "allocated memory = 4431950" although the number will vary.
Example with gc_strnum, strhash_miss, and strhash_hit
To track new string object allocations:
function f()
collectgarbage("collect")
local oldm = misc.getmetrics()
local table_of_strings = {}
for i = 3000, 4000 do table.insert(table_of_strings, tostring(i)) end
for i = 3900, 4100 do table.insert(table_of_strings, tostring(i)) end
local newm = misc.getmetrics()
print("gc_strnum diff = " .. newm.gc_strnum - oldm.gc_strnum)
print("strhash_miss diff = " .. newm.strhash_miss - oldm.strhash_miss)
print("strhash_hit diff = " .. newm.strhash_hit - oldm.strhash_hit)
end
f()
The result will probably be: "gc_strnum diff = 1100" because we added 1202 strings but 101 were duplicates, "strhash_miss_diff = 1100" for the same reason, "strhash_hit_diff = 101" plus some overhead, for the same reason. (There is always a slight overhead amount for ``strhash_hit``, which can be ignored.)
We say "probably" because there is a chance that the strings were already allocated somewhere. It is a good thing if the slope curve of ``strhash_miss`` is less than the slope curve of ``strhash_hit``.
The other ``gc_*num`` values -- ``gc_cdatanum``, ``gc_tabnum``, ``gc_udatanum`` -- can be accessed in a similar way. Any of the ``gc_*num`` values can be useful when looking for memory leaks – the total number of these objects should not grow nonstop. A more general way to look for memory leaks is to watch ``gc_total``. Also ``jit_mcode_size`` can be used to watch the amount of allocated memory for machine code traces.
Example with gc_allocated and gc_freed
To track an application's effect on the garbage collector (less is better):
function f()
for i = 1, 10 do collectgarbage("collect") end
local oldm = misc.getmetrics()
local newm = misc.getmetrics()
oldm = misc.getmetrics()
collectgarbage("collect")
newm = misc.getmetrics()
print("gc_allocated diff = " .. newm.gc_allocated - oldm.gc_allocated)
print("gc_freed diff = " .. newm.gc_freed - oldm.gc_freed)
end
f()
The result will be: ``gc_allocated diff = 800``, ``gc_freed diff = 800``. This shows that ``local ... = getmetrics()`` itself causes memory allocation (because it is creating a table and assigning to it), and shows that when the name of a variable (in this case the ``oldm`` variable) is used again, that causes freeing. Ordinarily the freeing would not occur immediately, but ``collectgarbage("collect")`` forces it to happen so we can see the effect.
Example with gc_allocated and a space optimization
To test whether optimizing for space is possible with tables:
function f()
collectgarbage("collect")
local oldm = misc.getmetrics()
local t = {}
for i = 1, 513 do
t[i] = i
end
local newm = misc.getmetrics()
local diff = newm.gc_allocated - oldm.gc_allocated
print("diff = " .. diff)
end
f()
The result will show that diff equals approximately 18000.
Now see what happens if the table initialization is different:
function f()
local table_new = require "table.new"
local oldm = misc.getmetrics()
local t = table_new(513, 0)
for i = 1, 513 do
t[i] = i
end
local newm = misc.getmetrics()
local diff = newm.gc_allocated - oldm.gc_allocated
print("diff = " .. diff)
end
f()
The result will show that diff equals approximately 6000.
gc_steps_atomic and gc_steps_propagate
The slope curves of ``gc_steps_*`` items can be used for tracking pressure on the garbage collector too. During long-running routines, ``gc_steps_*`` values will increase, but long times between ``gc_steps_atomic`` increases are a good sign, And, since ``gc_steps_atomic`` increases only once per garbage-collector cycle, it shows how many garbage-collector cycles have occurred.
Also, increases in the ``gc_steps_propagate`` number can be used to estimate indirectly how many objects there are. These values also correlate with the garbage collector's `step multiplier <https://www.lua.org/manual/5.4/manual.html#2.5.1>`_. For example, the number of incremental steps can grow, but according to the step multiplier configuration, one step can process only a small number of objects. So these metrics should be considered when configuring the garbage collector.
The following function takes a casual look whether an SQL statement causes much pressure:
function f()
collectgarbage("collect")
local oldm = misc.getmetrics()
collectgarbage("collect")
box.execute([[DROP TABLE _vindex;]])
local newm = misc.getmetrics()
print("gc_steps_atomic = " .. newm.gc_steps_atomic - oldm.gc_steps_atomic)
print("gc_steps_finalize = " .. newm.gc_steps_finalize - oldm.gc_steps_finalize)
print("gc_steps_pause = " .. newm.gc_steps_pause - oldm.gc_steps_pause)
print("gc_steps_propagate = " .. newm.gc_steps_propagate - oldm.gc_steps_propagate)
print("gc_steps_sweep = " .. newm.gc_steps_sweep - oldm.gc_steps_sweep)
end
f()
And the display will show that the ``gc_steps_*`` metrics are not significantly different from what they would be if the ``box.execute()`` was absent.
Example with jit_trace_num and jit_trace_abort
Just-in-time compilers will "trace" code looking for opportunities to compile. ``jit_trace_abort`` can show how often there was a failed attempt (less is better), and ``jit_trace_num`` can show how many traces were generated since the last flush (usually more is better).

Loading…

User avatar None

New source string

testing_project / Documentation: reference/tooling/luajit_getmetrics — English

The result will be: ``gc_allocated diff = 800``, ``gc_freed diff = 800``. This shows that ``local ... = getmetrics()`` itself causes memory allocation (because it is creating a table and assigning to it), and shows that when the name of a variable (in this case the ``oldm`` variable) is used again, that causes freeing. Ordinarily the freeing would not occur immediately, but ``collectgarbage("collect")`` forces it to happen so we can see the effect.
a year ago
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

String information

Flags
read-only
String age
a year ago
Last updated
a year ago
Source string age
a year ago
Translation file
string 76