Description of problem: currently there is no collectl available for EPEL8 Version-Release number of selected component (if applicable): 4.3.0-5 or 4.3.1 How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: there is no EPEL8 package Expected results: the package should be available Additional info:
Steffen, are you willing to help with the maintenance? I am already over full capacity and don't want to commit to more :-(
*** Bug 1912540 has been marked as a duplicate of this bug. ***
I'm (very slowly, sorry) working with Steffen so he could maintain collectl for EPEL. But there is a bigger issue, the upstream author retired from HPE in 2019 and the project is unmaintained, thus the future is unknown, see https://sourceforge.net/p/collectl/mailman/message/36739724/
I have created a github for collectl and started looking at perhaps taking over maintenance. https://github.com/loberman/collectl.git I need to refresh my Perl and other things but have been involved with it for 20+ years Regards Laurence
great news, thanks I have a git repo locally with all releases between 2.3.1 and 4.3.1, if you like to use it ...
actually it's https://github.com/sharkcz/collectl :-)
Hello Dan, I did not know you were active on this. I contacted Mark Seger and said I would get with him to sync up on a few things. I have been collaborating with Mark on collectl things for years. I am going to initially own this to get it updated as we uncovered a new issue this week with large CPU count servers. My Manager Lisa Concelli is working to get somebody on the tooling team to take over long term maintenance. I will continue to contribute and help as necessary. Regards Laurence
Hello Laurence, I was only maintaining the collectl package for Fedora, all functional work has been done by Mark, with whom I was solving the occasional packaging related issues. The git repo is my private "clone" of the upstream releases to better track any Fedora specific differences and I forgot to mention it earlier. I can say I even forgot I made it public on github :-) I have mentioned it here now in case it would make sense to preserve the history, which could be useful perhaps. It would be great if someone could take over the project itself.
Understood and thank you. I am refreshing my sadly old Perl knowledge. My brain is totally overwritten with Python, so I had to buy an updated Perl book today :( Most of my assistance to Mark was kernel internals about which counters could be used/trusted etc. and generic Linux performance assistance to Mark. I did mess with some of the Perl but it's been years so yeah that's where I am. So lets see how I do with this new bug. I started reading the code again We have a 384 8 NUMA node system where we see better USR/SYS than we should see with the -sc playback versus the -sc --verbose. The sc --verbose is correct as it matches vmstat. This caught us at an escalation this week where we were watching dynamically live using -scmnd and it suddenly looked a lot better. When it really was not. Example (very truncated) -sc # <----CPU[HYPER]-----> #Time cpu sys inter ctxsw 00:00:10 67 39 508K 599620 00:00:20 81 48 501K 628408 00:00:30 75 43 532K 556541 00:00:40 71 39 556K 573917 00:00:50 73 40 553K 574186 00:01:00 70 36 567K 495131 00:01:10 70 35 578K 497011 00:01:20 73 40 591K 740914 00:01:30 72 40 604K 772423 00:01:50 74 43 578K 752961 00:02:00 73 40 625K 825762 00:02:10 73 40 607K 778240 00:02:20 72 40 560K 628458 00:02:30 71 39 559K 604379 00:02:40 70 39 564K 623619 00:02:50 67 39 559K 645375 00:03:00 70 41 563K 686921 00:03:10 68 37 581K 689021 00:03:20 66 38 576K 696066 00:03:30 66 39 563K 662551 00:03:40 65 36 577K 689348 00:04:00 67 38 564K 665769 -sc --verbose Which was correct # CPU[HYPER] SUMMARY (INTR, CTXSW & PROC /sec) #Time User Nice Sys Wait IRQ Soft Steal Guest NiceG Idle CPUs Intr Ctxsw Proc RunQ Run Avg1 Avg5 Avg15 RunT BlkT 00:00:10 27 0 36 1 1 1 0 0 0 31 384 508K 599K 119 9505 432 189.59 188.95 233.37 371 13 00:00:20 33 0 45 1 1 1 0 0 0 16 384 501K 628K 153 9502 414 223.78 196.32 235.29 418 13 00:00:30 31 0 40 1 1 1 0 0 0 23 384 532K 556K 119 9524 305 242.53 201.25 236.48 309 16 00:00:40 32 0 36 1 1 1 0 0 0 26 384 556K 573K 64 9516 268 255.75 205.44 237.46 292 20 00:00:50 33 0 37 1 1 1 0 0 0 24 384 553K 574K 66 9510 283 261.71 208.35 238.07 308 11 00:01:00 34 0 32 0 1 1 0 0 0 28 384 567K 495K 56 9491 318 275.46 213.08 239.29 293 14 00:01:10 35 0 31 1 1 1 0 0 0 28 384 578K 497K 39 9512 304 277.80 215.64 239.84 302 23 00:01:20 32 0 37 2 1 1 0 0 0 24 384 591K 740K 70 9507 340 292.51 220.82 241.27 350 33 00:01:30 32 0 36 2 1 1 0 0 0 25 384 604K 772K 62 9462 367 302.92 225.42 242.55 289 36 00:01:50 31 0 40 3 1 1 0 0 0 22 384 578K 752K 79 9453 308 318.76 234.06 245.02 314 25 00:02:00 33 0 36 2 1 1 0 0 0 23 384 625K 825K 44 9441 363 324.50 238.10 246.22 323 31 00:02:10 32 0 37 2 1 1 0 0 0 23 384 607K 778K 46 9440 310 330.04 242.12 247.44 309 23 00:02:20 31 0 37 1 1 1 0 0 0 26 384 560K 628K 68 9443 288 328.32 244.70 248.23 272 13 00:02:30 32 0 36 1 1 1 0 0 0 27 384 559K 604K 47 9442 284 332.05 248.22 249.34 305 21 00:02:40 30 0 36 1 1 1 0 0 0 28 384 564K 623K 58 9439 263 331.54 250.87 250.19 293 22 00:02:50 27 0 36 1 1 1 0 0 0 30 384 559K 645K 59 9434 317 327.02 252.57 250.75 279 17 00:03:00 29 0 38 1 1 1 0 0 0 27 384 563K 686K 76 9418 254 326.73 254.95 251.54 290 24 00:03:10 31 0 34 1 1 1 0 0 0 29 384 581K 689K 42 9406 285 326.17 257.20 252.31 303 15 00:03:20 28 0 34 1 1 1 0 0 0 31 384 576K 696K 61 9416 280 323.31 258.84 252.89 316 13 00:03:30 27 0 36 1 1 1 0 0 0 31 384 563K 662K 71 9411 274 319.13 260.04 253.35 273 17 00:03:40 28 0 33 1 1 1 0 0 0 32 384 577K 689K 53 9377 305 317.95 261.68 253.95 282 22 00:04:00 29 0 35 1 1 1 0 0 0 30 384 564K 665K 54 9390 276 325.29 267.01 255.87 260 15
On code review No bug -sc shows combined usr/sys Working as designed
Hello We have the latest changes here url = https://github.com/sharkcz/collectl.git Can we please push to get this for EPEL in rhel8 Regards Laurence Oberman
EPEL 8+9 branches requested: https://pagure.io/releng/fedora-scm-requests/issue/42924 https://pagure.io/releng/fedora-scm-requests/issue/42925