thezyth

Members
  • Posts

    44
  • Joined

  • Last visited

Everything posted by thezyth

  1. After doing some more research it seems that the controller might be overheating. Going to repaste the controller and maybe zapstrap a 40mm fan on top of it.
  2. Some more info I can provide. The parity checks seem to speed up to 100mb/s and drops down to anywhere between 10-25mb/s. The speeds seem to increase and just drop down again. I have also attached another diagnostic while the speeds were at 2.9 mb/s. Hopefully this can be of use. The speeds also seem to be slow even when the server is not being accessed. zeus-diagnostics-20220505-1649.zip
  3. Unforunately that did not last...its back at 20mb/s
  4. Okay as soon as I changed it form On-Demand to Performance it boosted up to 100mb/s. Will report back and let you know if it stays stable at that speed. Attached another diagnostic after setting it to performance. zeus-diagnostics-20220505-1214.zip
  5. I'll try to provide as much info as I can because I'm kind of lost as to what the issue could be. I've been getting super slow parity checks dropping from the usual 80-120mb/s to roughly 20mb/s. I did upgrade my single 8tb parity drive to two parity drives 14tb. System Specs: The ASR 72405 controller is set to HBA Mode CPU scaling governor is set to ON-Demand Unradi Version: 6.10.0-rc5 Below are some Diskspeed Test and the diagnostic. Please let me know if you have any suggestions I can try. I don't have another controller that I can use to test if it is still somehow the controller. Tests were run with no docker containers running or any VM's. The diagnostic was pulled while the parity check was running. Diskspeed Test: Controller Benchmark: The cache_downloads SSD is dying but I don't think that should cause any issues with parity checks. Please let em know if you have any suggestions that I can try to fix this! zeus-diagnostics-20220504-1359.zip
  6. I fixed my issue by going into the config.ini and changing the IP address from 192.168.1.29 to 0.0.0.0
  7. Any help/update on this? Please ignore I was able to fix this!
  8. I keep getting that OS Error for some reason. Nuked image and redid all settings again. Worked for a bit and then it died agian and back to the weird error.
  9. Still same error after nuking the docker image and reinstalling all apps
  10. I still keep getting that error..maybe the docker img is corrupted.
  11. Hey how did you revert the docker to a older version?
  12. You were correct on the controller being the issue. I set the controller into HBA mode and I haven't had any issues since! Thank you!
  13. 2021-08-26 21:55:36,925 - root (1503f556a7d0) : ERROR (check_update:25) - Error trying to get releases from Github. Http error. 2021-08-26 21:55:37,152 - root (1503eefb2d00) : INFO (signalr_client:41) - BAZARR trying to connect to Sonarr SignalR feed... 2021-08-26 21:55:37,157 - root (1503eefb2e10) : INFO (signalr_client:105) - BAZARR trying to connect to Radarr SignalR feed... 2021-08-26 21:55:37,181 - root (1503eec93040) : INFO (signalr_client:129) - BAZARR SignalR client for Radarr is connected and waiting for events. 2021-08-26 21:55:37,252 - root (1503eefb2d00) : INFO (signalr_client:56) - BAZARR SignalR client for Sonarr is connected and waiting for events. 2021-08-26 21:55:37,254 - root (1503f556a7d0) : INFO (server:37) - BAZARR is started and waiting for request on http://192.168.1.77:6767 Traceback (most recent call last): File "/app/bazarr/bin/bazarr/main.py", line 214, in <module> webserver.start() File "/app/bazarr/bin/bazarr/server.py", line 40, in start self.server.serve_forever() File "/usr/lib/python3.8/site-packages/gevent/baseserver.py", line 398, in serve_forever self.start() File "/usr/lib/python3.8/site-packages/gevent/baseserver.py", line 336, in start self.init_socket() File "/usr/lib/python3.8/site-packages/gevent/pywsgi.py", line 1545, in init_socket StreamServer.init_socket(self) File "/usr/lib/python3.8/site-packages/gevent/server.py", line 180, in init_socket self.socket = self.get_listener(self.address, self.backlog, self.family) File "/usr/lib/python3.8/site-packages/gevent/server.py", line 192, in get_listener return _tcp_listener(address, backlog=backlog, reuse_addr=cls.reuse_addr, family=family) File "/usr/lib/python3.8/site-packages/gevent/server.py", line 288, in _tcp_listener sock.bind(address) File "/usr/lib/python3.8/site-packages/gevent/_socketcommon.py", line 563, in bind return self._sock.bind(address) OSError: [Errno 99] Address not available: ('192.168.1.77', 6767) Bazarr starting... Bazarr exited. The error I seem to be getting
  14. Stats page and diagnostics while pairty sync is running. zeus-diagnostics-20210821-1424.zip
  15. I still seem to be getting inconsistent speeds. Sometimes it goes up 180 mb/s and then drops down to 30mb/s. I removed the SMR drive also. I'm kind of out of ideas at this point. Any suggestions?
  16. Moving data off the Seagate SMR drive to another drive. Will report back after.
  17. The speeds seem to increase for a few seconds and tapper of...is this normal behaviour?
  18. I do have one SMR drive within the array. Could this be the cause of the slow downs?
  19. I moved data off the last two old drives onto a different drive. Pulled the old drives out and did a new config. The current speed of the parity sync is now back to 25-30 mb/s... :') No docker containers running no VM's running. I'm so confused at what it could be.
  20. I ended up just canceling the rebuild because the data on the drive is not that important. I started a new config and did a new pairty sync. The pairty sync is going much much faster than the rebuild. I'm kind of confused as to what the issue could be. The sync is going at 100mb/s while the rebuild was maxing out at 30mb/s....
  21. Do you have different controller in mind that would work better? I'm currently doing a rebuild of disk 1 and it seems to be slowed down to a crawl again. Only getting 20mb/s on the rebuild right now. I have attached a new diagnostic. More info: Rebuilding a 2tb drive that failed on me to a 8tb drive which was shucked. Full Specs of build: PSUS upermicro PWS-1K62P-1R MOBO X9QFI-F+ SAS BackplaneBPN-SAS-846A Raid Controller ASR 72405 Ram 4gb DDR3 1333 MHZx16 CPU E5-4650 x4 zeus-diagnostics-20210817-1311.zip
  22. Haven't had any issues since the rebuild/restart. I think everything should be okay! Thanks for your help guys!
  23. I'll look into the System Event Log once the rebuild is done! Hopefully the CPU isn't going bad.
  24. I'll try to buy a different controller when I get a chance and see if that makes a difference.