On Mon, Mar 11, 2013 at 2:54 PM, Mark Seger <[email protected]> wrote: > 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.
Thanks, let me know if there are any questions or issues. > 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. I get similar start-up time results on PC. The 0.5 s to 1.0 s I reported earlier was running collectl and perl in a cygwin session on a Windows PC. Running collectl and perl in Ubuntu in VM running on the same PC, I reliably get 0.27 s start-up. > Perhaps > busybox is very inefficient or doesn't have enough memory or a real > slow disk? "BusyBox is a multi-call binary that combines many common Unix utilities into a single executable." I don't think it can contain perl; it definitely doesn't in my system where perl is the standard 5.10.1 release. Memory isn't an issue. If I shut down all my applications, collectl reports over 100 MB free along with another 100 MB in caches and buffers which are easily discarded. The instrument doesn't have a real disk, it uses UBIFS on NAND Flash, but this doesn't appear to be the issue. > 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. At 1 s update, CPU statistics go from 95+% idle to constant 0% idle as a second instance of collectl starts. Almost all of the CPU is in user level, sys contains the rest and varies between 0% and 12%, mostly very low. > Could you be swapping or something really > basic? There is no swap enabled. > 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. When I use the .1 s interval, the precision is much lower, everything is a multiple of 10 and the instance of collectl that is doing the monitoring takes about 30% of the CPU. Most intervals have 100% user, but the few sys spikes are much higher than before, up to 50%. > I don't think I > could easily make some of the code conditionally load because it's too > intertwined. OK, thanks for considering it and for all the suggestions above. By scattering a few print statements throughout collectl, I see that most of the time is spent loading and parsing the files collectl (before first line of code) and formatit.ph (require "$ReqDir/formatit.ph"). This is why I was hoping that separate files could be loaded depending on the usage; reading system information, writing daemon raw files, reading daemon raw files, outputting to console. > > -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 >> -- 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
