[Rear-users] Profiling ReaR

Dag Wieers dag at wieers.com
Thu Jun 2 01:05:28 CEST 2011


Hi,

Jeroen and I discussed improving ReaR's performance.

A normal 'rear mkrescue' run on my laptop takes up 109 seconds (including 
cfg2html) or 84 seconds (without cfg2html). Since our use-case has an 
operator waiting for ReaR to return a beep before unplugging, we'd like to 
make sure ReaR is as efficiently as possible.

Breaking this lapse out, we get:

   19:50:18 start    ->   1 sec
   19:50:19 layout   ->   1 sec
   19:50:20 rescue   ->   1 sec
   19:50:21 cfg2html ->  25 sec
   19:50:46 build    ->  17 sec
   19:51:03 pack     ->  41 sec
   19:51:44 output   ->  22 sec
   19:52:06 cleanup  ->   1 sec
   19:52:06 exit      = 109 sec

Excluding cfg2html from the equation, there's the build, pack and output 
stages to improve. Since output is mostly writes to USB, there's not much 
to improve there.

On a second run I did an outbreak:

   00:34:24 prep     ->   0 sec
       200 procs/sec
   00:34:24 layout   ->   1 sec
       400 procs/sec, 15% cpu
   00:34:25 rescue   ->   1 sec
       400 procs/sec, 15% cpu
   00:34:26 cfg2html ->  25 sec
        75 procs/sec, 10% cpu (cfg2html)
   00:34:51 build    ->  19 sec
       615 procs/sec, 25% cpu (rear)
   00:35:10 pack     ->  34 sec
       1 procs/sec,   25% cpu (gzip)
   00:35:44 output   ->  21 sec
      10 procs/sec / 100% disk-util / 3.5MB/sec
   00:36:05 cleaup   ->   0 sec
   00:36:05 exit      = 102 sec

Which seems to indicate there may be room for optimization in the build 
and pack stages. In the build phase the high number of forks per second is 
very obvious, during the pack phase the bottleneck is the single-threaded 
gzip.

If we can optimize the build phase (hot paths), and if we can get rid of 
the CPU bottleneck (fast gzip), we might reduce the total run with 20 to 
30 seconds.

Any insights are welcome,
-- 
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]




More information about the rear-users mailing list