[zeromq-dev] Debugging ZMQ in Unix

Andrew Hume andrew at research.att.com
Fri Aug 24 16:46:07 CEST 2012


this begs the question "is there something in a non-unix environment that would suffice?"

for my case, all major data flows go thru various "portal"s where i precisely measure the
messages in and out (and thus know the exact queue length). except for these portals,
all data flows have a fairly tight leash (in terms of HWM). i can then examine progress
by displaying two complementary views: one measures teh flow in messages/min
and the other measures queue length as a % of messages out.

for example, as my app goes from a state where processing had suspended
to a normal running state, the queue view looks like

>     |->digest|->active|->locate| ->tagger |->tally|->calibrate|->measure
>     |  blob  | casea  |  lrl   |caset loc | tcase | lrc   rc  |  locm   
> 05:19|   1.8  |        |        |          |       |           |         
> 05:20|   1.4  |        |        |          |       |  0.1  0.1 |         
> 05:21|   0.9  |        |        | 0.1      |       |           |         
> 05:22|   0.4  |        |        | 0.2      |       |           |         
> 05:23|   0.2  |        |        | 0.2      |       |           |         
> 05:24|   0.1  |        |        | 0.1      |       |           |         
> 05:25|        |        |        | 0.1      |       |           |         
> 05:26|        |        |        | 0.1      |       |           |         
> 05:28|        |        |        | 0.1      |       |           |         

and the flow looks like

>     |->digest|->active|->locate|    ->tagger     |->tally |   ->calibrate   |->measure
>     |  blob  | casea  |  lrl   | caset     loc   | tcase  |  lrc       rc   |  locm   
> 05:19| 1.912M | 57.61M | 4.359M | 49.58M   479.3K | 729.2K | 3.688M   946.4K | 543.7K  
> 05:20| 4.131M | 105.1M | 8.509M | 82.58M   971.6K | 1.134M | 6.694M   1.831M | 964.9K  
> 05:21| 5.675M | 150.8M | 12.44M | 80.83M   1.648M | 1.046M | 16.15M   4.433M | 1.510M  
> 05:22| 4.460M | 120.4M | 11.80M | 60.79M   1.202M | 1.153M | 10.02M   3.191M | 1.279M  
> 05:23| 2.467M | 89.90M | 5.795M | 105.3M   682.3K | 1.645M | 6.125M   1.552M | 698.6K  
> 05:24| 1.876M | 51.99M | 4.254M | 60.62M   481.7K | 901.9K | 4.574M   1.237M | 481.6K  
> 05:26| 1.819M | 51.20M | 4.227M | 42.82M   481.4K | 721.2K | 4.206M   1.099M | 506.0K  
> 05:27| 941.1K | 28.27M | 2.227M | 42.58M   270.7K | 707.3K | 2.217M   780.8K | 266.3K  
> 05:28| 864.8K | 24.92M | 1.956M | 28.12M   233.8K | 437.7K | 2.013M   601.5K | 232.3K  
> 05:29| 806.6K | 23.07M | 1.705M | 20.25M   185.4K | 289.9K | 1.701M   560.0K | 187.7K  


the headings indicate the topology and portal names.
this shows that digest was processing 4-5M messages/min while there was a queue
and that the asymptotic input rate is about 800K-1M messages/min.

normally, we like no queues, except for tagger (who uses the queue to do
approximate temporal sorting).

i know this isn't graphical really, but its proved to be a very useful debugging
and monitoring tool for teh application. actually, make that critical;
i don't think i could have debugged or tuned this app without them.

	andrew



On Aug 24, 2012, at 7:19 AM, erupter at libero.it wrote:

> Hi.
> I'm not a great developer in Unix so I'm asking the following questions.
> Are there any tools that can graphically represent multithreading and message-
> shuffling while debugging an application?
> I know gdb and valgrind, but they don't do what I mean.
> I intend a kind of real-time profiler and possibly a kind of wireshark (if 
> anyone's familiar with that).
> 
> Does anyone know of any such application?
> I use Ubuntu if that is of interest.
> 
> Thanks
> Claudio
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120824/d33aee55/attachment.htm>


More information about the zeromq-dev mailing list