December 12, 20205 yr Hi all! I am having an issue that I just can't seem to put my finger on. I constantly have 50% or more of my CPU being used and I have no idea what's causing it. I've attached a pic of terminal with htop running beside it as well as graphs from a direct play on Plex. I've tried turning off Docker, VMs, and it's still hovering at 50%. I only have 1 cache and 1 data drive (system running on an HP290). I know this Celeron isn't the highest performing CPU, but this seems a bit odd. FWIW, I was having the same issue on my older Xeon 1226v3 on my old machine. Meanwhile, my memory is also being hammered by Log and I don't know what that means. Any ideas? scout-diagnostics-20201212-0730.zip Edited December 12, 20205 yr by drogg Added diagnostics
December 12, 20205 yr Community Expert Do you have syslog server running? Also try booting in safe mode.
December 12, 20205 yr Author 7 minutes ago, JorgeB said: Do you have syslog server running? Also try booting in safe mode. Not sure what the syslog server is. How would I check? What should I be looking out for in safe mode?
December 13, 20205 yr Community Expert 20 hours ago, drogg said: Not sure what the syslog server is. How would I check? Settings -> Syslog Server 20 hours ago, drogg said: What should I be looking out for in safe mode? If it helps or not.
December 22, 20205 yr Author Ok, just want to follow up. I did a complete reinstall - only carried over my license number. The ONLY other thing I'm running is a mergerfs mount with rclone and Sonarr/Radarr/DelugeVPN, but I'm not seeing how those would be hammering the CPU all day. Any ideas? Diagnostics attached. scout-diagnostics-20201221-2009.zip
December 22, 20205 yr Community Expert If you stop the array is CPU still pegged? I'm battling a similar issue, although it didn't appear in 6.8.3, might be some suggestions that help you there.
December 22, 20205 yr Author 9 minutes ago, tjb_altf4 said: If you stop the array is CPU still pegged? I'm battling a similar issue, although it didn't appear in 6.8.3, might be some suggestions that help you there. Stopping the array drops it to 1% (if that).
December 22, 20205 yr Community Expert 4 minutes ago, drogg said: Stopping the array drops it to 1% (if that). I noticed in your screenshot plex is doing a scan, try starting your array but not running Plex and see what usage is like. The culprit might be Plex being over zealous.
December 22, 20205 yr Author I've actually been watching it for the last 10 minutes without a scan, and after the rclone mount has been added. Plex is at 2%, max right now (no scans), while streaming a video. I'm going to start every docker one at a time to see if maybe a docker has gone wild. EDIT: Things were going like they should be until I opened NZBGet. As soon as it opened, the CPU and process shot up and won't subside. Interestingly, this was happening on my previous install...when I was using Sabnzbd. EDIT EDIT: According to advanced view on the Docker tab, NZBGet is only using 1%. So I'm thinking it's not actually NZBGet after all. EDIT EDIT EDIT: It just appears out of nowhere 11 minutes after the server is rebooted. I installed the Open Files plugin and it showed me a random video file was open, so killing that has fixed the error. I will keep monitoring. Edited December 22, 20205 yr by drogg
December 24, 20205 yr Author Just going to keep bumping this in hopes of help. It seems like I have extremely high iowait. What causes this? I run one NVMe, one HDD. I keep everything besides seeding downloads on the cache, and I wouldn't expect to slow my server to a crawl whenever Sonarr or Lidarr copy files. Any help would be much appreciated! I'm at a complete loss here,
December 27, 20205 yr I have a similar issue with cpu usage being pegged with all VMs stopped and docker stopped. No shares are being accessed, and nothing is being written. CPU load goes up to 51% on a 4 core i7. I've disabled the one file caching plug in. And also noticed, since the -rc1/rc2 releases, disks are never spun own.
Archived
This topic is now archived and is closed to further replies.