Activity for Bill Torpey
-
Bill Torpey posted a comment on discussion Help
On Dec 2, 2022, at 10:26 AM, Mark Seger markseger@users.sourceforge.net wrote: I think you may be confused about collectl data collection. When you collect process data your get a lot more than is displayed. You can then play it back multiple times and choose to display different process options from same collection, see --helpsuboopts. Also, no need to run once to collectl process data and a second time for system disk or other data. Just collectl it all in one go and play back with --vmstat or...
-
Sorry if that wasn't clear: we run collectl once to get per-process cpu utilization (--procopts kw4096 -sZ -oDG), a second time to get per-process memory utilization (--procopts mkw4096 -sZ -oDG), a third time to get system-wide network utilization (-sN -oD), and fourth to get vmstat (--export vmstat -oD). All of that is from the same .raw file(s). Again, we did it that way just so we could run both collectl and our old monitoring tools and compare like-for-like. We'll be changing that to generate...
-
Thanks Laurence, I'll check that out. FWIW, attached is the kind of output we get from vmstat.
-
Hi Mark (and Laurence): First off, thanks for all the help, and for a great tool! Please see replies inline below: Bill - I guess the one overall question I'd ask is about your general use of collectl and why you have a handful of smallisk files you need to play back together and also way none of your files are compressed? We've recently switched to collectl for monitoring our QA performance testing environment, with a view to rolling out collectl in production. collectl is replacing a bunch of custom...
-
Right -- you're just removing the check for "-s". I've been running with that patch in my local copy for a week or so and have not seen any problems. Looks good to me! and Thanks!
-
Here's the directory listing: [btorpey@bt-brix7 collectl]$ ls -lh *.raw -rw-r--r-- 1 btorpey shared 102M Nov 22 09:36 csappia01-20221110-223734.raw -rw-r--r-- 1 btorpey shared 2.0G Nov 22 09:36 csappia01-20221111-000000.raw -rw-r--r-- 1 btorpey shared 2.0G Nov 22 09:36 csappia01-20221112-000000.raw -rw-r--r-- 1 btorpey shared 1.1G Nov 22 09:36 csappia01-20221113-000000.raw The result of running the system collectl: [btorpey@bt-brix7 collectl]$ time /usr/bin/collectl -p '*.raw' --export vmstat -oD...
-
Hi -- I'm back... Have run some tests, and my results seem to indicate that: Without quotes, wildcarding the "-p" param results in only the first file being processed (bash guarantees that filenames are returned in alpha order) With quotes, collectl processes all files, subject to "--from" parameter It doesn't matter whether you use single or double quotes Presence/absence of "--from" parameter makes no difference. Except with "--export vmstat": collectl will NOT process multiple files -- at the...
-
Hi -- I'm back... Have run some tests, and my results seem to indicate that: Without quotes, wildcarding the "-p" param results in only the first file being processed (bash guarantees that filenames are returned in alpha order With quotes, collectl processes all files, subject to "--from" parameter It doesn't matter whether you use single or double quotes Presence/absence of "--from" parameter makes no difference. Except with "--export vmstat": collectl will NOT process multiple files -- at the end...
-
Just the one file -- not all? Was there anything on stderr?
-
FWIW, simply removing the check fixes: sub vmstatInit { #error("-s not allowed with 'vmstat'") if $userSubsys ne ''; error("-f requires either --rawtoo or -P") if $filename ne '' && !$rawtooFlag && !$plotFlag; error("-P or --rawtoo require -f") if $filename eq '' && ($rawtooFlag || $plotFlag); $subsys=$userSubsys='cm'; } $ /shared/collectl/collectl -p 'csappia01-*.raw' --from 20221110:23:52:30-20221113:04:57:08 --export vmstat -oD | tail 20221113 04:56:59 0 0 0 45165M 332M 65719M 2472M 63521M 0 0...
-
It's true that there's other stuff in the directory, but it shouldn't matter? $ ls -lh total 5.2G -rw-rw-r-- 1 btorpey shared 102M Nov 14 17:42 csappia01-20221110-223734.raw -rw-r--r-- 1 btorpey shared 3.2M Nov 11 00:00 csappia01-20221110-223734.raw.gz -rw-rw-r-- 1 btorpey shared 2.0G Nov 15 12:06 csappia01-20221111-000000.raw -rw-r--r-- 1 btorpey shared 78M Nov 12 00:00 csappia01-20221111-000000.raw.gz -rw-rw-r-- 1 btorpey shared 2.0G Nov 15 12:06 csappia01-20221112-000000.raw -rw-r--r-- 1 btorpey...
-
Weird -- not what I see: $ ls -lh *.raw -rw-rw-r-- 1 btorpey shared 102M Nov 14 17:42 csappia01-20221110-223734.raw -rw-rw-r-- 1 btorpey shared 2.0G Nov 15 12:06 csappia01-20221111-000000.raw -rw-rw-r-- 1 btorpey shared 2.0G Nov 15 12:06 csappia01-20221112-000000.raw -rw-rw-r-- 1 btorpey shared 1.1G Nov 15 12:06 csappia01-20221113-000000.raw $ collectl -p 'csappia01-*.raw' --from 20221110:23:52:30-20221113:04:57:08 --export vmstat -oD | tail 20221110 23:59:52 0 0 0 114G 321M 1832M 370M 1725M 0 0...
-
When exporting with vmstat format using a wildcard filespec, the first file processes OK but the second fails with "Error: -s not allowed with 'vmstat'". Sample command: collectl -p 'collectl/csappia01-*.raw' --from 20221110:23:52:30-20221113:04:57:08 --export vmstat -oD Obviously the "-s" is not on the command line, but it appears to be coming from somewhere? Thanks in advance for any help...
-
Similar issue with boost (include/boost/config/detail/select_stdlib_config.hpp): #if defined(__cplusplus) && defined(__has_include) # if __has_include(<version>) // It should be safe to include `<version>` when it is present without checking ...
-
For example, here's what I get from one sample of a particular process: proc:10385 stat 10385 (tpsdaemon) S 1 8783 8783 0 -1 1077944320 3273 0 0 0 0 0 0 0 20 0 15 0 985166519 2243244032 4006 18446744073709551615 4194304 4630248 140731205735328 140731205733344 140394182363493 0 0 0 2076278527 18446744073709551615 0 0 17 8 0 0 0 0 0 6728944 6731732 25190400 140731205741431 140731205741653 140731205741653 140731205746638 0 proc:10385 Tgid: 10385 proc:10385 Uid: 1118 1118 1118 1118 proc:10385 VmPeak:...
-
Thanks Mark! I assume that whatever collectl is collecting is in the raw file, so I unzipped that (using cat | gunzip) and grep'd out one of the pid's I was interested in to see what was being collected. I use the following DaemonCommands in /etc/collectl.conf, which I think is grabbing pretty much everything: DaemonCommands = -f /var/log/collectl -r00:00,7 -m -F60 -i 1:1:60 -scCdDmMnNstZ --procfilt ctpsdaemon,ctpsworker,fappia,ctimestensubd,ctimestenrepd,cdropcopy,cnsd,ccollectl
-
Thanks Laurence, Mark for the quick replies, and my apologies for not getting back sooner. In the meantime, I've been combing through the docs for collectl, /proc, etc. to see if there's another way to get the data I'm looking for, or if I've misunderstood something along the way. To backtrack a bit, my initial question about shared memory was because I wanted to be certain that shared memory didn't get included in some of the other metrics that collectl collects from /proc. We really wanted to monitor...
-
I'm trying to figure out a way to get processes' shared memory usage from collectl, and I'm not having much luck. Our application connects directly to a database which uses shared memory, and I'd like to exclude this memory from the amount used, but I can't find it anywhere. I see some comments in the code (e.g., "added nr_shmem to memory -P stats") but don't know where to go from there. Any help would be most appreciated!
-
Brilliant! Thanks so much! I had no idea that --procopts w took a parameter, but that does the trick. P.S. As for the unzipping the raw.gz file -- that worked a treat also. Thanks again to you and Mark for a terrific piece of software!
-
I don't know what collectl is storing internally -- I've tried unzipping the .raw.gz file, but I get "unexpected end of file".
-
Thanks. This has nothing to do with java per se -- it's just that our java processes have really long command lines -- when we get them from collectl they are truncated after approx 1K characters. The question is whether collectl stores the full command line, and if so, whether there is any way to get the full command line from collectl.
-
When extracting data from raw.gz. file (e.g., with "--procopts w -sZ -oD") it appears that the command string is truncated after approx. 1K characters. In our case, we launch java processes with very long --classpath parameters, so we lose the last part of the command line, which for us is the most significant. Is there any way to get collectl to output the full command line? P.S. I do understand that we can avoid this problem by using e.g., CLASSPATH environment variable -- that would require changes...
-
Hi all: I'm trying to enter this at trac.cppcheck.net, but I'm starting to think...
-
Hi again! I'm curious if there's any documentation re: return codes from cppcheck...
-
Hi (again): At the risk of seeming pedantic, I recently started using the 1.73 release,...
-
Hi (again): At the risk of seeming pedantic, I recently started using the 1.73 release,...
-
I've noticed some differences in output depending on the --std= parameter defined,...
-
Thanks for the info! FWIW, I started out by comparing the output of cppcheck --doc/--errorlist...
-
I notice some new checks in 1.72, as well as overall improvements -- thanks! But...
1