Zen

Source string Source string

61/10000 · 61
English Actions
**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).
The following function does not contain code that can cause trouble for LuaJIT:
function f()
jit.flush()
for i = 1, 10 do collectgarbage("collect") end
local oldm = misc.getmetrics()
collectgarbage("collect")
local sum = 0
for i = 1, 57 do
sum = sum + 57
end
for i = 1, 10 do collectgarbage("collect") end
local newm = misc.getmetrics()
print("trace_num = " .. newm.jit_trace_num - oldm.jit_trace_num)
print("trace_abort = " .. newm.jit_trace_abort - oldm.jit_trace_abort)
end
f()

Loading…

User avatar None

New source string

testing_project / Documentation: reference/tooling/luajit_getmetrics — English

To test whether optimizing for space is possible with tables:
a year ago
Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Mismatched colon: Russian, Russian

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 78