for all things debian I'm copying the maintainer and see if he cares to comment on your patch. I am getting ready to push a new release so if it's good with him it's good with me.
30 seconds to start? wow! I would have shot myself by now if that happened to me and at the very least would have never bothered to even develop collectl. I've always run extensive timing tests to make sure it was really fast including the time to load perl. I just tried your test for timing the help command and it only took 0.187s total time. I tried it on a smaller box at home and it tool 0.26 seconds. Perhaps busybox is very inefficient or doesn't have enough memory or a real slow disk? Have you tried using collectl to monitor collectl? Run collectl in one window and fire up another copy and see where the system is spending all it's time. Could you be swapping or something really basic? I just tried monitoring the start of collectl with another copy running at a monitoring interval of .1 and watching all CPUs with -sC. I did see one hit 100% but only for 1 cycle. I don't think I could easily make some of the code conditionally load because it's too intertwined. -mark On Mon, Mar 11, 2013 at 1:29 PM, Christopher Cordahi <[email protected]> wrote: > Hi, > > Thanks for this useful utility. I've installed collectl 3.6.5 to run > as a daemon to monitor the system resources of my embedded product. > > Unfortunately the busybox start-stop-daemon [1] my system uses only > accepts the --test option with the --stop option, not --start. As > such I've made the attached use_stop_to_test_if_running.patch patch. > I believe using --test with --stop would be safe in all installations > using the start-stop-daemon. > > [1] http://git.busybox.net/busybox/tree/debianutils/start_stop_daemon.c > > I have another issue, I don't think much can be done about it, but if > anyone can suggest anything, it would be greatly appreciated. > collectl takes a fairly long time to start, during which the CPU is > very busy. Even on my fast desktop, it can take almost a second to > start. This is easily seen just by requesting help, see following > examples. Is this simply the time required for perl to parse the > source files? Would it be possible to separate the code required for > playback mode from that of daemon/capture mode? > > root@centaur-3_0009:~# time collectl --help > /dev/null > > real 0m30.418s > user 0m23.880s > sys 0m1.990s > > root@centaur-3_0009:~# time collectl --help > /dev/null > > real 0m21.656s > user 0m18.200s > sys 0m0.880s > > Except for the above, everything works wonderfully. Thanks again for > the fine utility. > > -- > Chris > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Collectl-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/collectl-interest > ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Collectl-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/collectl-interest
