From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id B9440430408 for ; Tue, 11 Aug 2020 23:23:48 +0300 (MSK) Date: Tue, 11 Aug 2020 23:13:24 +0300 From: Igor Munkin Message-ID: <20200811201324.GY18920@tarantool.org> References: <20200721113451.25817-1-skaplun@tarantool.org> <20200721113717.22804-1-skaplun@tarantool.org> <20200723101525.GC894@tarantool.org> <20200724111829.GA4086@root> <20200724172003.GF894@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200724172003.GF894@tarantool.org> Subject: Re: [Tarantool-patches] [RFC] rfc: luajit metrics List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Ostanevich Cc: tarantool-patches@dev.tarantool.org Sergos, On 24.07.20, Sergey Ostanevich wrote: > Hi! > > > On 24 Jul 14:18, Sergey Kaplun wrote: > > > > + /* > > > > + * 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. 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 in VM). Anyway, the user has to proceed with the degradation investigation at first. > > > > > > > + 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, 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 > > > > > > > -- > > Best regards, > > Sergey Kaplun [1]: https://github.com/kikito/inspect.lua -- Best regards, IM