zcot wrote: ⤴Mon Jun 28, 2021 11:30 pm
you can add a line for debugging for a while, for the
texeci 3 sensors call. Something like:
${voffset -9}THERE ARE ${threads} THREADS.
This gives me around 1367 threads, fluctuating up and down by a few. This is the total thread count on my machine, not sure if this is helpful, though? Or is there a way to make it only show the threads of that
texeci 3 sensors call?
zcot wrote: ⤴Mon Jun 28, 2021 11:30 pmAlso in the conky config you look at that same attitude with the initiation of the audacious call. It would probably be better to do it more like the lampp call where you execi at first. That would eliminate any lost count or resets, and plus you are already checking against the status inside of the audacious script so you don't need it in that conky block.
I'm trying to do that already with the
${if_match "${audacious_status}" == "Playing"} line, which I think is roughly the same as what you're suggesting, isn't it? This uses Conky's API for Audacious and restricts the block that calls
aud_song.sh to only execute when Audacious is actually "Playing". This saves a lot of unnecessary calls to the aud_song.sh script that would otherwise execute with each iteration of Conky (every second or so). And even when that aud_song.sh script is called, it only makes the call to aud_song.sh every 3 seconds with
execi (only when Audacious is actively playing a song). And that script was only querying the song title if Audacious is playing, which was redundant, yes, so I removed the
playback_status check in aud_song.sh.
zcot wrote: ⤴Mon Jun 28, 2021 11:30 pmYou could also do that block with merely the execi call to the script and just do everything in the script, and create a conky string to return, if needed, if "Playing", and use the ${conky_parse} with it.
If I do that then Conky calls the aud_song.sh script on every iteration of Conky (or 3 sec, if I use execi), instead of only when Audacious is playing a song. That would be too costly, in my opinion.
Thank you for the suggestions, though, since I am still trying to figure this out.
As for debugging, here are the results of my little un-scientific test, performed over the course of 5 days, after I improved the
${texeci 3 sensors call from Termy. During the test I just opened
htop and watched it for a few minutes, recording the highest and lowest CPU values of the active threads (usually just two appear to do the bulk of the work out of the total 12 threads).
Conky CPU usage
Code: Select all
Sat Jun 26, 12:15pm: 1.5-3% and 0.1% Mem usage
Sun Jun 27, 12:15pm: 1.9-3.8% and 0.1% Mem usage
Sun Jun 27, 8:46pm: 0.6-2.6% and 0.1% Mem usage
Sun Jun 27, 10:46pm: 1.3-5.1% and 0.1% Mem usage
Mon Jun 28, 3:45pm: 1.9-6.4% and 0.1% Mem usage
Mon Jun 28, 9:15pm: 1.3-7.5% and 0.1% Mem usage
Tue Jun 29, 1:05pm: 3.2-9.6% and 0.2% Mem usage
Tue Jun 29, 5:13pm: 3.8-10.9% and 0.2% Mem usage
Tue Jun 29, 6:15pm: 3.8-12.2% and 0.2% Mem usage
Tue Jun 29, 9:48pm: 5.1-12.8% and 0.2% Mem usage
Tue Jun 29, 11:00pm: 5.1-15.5% and 0.2% Mem usage
Wed Jun 30, 12:00pm: 5.8-17.0% and 0.2% Mem usage
Wed Jun 30, 2:47pm: 5.7-18.4% and 0.2% Mem usage
Wed Jun 30, 6:00pm: 5.8-19.9% and 0.2% Mem usage
Even with the
${texeci 3 sensors} change, it's still creeping up in CPU usage and I still don't know why. Any other ideas? Does anyone else's Conky do this?
I doubt it'll fix the issue, but it might.
