May 30, 20197 yr Hi, I am having incredible high cpu usage between 50 ~100% on my Unraid server v6.6.7. It runs on an i5-4570 but has most of the time 1, 2 or 4 of the 4 cores running at 100%! I have 1 docker with plex running, but even when I am not streaming anything I still have the high CPU usage. Because of this I can hardly transfer or watch any file to the server. It also causes poor transer speed between a few KB and 20MB at max. Did I misconfigure something? In the attachment you'll find my diagnostics. Who can help me out? Kind regards, Jordy tower-diagnostics-20190530-1859.zip
May 30, 20197 yr Greetings, I think one clue here is this line when you run top (or from your diagnostics): %Cpu(s): 0.0 us, 1.6 sy, 0.0 ni, 0.0 id, 98.4 wa, 0.0 hi, 0.0 si, 0.0 st Note the 98.4% listing for wa - this shows that it's not so much the CPU that's generating load, it's that the CPU is waiting for IO. This points to a disk error, and sure enough, looking through your syslog also shows some errors. Note that the drive on ATA11.0 (TOSHIBA MD04ACA4) is showing frequent resets as the board attempts to adjust the communication speed. I haven't had time to carefully comb through the logs but first glance indicates this is more of a drive issue than an actual cpu load issue (although it'll show as 'load' - note the load indication in command 'top' - top line right.) If this was me, I'd run a full SMART test on the Toshiba disk - which appears to be disk2 in your array. You might find a bit of relief by moving critical stuff OFF disk2 for now (if you can - the disk definitely seems a bit dicey.) Check cables and monitor your syslog - you really want to stop those 'reset' messages - these ones: Quote May 30 18:08:15 Tower kernel: ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen May 30 18:08:15 Tower kernel: ata11.00: failed command: WRITE DMA EXT May 30 18:08:15 Tower kernel: ata11.00: cmd 35/00:40:d8:5b:71/00:00:74:00:00/e0 tag 27 dma 32768 out May 30 18:08:15 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) May 30 18:08:15 Tower kernel: ata11.00: status: { DRDY } May 30 18:08:15 Tower kernel: ata11: hard resetting link May 30 18:08:16 Tower kernel: ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 300) May 30 18:08:16 Tower kernel: ata11.00: configured for UDMA/100 May 30 18:08:16 Tower kernel: ata11.00: device reported invalid CHS sector 0 May 30 18:08:16 Tower kernel: ata11: EH complete May 30 18:08:46 Tower kernel: ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen May 30 18:08:46 Tower kernel: ata11.00: failed command: WRITE DMA EXT May 30 18:08:46 Tower kernel: ata11.00: cmd 35/00:20:58:5c:71/00:00:74:00:00/e0 tag 30 dma 16384 out May 30 18:08:46 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) May 30 18:08:46 Tower kernel: ata11.00: status: { DRDY } There's another user here who can probably give you even better advise but that's my take on this issue. Hope it helps, Del
June 1, 20197 yr Author Hi Del, Thank you for helping me out. I ordered extra sata cables to see if it would solve the issues. In the mean time I moved the disk2 to another slot to see if it would solve the issues. I doesn't contain important data and I thought it was worth the try. I did not realize that Unraid had to rebuild the whole share. This would be fine with me, but I have an average parity sync speed between 6 and 25 MB which will take more than 2 days to rebuild. On the high CPU load, the numbers provided by top do not match with the CPU load in the webgui. I am willing to believe that top provides the real values but I find it strange that I see 80% CPU load on average among 4 cores with 3 of 4 cores running at 100% while top says a CPU utilization of 4%... I did a reboot and initiated the rebuild for now. The CPU utilization dropped to normal proportions so my problems seems to have solved itself. I'll keep an eye on it to see if anything weirds happens. For now I'll leave it at it is and close this topic.
Archived
This topic is now archived and is closed to further replies.