[Tarantool-patches] [RFC] rfc: luajit metrics

[Igor Munkin]

Sergos,

On 24.07.20, Sergey Ostanevich wrote:
> Hi!
> 
> 
> On 24 Jul 14:18, Sergey Kaplun wrote:

<snipped>

> > > > +	/*
> > > > +	 * Overall number of snap restores for all traces
> > > 
> > > Snap restores needs some explanation.
> > 
> > Ok, sounds reasonable. AFAIK number of snap restores equals to amount of
> > trace exits. May be this will be more informative for users.
> > 
> 
> Well. What this will tell to you as a user running a Lua code? Consider
> the number is grows - ??? And what if it shrinks??

What does a pretty high lymphocyte percentage tell you? This might be
either allergic reaction you're facing right now, or infection, or
something else. You can say nothing considering only this one index.

<jit_snap_restore> is just a single JIT-related index and it shows
nothing per se.

Since this index is absolute, it doesn't shrink.

> 
> I believe it is tighly bound to the total number of traces and the size
> of code.

It's closely related to the overall number of side exits leading to VM.
NB: side exits leading to the side trace are not counted here (since
snapshot is "replayed" and the corresponding code is added prior to the
side trace enter), but trace exits violating the loop condition guards
are (this is the way trace execution leaves the recorded loop).

> But what should it disclose to the user - how should it react,
> refactor its code?

Wild guess: there *might* be irrelevant traces. At the same time it may
be just a noise, since "succeeded" trace exits are not counted (but we
can implement it within <lj_vm_exit_interp> in VM). Anyway, the user has
to proceed with the degradation investigation at first.

> 

<snipped>

> > 
> > > > +    jit_snap_restore: 0
> > > > +    gc_freed: 2239391
> > > > +    strhash_hit: 53759
> > > > +    gc_steps_finalize: 0
> > > > +    gc_allocated: 3609318
> > > > +    gc_steps_atomic: 6
> > > > +    gc_steps_sweep: 296
> > > > +    gc_steps_sweepstring: 17920
> > > > +    jit_trace_abort: 0
> > > > +    strhash_miss: 6874
> > > 
> > > I wonder if those keys can be sorted? Consider, I want to find
> > > something by the name. Sorting helps greatly. 
> > 
> > It can be implement by user as simple as:
> > 
> > | local metrics = xjit.getmetrics()
> > | local sorted = {}
> > | for k, v in pairs(metrics.incremental) do table.insert(sorted, k) end
> > | table.sort(sorted)
> > | for _, k in ipairs(sorted) do print(k, metrics.incremental[k]) end
> > |
> > | --[[
> > | gc_allocated    8920
> > | gc_freed        3528
> > | gc_steps_atomic 0
> > | gc_steps_finalize       0
> > | gc_steps_pause  0
> > | gc_steps_propagate      62
> > | gc_steps_sweep  0
> > | gc_steps_sweepstring    0
> > | jit_snap_restore        0
> > | jit_trace_abort 0
> > | strhash_hit     118
> > | strhash_miss    7
> > | ]]
> > 
> 
> For me it is not that simple, frankly. Not in understanding - in use.
> Can we just incorporate the code into the getmetrics()?

No, <getmetrics> yields a table (unordered map if you want), not a
string. And you question relates to stats view, not its storage. I
personally prefer inspect module[1], that serializes a table sorting its
keys as you can see below:

| $ LUA_PATH="$HOME/.luarocks/share/lua/5.1/?.lua;;" \
| 	./luajit -e 'print(require("inspect")(misc.getmetrics()))'
| {
|   cdatanum = 0,
|   gc_allocated = 93583,
|   gc_freed = 28408,
|   gc_steps_atomic = 0,
|   gc_steps_finalize = 0,
|   gc_steps_pause = 1,
|   gc_steps_propagate = 218,
|   gc_steps_sweep = 0,
|   gc_steps_sweepstring = 0,
|   gc_total = 65175,
|   jit_mcode_size = 0,
|   jit_snap_restore = 0,
|   jit_trace_abort = 0,
|   jit_trace_num = 0,
|   strhash_hit = 958,
|   strhash_miss = 447,
|   strnum = 447,
|   tabnum = 69,
|   udatanum = 4
| }

> 
> Thanks,
> Sergos
> 
> > 

<snipped>

> > 
> > -- 
> > Best regards,
> > Sergey Kaplun

[1]: https://github.com/kikito/inspect.lua

-- 
Best regards,
IM