GUADEC dtrace

Shortly before Glynn and I gave our GUADEC talk on dtrace, we sat in on Federico's "How fast" talk where he raised a question about profiling evolution memory allocation. I put together a quick dtrace oneliner which gives a distribution for evolution startup:
bash-3.00$ dtrace -c /usr/lib/evolution-2.6 -n 'pid$target::malloc:entry {@howmuch=quantize(arg0);}'
dtrace: description 'pid$target::malloc:entry ' matched 2 probes
CalDAV Eplugin starting up ...

(evolution-2.6:104389): camel-WARNING \*\*: camel_exception_get_id called with NULL parameter.
\^Cdtrace: pid 104389 terminated by SIGINT



           value  ------------- Distribution ------------- count
               0 |                                         0
               1 |                                         3414
               2 |@                                        12502
               4 |@@@@@                                    45218
               8 |@@@@@@@                                  71301
              16 |@@@@@@@@@@@@                             117177
              32 |@@@@@@@@@                                84371
              64 |@                                        14154
             128 |@@                                       15120
             256 |@                                        8680
             512 |                                         4517
            1024 |                                         4119
            2048 |                                         1193
            4096 |                                         784
            8192 |                                         1263
           16384 |                                         25
           32768 |                                         112
           65536 |                                         10
          131072 |                                         4
          262144 |                                         1
          524288 |                                         0

Joerg also pointed out that my "where evolution mallocs" oneliner was printing (N X M) stack traces and that one of the pair of output numbers was meaningless because it represented the count of that unique combination:
dtrace -c /usr/lib/evolution-2.6 -n 'pid$target::malloc:entry {@howmuch=quantize(arg0); @where[arg0,ustack()]=quantize(arg0)}
Where N was the number unique allocations and M was the number of unique stack traces. Its not as easy to do this correctly in a oneliner, so as soon as possible I'll put together a little script for profiling where the allocations are taking place.

One thing that is easily obvious from the above histogram is that evolution allocations are weighted towards very small amounts (2 bytes?!!!) Solaris's slab allocator should help in these circumstances. The gtk 2.10 talk was interesting, apparently GSlice uses an allocation scheme similar to that used by Solaris's slab allocator. You can't keep a good idea secret forever, can you?

I'll try to blog more about this if I have time and reliable connectivity.

BTW, why are the GUADEC wifi dhcp-servers handing out the same IP address to several MAC addresses?
Jun 28 15:24:46 sligo ip: [ID 903730 kern.warning] WARNING: IP: Hardware address '00:0e:35:07:69:1b' trying to be our address 010.000.007.027!
I guess the opportunity for IP address collision at an event like guadec is the reason why dhclient uses a very time consuming and paranoid arp broadcasting scheme to make sure that I'm not using someone's IP.

Thanks to whoever attended our Dtrace talk, I wish we had more time so I didn't have to fly through the demos, but it really is a technology you have to play with to fully appreciate.
Comments:

Post a Comment:
Comments are closed for this entry.
About

bnitz

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today