testing_project/Documentation: reference/tooling/luajit_memprof — Russian @ Weblate: The :ref:`test.lua code example <profiler_usage_example01>` above also illustrates the memory …

Translation

English

Russian

Needs editing

Skip

	English	Russian	Actions
	:ref:`Parsing <profiler_usage_parse>` the collected binary profile to get a human-readable profiling report.	Выполняется :ref:`парсинг <profiler_usage_parse>` собранного бинарного профиля. В результате формируется отчет о профилировании в удобном для чтения формате.
	Collecting binary profile	Сбор бинарного профиля
	To collect a binary profile for a particular part of the Lua code, you need to place this part between two ``misc.memprof`` functions, namely, ``misc.memprof.start()`` and ``misc.memprof.stop()``, and then execute the code under Tarantool.	Чтобы сформировать бинарный профиль для определенного участка кода на Lua, вставьте этот участок кода между функциями ``misc.memprof.start()`` и ``misc.memprof.stop()``, а затем выполните его в Tarantool.
	Below is a chunk of Lua code named ``test.lua`` to illustrate this.	Для наглядности ниже приведен фрагмент кода на Lua под названием ``test.lua``.
	-- Prevent allocations on traces. jit.off() local str, err = misc.memprof.start("memprof_new.bin") -- Lua doesn't create a new frame to call string.rep, and all allocations -- are attributed not to the append() function but to the parent scope. local function append(str, rep) return string.rep(str, rep) end local t = {} for i = 1, 1e4 do -- table.insert is the built-in function and all corresponding -- allocations are reported in the scope of the main chunk. table.insert(t, append('q', i) ) end local stp, err = misc.memprof.stop()	-- Отключение аллокации на трассах jit.off() local str, err = misc.memprof.start("memprof_new.bin") -- Lua не создает стековый фрейм для вызова string.rep, -- поэтому все события аллокации -- приписываются не функции append(), а родительской области local function append(str, rep) return string.rep(str, rep) end local t = {} for i = 1, 1e4 do -- table.insert — встроенная функция, -- так что профилировщик включает все соответствующие ей -- события аллокации в отчет по основной части кода table.insert(t, append('q', i) ) end local stp, err = misc.memprof.stop()
	The Lua code for starting the profiler -- as in line 3 in the test.lua example above -- is:	В примере test.lua код для запуска профилировщика находится на строке 3:
	local str, err = misc.memprof.start(FILENAME)	local str, err = misc.memprof.start(ИМЯ_ФАЙЛА)
	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``.	Если операция завершается ошибкой, функция ``misc.memprof.start()`` возвращает результат, состоящий из трех частей: ``nil``; строка с сообщением об ошибке; код ошибки в зависимости от системы. Ошибка может возникнуть, например, когда не открывается файл для записи или профилировщик уже запущен. Если операция выполняется успешно, ``misc.memprof.start()`` возвращает ``true``.
	The Lua code for stopping the profiler -- as in line 18 in the test.lua example above -- is:	В примере test.lua код для остановки профилировщика находится на строке 18:
	local stp, err = misc.memprof.stop()	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``.	Если операция завершается ошибкой, функция ``misc.memprof.stop()`` возвращает результат, состоящий из трех частей: ``nil``; строка с сообщением об ошибке; код ошибки в зависимости от системы. Ошибка может возникнуть, например, когда закрыт файловый дескриптор или во время составления отчета происходит сбой. Если операция выполняется успешно, ``misc.memprof.stop()`` возвращает ``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:	Теперь нужно сгенерировать файл с профилем памяти в бинарном формате. В :ref:`примере test.lua <profiler_usage_example01>` имя файла — ``memprof_new.bin``. Выполните код в Tarantool:
	$ tarantool test.lua	$ 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.	Tarantool собирает события аллокации в файл ``memprof_new.bin``, помещает его в :ref:`рабочую директорию <cfg_basic-work_dir>` и завершает сеанс.
	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:	:ref:`Пример test.lua <profiler_usage_example01>` также иллюстрирует логику, по которой в некоторых случаях происходит аллокация памяти. Важно понимать эту логику, чтобы :ref:`читать <profiler_usage_parse>` и :ref:`анализировать <profiler_analysis>` отчеты о профилировании.
	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.	Строка 2: Рекомендуется отключать JIT-компиляцию, вызывая ``jit.off()`` перед запуском профилировщика. За дополнительными сведениями обратитесь к :ref:`примечанию о jitoff <profiler_usage_internal_jitoff>`.
	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.	Строки 6–8: Оптимизация хвостового вызова не создает новый фрейм стека вызовов, поэтому все события аллокации в `байт-коде <http://wiki.luajit.org/Bytecode-2.0#calls-and-vararg-handling>`_ ``CALLT/CALLMT`` относятся на счет кода, вызывающего эту функцию. Обратите внимание на комментарии перед этими строками.
	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.	Строки 14–16: Как правило, разработчиков несильно интересует информация об аллокации во встроенных функциях LuaJIT. Поэтому если встроенная функция вызывается из функции на Lua, профилировщик собирает все события аллокации для функции на Lua. В противном случае событие относится к функции на C. Обратите внимание на комментарии перед этими строками.
	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, воспользовавшись следующей командой (обратите внимание на дефис ``-`` перед именем файла):
	$ tarantool -e 'require("memprof")(arg)' - memprof_new.bin	$ 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.)	Здесь ``memprof_new.bin`` — бинарный профиль, :ref:`ранее сгенерированный <profiler_usage_generate>` командой ``tarantool test.lua``. (Внимание: в версии Tarantool 2.8.1 поведение команды ``tarantool -e`` немного изменилось.)
	Tarantool generates a profiling report and displays it on the console before closing the session:	Tarantool генерирует отчет о профилировании и выводит его в консоль перед закрытием сеанса:
	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	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.	В macOS отчет по той же части кода выглядит по-другому, поскольку Tarantool и LuaJIT собраны с поддержкой режима GC64 для macOS.
	Let's examine the report structure. A report has four sections:	Рассмотрим структуру отчета. Он состоит из четырех разделов:
	ALLOCATIONS	ALLOCATIONS (аллокация)
	REALLOCATIONS	REALLOCATIONS (реаллокация)
	DEALLOCATIONS	DEALLOCATIONS (деаллокация)
	HEAP SUMMARY (described later in :ref:`The heap summary and the --leak-only option<luajit_memprof_leak_only>`)	HEAP SUMMARY (cводка изменений в динамической памяти, раздел описан :ref:`ниже <luajit_memprof_leak_only>`)