[GRLUG] Process timing

[Grand Rapids Linux Users Group]

More than that, you want flamegraphs of where the system is spending its
time.

https://github.com/brendangregg/FlameGraph

Learning to interpret and apply the data properly is quite the learning
experience.

:wq

On Mon, Aug 17, 2020, 10:55 PM Grand Rapids Linux Users Group <
grlug at grlug.org> wrote:

> Not sure what you would do with knowing how long various processes are
> running.  I think your better off looking at logs, or running a
> benchmarker/code profiler for the application.  If you watching apache
> processes spin up and down and wondering how long,  I would just up the
> debug log, and what for servers to be spun up and down.  If your interested
> in per object response time, you need to look at setting up jjmeter to test
> your web app.
>
> If you looking to debug what the actual process is doing on the system,
> you are looking for strace data.
>
> On Mon, Aug 17, 2020 at 5:41 PM Grand Rapids Linux Users Group <
> grlug at grlug.org> wrote:
>
>> For what you want, I'd configure auditd to log every process start and
>> stop, run my tests, then tell auditd to not do that any more. Then I'd
>> script up some analysis of logs.
>>
>> To be honest, I don't know how to do that off the top of my head. If
>> auditd couldn't do it, though, I'd turn around and look at something like
>> SystemTap, which certainly could, though it would require some elbow grease
>> to write the BPF program to assemble the events and log entries I wanted.
>> (Though to be clear, you could very likely have it give you the entire
>> process lifecycle timing.) It's possible someone has already written the
>> BPF program to do exactly this.
>>
>> :wq
>>
>> On Mon, Aug 17, 2020, 6:14 PM Grand Rapids Linux Users Group <
>> grlug at grlug.org> wrote:
>>
>>> correction.
>>>
>>> nagios is cool, but not what i meant.
>>> munin is what i was thinking of
>>>
>>> both excellent sources of infinite perl wisdom too
>>>
>>>
>>> -j
>>>
>>>
>>>
>>>
>>>
>>> On Aug 17, 2020, at 6:07 PM, Grand Rapids Linux Users Group <
>>> grlug at grlug.org> wrote:
>>>
>>> no proc!!! no wae!
>>> prolly in /run or some such magic ヽ(｀Д´)⊃━☆ﾟ. * ･ ｡ﾟ,
>>>
>>> apache has mod_status which provides a lot of info about the server,
>>> threads/workers & requests/response timing
>>>
>>> enabling it is simple, but do ensure you’ve paid attention to Allow From
>>> 127/0 and such. you don’t wanna give us all those spicy bits.
>>>
>>> tools like nagios can help spruce up the display, but you might get by
>>> with the default look-n-feel
>>>
>>>
>>>
>>> -j
>>>
>>>
>>>
>>>
>>>
>>> On Aug 17, 2020, at 6:01 PM, Grand Rapids Linux Users Group <
>>> grlug at grlug.org> wrote:
>>>
>>> On Mon, 17 Aug 2020, Grand Rapids Linux Users Group wrote:
>>>
>>> watch proc topless
>>>
>>> Interesting, .. unfortunately no proc on this distro.
>>>
>>> execution time and process/thread life are not the same tho, so if
>>> you’re tryna see how long a script executes, you might actually find
>>> apache’s LogFormat helpful, but not as great as nginx.
>>>
>>> Most of the timing information is there in the logs, .. but what/how to
>>> parse?
>>>
>>> Thanks!
>>> --
>>> grlug mailing list
>>> grlug at grlug.org
>>> https://shinobu.grlug.org/mailman/listinfo/grlug
>>>
>>>
>>> --
>>> grlug mailing list
>>> grlug at grlug.org
>>> https://shinobu.grlug.org/mailman/listinfo/grlug
>>>
>>>
>>> --
>>> grlug mailing list
>>> grlug at grlug.org
>>> https://shinobu.grlug.org/mailman/listinfo/grlug
>>>
>> --
>> grlug mailing list
>> grlug at grlug.org
>> https://shinobu.grlug.org/mailman/listinfo/grlug
>>
> --
> grlug mailing list
> grlug at grlug.org
> https://shinobu.grlug.org/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://shinobu.grlug.org/pipermail/grlug/attachments/20200817/d8bfc9a8/attachment.html>