Zen

Source string Source string

280/10000 · 280
English Actions
where ``FILENAME`` is the name of the binary file where profiling events are written.
If the operation fails, for example if it is not possible to open a file for writing or if the profiler is already running, ``misc.memprof.start()`` returns ``nil`` as the first result, an error-message string as the second result, and a system-dependent error code number as the third result. If the operation succeeds, ``misc.memprof.start()`` returns ``true``.
The Lua code for stopping the profiler -- as in line 18 in the test.lua example above -- is:
local stp, err = misc.memprof.stop()
If the operation fails, for example if there is an error when the file descriptor is being closed or if there is a failure during reporting, ``misc.memprof.stop()`` returns ``nil`` as the first result, an error-message string as the second result, and a system-dependent error code number as the third result. If the operation succeeds, ``misc.memprof.stop()`` returns ``true``.
To generate the file with memory profile in binary format (in the :ref:`test.lua code example above <profiler_usage_example01>` the file name is ``memprof_new.bin``), execute the code under Tarantool:
$ tarantool test.lua
Tarantool collects the allocation events in ``memprof_new.bin``, puts the file in its :ref:`working directory <cfg_basic-work_dir>`, and closes the session.
The :ref:`test.lua code example <profiler_usage_example01>` above also illustrates the memory allocation logic in some cases that are important to understand for :ref:`reading <profiler_usage_parse>` and :ref:`analyzing <profiler_analysis>` a profiling report:
Line 2: It is recommended to switch the JIT compilation off by calling ``jit.off()`` before the profiler start. Refer to the following :ref:`note about jitoff <profiler_usage_internal_jitoff>` for more details.
Lines 6-8: Tail call optimization doesn't create a new call frame, so all allocations inside the function called via the ``CALLT/CALLMT`` `bytecodes <http://wiki.luajit.org/Bytecode-2.0#calls-and-vararg-handling>`_ are attributed to the function's caller. See also the comments preceding these lines.
Lines 14-16: Usually the information about allocations inside Lua built‑ins is not really useful for developers. That's why if a Lua built‑in function is called from a Lua function, the profiler attributes all allocations to the Lua function. Otherwise, this event is attributed to a C function. See also the comments preceding these lines.
Parsing binary profile and generating profiling report
After getting the memory profile in binary format, the next step is to parse it to get a human-readable profiling report. You can do this via Tarantool by using the following command (mind the hyphen ``-`` before the filename):
$ tarantool -e 'require("memprof")(arg)' - memprof_new.bin
where ``memprof_new.bin`` is the binary profile :ref:`generated earlier <profiler_usage_generate>` by ``tarantool test.lua``. (Warning: there is a slight behavior change here, the ``tarantool -e ...`` command was slightly different in Tarantool versions prior to Tarantool 2.8.1.)
Tarantool generates a profiling report and displays it on the console before closing the session:
ALLOCATIONS
@test.lua:14: 10000 events +50240518 bytes -0 bytes
@test.lua:9: 1 events +32 bytes -0 bytes
@test.lua:8: 1 events +20 bytes -0 bytes
@test.lua:13: 1 events +24 bytes -0 bytes

REALLOCATIONS
@test.lua:13: 13 events +262216 bytes -131160 bytes
Overrides:
@test.lua:13

@test.lua:14: 11 events +49536 bytes -24768 bytes
Overrides:
@test.lua:14
INTERNAL

INTERNAL: 3 events +8448 bytes -16896 bytes
Overrides:
@test.lua:14

DEALLOCATIONS
INTERNAL: 1723 events +0 bytes -483515 bytes
@test.lua:14: 1 events +0 bytes -32768 bytes

HEAP SUMMARY:
@test.lua:14 holds 50248326 bytes: 10010 allocs, 10 frees
@test.lua:13 holds 131080 bytes: 14 allocs, 13 frees
INTERNAL holds 8448 bytes: 3 allocs, 3 frees
@test.lua:9 holds 32 bytes: 1 allocs, 0 frees
@test.lua:8 holds 20 bytes: 1 allocs, 0 frees
On macOS, a report will be different for the same chunk of code because Tarantool and LuaJIT are built with the GC64 mode enabled for macOS.
Let's examine the report structure. A report has four sections:
ALLOCATIONS
REALLOCATIONS
DEALLOCATIONS
HEAP SUMMARY (described later in :ref:`The heap summary and the --leak-only option<luajit_memprof_leak_only>`)
Each section contains event records that are sorted from the most frequent to the least frequent.
An event record has the following format:
@<filename>:<line_number>: <number_of_events> events +<allocated> bytes -<freed> bytes
<filename>—a name of the file containing Lua code.
<line_number>—the line number where the event is detected.
<number_of_events>—a number of events for this code line.
+<allocated> bytes—amount of memory allocated during all the events on this line.

Loading…

User avatar None

New source string

testing_project / Documentation: reference/tooling/luajit_memprof — English

where ``memprof_new.bin`` is the binary profile :ref:`generated earlier <profiler_usage_generate>` by ``tarantool test.lua``. (Warning: there is a slight behavior change here, the ``tarantool -e ...`` command was slightly different in Tarantool versions prior to Tarantool 2.8.1.)
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 28