Rudder2

Members
  • Posts

    134
  • Joined

  • Last visited

About Rudder2

  • Birthday 01/18/1981

Converted

  • Gender
    Male
  • Location
    Niceville, FL

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Rudder2's Achievements

Apprentice

Apprentice (3/14)

4

Reputation

  1. Yup, it's for sure was the power save governor issue. Thank you for your help. Never would of figure this out on my own.
  2. I can confirm this is the problem. Issuing "echo active > /sys/devices/system/cpu/intel_pstate/status" command fixed the parity check speed problem also. I've also noticed my server idles @ 10% instead of 35% after issuing the command. Guess this command goes in to the GO file.
  3. Preliminary check makes me think this might of been the problem. I will report back Friday when my Parity Check Starts. I just created a user script to issue "echo active > /sys/devices/system/cpu/intel_pstate/status" command every Wednesday @0500, 30 minutes after my automated reboot, to see how it works, I don't like messing with the GO file unless I have to. My CPU was locked at 1200 MHz instead of being able to go to 3000 MHz as needed. I noticed my Gaming VM, Web UI, and SMB shares were sluggish but didn't think much of it till I read that thread you posted. After running "echo active > /sys/devices/system/cpu/intel_pstate/status" from the SSH Terminal my WebUI, Gaming VM, and SMB shares are snappy again. I have the Tips and Tricks plugin installed and my only CPU governor options are Power Save, Performance, or Scheduled.
  4. It's a problem with saving the file. I can copy and paste the screen print... Nevermind...It's truncated.
  5. Just typed it instead of coping and pasting and received the same result.
  6. This is what I got: # lspci -vv > /boot/lscpi-vv.txt pcilib: sysfs_read_vpd: read failed: Input/output error pcilib: sysfs_read_vpd: read failed: Input/output error pcilib: sysfs_read_vpd: read failed: Input/output error
  7. Here's the Diagnostics 10 Hours in to the Parity Check running on 6.9.1. On 6.8.3 the Parity Check would be complete in 4 hours...It won't be...It's estimating 13 more hours to go when it use to only take 14 HRS and 30 Minutes. rudder2-server-diagnostics-20210326-0913.zip
  8. I can confirm that this worked for fixing the Parity Check after clean shutdown. I will gather the Diagnostic Data Friday AM and upload it to see if we can figure out why my Parity check is now ~50% the speed after updating from 6.8.3 to 6.9.1.
  9. unRAID usually works. When it doesn't I know Linux so usually can fix it myself. I've very rarely had a problem since I started running unRAID the July of 2014 so I'm not verse on getting help...Sorry about that...Would think that this is a testament to the quality LimeTech offers unRAID as a Server OS.
  10. Figured it happened during the update so y'all would know what you did that could of caused that... Parity check will start Thursday Evening if it doesn't start with the automated reboot like it has been. Will do it Friday AM so Parity Check has been running 12 hours or so. I wouldn't of EVER downloaded a Diagnostics with a Parity check running till you asked for it. Never would of crossed my mind because I try to not do anything with my server, other than the automated stuff which I have non critical stuff not happen during Parity Check or Rebuild.
  11. I just tried this. Will see how it works when I have my automated restart Wednesday AM. So what about the Parity Check being 50% of the speed since the update?
  12. Ever since I upgraded from 6.8.3 to 6.9.1 if I shutdown the server with the /usr/local/sbin/powerdown or reboot the server with /usr/local/sbin/powerdown -r when the system reboots it always performs a parity check like it didn't cleanly shutdown. Also, my Parity check average is 66 MB/s instead of 116 MB/s like it was on 6.8.3.