[ 
https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030839#comment-16030839
 ] 

ASF GitHub Bot commented on ARTEMIS-1185:
-----------------------------------------

Github user franz1981 commented on the issue:

    https://github.com/apache/activemq-artemis/pull/1295
  
    @clebertsuconic 
    
    > doc how to use this... (is that internal only)?
    
    :+1: You're right, but what could be a good place where put it?
    It is like the other CLI commands, so it can be used by any user, but I 
suspect that perf engineers and devOps engineers are the typical audience for 
it.
    A possible use case is to build a Cron job that during the day run it and 
use the extracted log to feed a time series database, an Elastic Search 
repository or anything suitable to collect latency samples.
    After the doc probably most of the aspect of the profiler will be clear, it 
uses an approach similar to perf tools on *nix.
    
    > how to read the file...
    
    The *profiler* (ie FlushProfiler) produces only one file of 4K fixed size 
in `/dev/shm` or  in the Artemis configured `tmp` dir: this file is not built 
to be read by humans or other user-provided tools right now.
    
    > I am a bit confused with the file format...
    
    The *sampler* (ie the CLI command) samples the data on the file written by 
the *profiler* and produces a CSV US-ASCII text trace with `<timestamp in 
ns><separator><latency in ns>\n` pairs.
    For example, using the default parameters:
    ```
    0 27729
    4534870 32709
    8443760 27556
    15067045 44260
    16290386 18286
    17146291 14201
    17908462 8243
    19349526 33071
    24171483 79496
    27741532 18992
    ...
    ```
    This trace, if collected in a file, can be used directly with `gnuplot` to 
plot this:
    
![image](https://cloud.githubusercontent.com/assets/13125299/26622962/72d67788-45ec-11e7-9e23-a6e1c054b75f.png)
    But it won't be saved in a file if not configured properly.
    
    > Also, it would be nice to be allowed to configure where the file would be 
generated.
    
    Currently the user running the *sampler* could choose where put the trace 
recorded from the profiler using the `--out` parameter:
    ```
    @Option(name = "--out", description = "The output text csv stat file or 
stdout if not defined")
    public String fileOut;
    ```
    By default the *sampler* command prints on `stdout` the CSV trace and on 
`stderr` a real time log of the statistics of the running sampler, in the form:
    ```
    Duration 1003ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 657 sample - 4 lost - 780 kB - 657 sync
    Duration 1002ms - 3,397 sample - 0 lost - 4,413 kB - 3,397 sync
    Duration 1001ms - 4,328 sample - 14 lost - 5,827 kB - 4,328 sync
    Duration 1001ms - 4,807 sample - 2 lost - 6,513 kB - 4,807 sync
    Duration 1000ms - 2,100 sample - 0 lost - 2,847 kB - 2,100 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 2,994 sample - 0 lost - 4,051 kB - 2,994 sync
    Duration 1001ms - 5,165 sample - 0 lost - 7,001 kB - 5,165 sync
    Duration 1000ms - 5,244 sample - 0 lost - 7,116 kB - 5,244 sync
    Duration 1001ms - 1,647 sample - 0 lost - 2,230 kB - 1,647 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1000ms - 3,237 sample - 0 lost - 4,381 kB - 3,237 sync
    Duration 1001ms - 4,892 sample - 0 lost - 6,616 kB - 4,892 sync
    Duration 1001ms - 4,543 sample - 0 lost - 6,120 kB - 4,543 sync
    Duration 1000ms - 2,468 sample - 0 lost - 3,281 kB - 2,468 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 1,747 sample - 1 lost - 2,374 kB - 1,747 sync
    Duration 1000ms - 5,318 sample - 0 lost - 7,224 kB - 5,318 sync
    Duration 1001ms - 5,327 sample - 0 lost - 7,233 kB - 5,327 sync
    Duration 1001ms - 2,628 sample - 0 lost - 3,565 kB - 2,628 sync
    Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 2,553 sample - 0 lost - 3,451 kB - 2,553 sync
    Duration 1001ms - 5,243 sample - 0 lost - 7,108 kB - 5,243 sync
    Duration 1001ms - 5,162 sample - 0 lost - 7,008 kB - 5,162 sync
    Duration 1000ms - 2,087 sample - 0 lost - 2,831 kB - 2,087 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 3,011 sample - 0 lost - 4,090 kB - 3,011 sync
    Duration 1001ms - 6,720 sample - 0 lost - 9,116 kB - 6,720 sync
    Duration 1000ms - 5,306 sample - 0 lost - 7,193 kB - 5,306 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Duration 102ms - 0 sample - 0 lost - 0 bytes - 0 sync
    Total Duration 38132ms - 90,581 total sample - 21 total lost
    ```
    Where `lost` represent the number of lost samples due to a low frequency of 
the *sampler* vs the higher frequency of profiled data.
    
    
    
    
    
    
    
    



> Inter-Process Journal Sampler Profiler + CLI command
> ----------------------------------------------------
>
>                 Key: ARTEMIS-1185
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1185
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>          Components: Broker
>            Reporter: Francesco Nigro
>            Assignee: Francesco Nigro
>            Priority: Minor
>
> It provides a sampling profiler on buffered ASYNCIO/NIO based journals.
> The profiling has a minimal cost in term of CPU time for each sample (the 
> dominant costs are System.nanoTime() and a single cache line invalidation) 
> and total memory footprint (~OS page size in bytes).
> A proper CLI command activates a sampler to collect (ie CSV) the profiled 
> data, showing the precision of the sampling: data loss is not considered a 
> failure condition.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to