What's wrong with attached pic, have to wait whenever trying to access gui of docker apps

[jang430]

Whenever I try to right click on Sab, CP, Sonarr, etc. icons to access webgui, there will always be a wait (sometimes up to 5 seconds), before the options to access webgui appears.  I've attached a copy of my dashboard, and netdata at a period in time, where usage is low, but still slow.  Has this anything to do with me downloading in sab at 5 MBps?  Furthermore, I don't see how to allocate more resources to the app that's causing all the delay.  Kindly check screenshot.

 

 

[Squid]

Could be client side.  Close all your tabs, then reopen the browser with just the one to unRaid

[1812]

and put a fan on your hard drives.

[jang430]

Hi.  It's not the PC I'm using to access it though.  Nor the browser.  This happens even on a different PC/ browser.

 

Noted on the fan   But I believe it's not the one causing delay in access to docker apps.

[jang430]

Anyone think it's because processor Xeon E3-1240 v2 too slow?  Or memory is lacking?  8 GB?

 

I have to say though I've seen access to Webgui much faster on AMD A8 chips, Running 4 GB.

[bonienl]

There are several known reasons why the GUI responses are slow.

 

1. Missing 'ntp' 'avahi' user accounts, upgrade to unRAID v6.3.4 will automatically create the missing accounts

2. Adblocker, anti-virus or firewall software interfering with the GUI, whitelist the GUI and exclude its IP address from tracking

 

[jang430]

bonienl, 

 

I just upgraded to v6.3.4 earlier, haven't restarted.  I do have Adblocker enabled, AV, and Firewall at home.  Will consider it.

 

Thanks!

[bonienl]

AV is known to interfere, search this forum for related stories and solutions.

 

[runraid]

Open your case and put a floor fan blowing into your PC until you get proper cooling. That many drives that hot looks dangerous.  

[jang430]

Sounds like a good idea runraid.  Haven't gotten around buying them pwm fans yet. 

[unevent]

At the time of your pics your five or so second delay is to be expected based on the load average shown in htop.  You have a four core CPU with 9+ loading which appears to be from I/O loading.  The netdata page shows iowait is what is holding things up (CPU is basically waiting for I/O to finish).  Could use iostat to help locate which disk is the culprit, but looks like not installed by default and doesn't appear to be available in the nerd pack either.  Based on the top four processes in htop being python with the next process being shfs I would assume you have some post processing going on which is disk intensive.  Is interesting the netdata disk I/O meters are not showing all that much going on (~33MB/s), however.  Slow disks and/or anemic controller or is there more than one post process being done on same disk?

[jang430]

Hi unevent.  That's a wealth of information you're sharing   Unfortunately, I don't have an answer.  I've seen a few post processing happening together in Sabnzbd, but not sure if that is what's happening during that time.  In general, it's my user experience when I try to access webgui, I find the web pages don't come up immediately.  My disks are old though, and may be 1 of the reasons for slow post process? Hence the wait?

[unevent]

The closer the load average gets to 4 with your cpu the slower your server will be to respond and at the 9+ you had at the time of that pic things were a bit frustrating I'm sure.

[jang430]

Thanks unevent.  I'll try to learn how to read this charts, and reports.  Can probably help me address this system better.  So for the moment, you think an upgrade in RAM will help?  I assume processor isn't the issue here either, right?  Disk activity being the most likely culprit?

[unevent]

Thanks unevent.  I'll try to learn how to read this charts, and reports.  Can probably help me address this system better.  So for the moment, you think an upgrade in RAM will help?  I assume processor isn't the issue here either, right?  Disk activity being the most likely culprit?

Memory looks fine based on the data displayed. More memory is not a bad thing, but i think the issue is slow disks or something slow related to disks. Post a diagnostics and will take a look.

Sent from my ASUS_Z00AD using Tapatalk

[jang430]

Hi unevent, diagnostics generated with Unraid even without actual file transfer or downloading happening realtime?  Will diagnostics give accurate results?

tower-diagnostics-20170523-1750.zip

Edited May 23, 2017 by jang430

[unevent]

I see a few issues.  You have a couple Hitachi disks that are rather slow (sustained data rate (MB/sec) 64.8 - 31 (zone 0 - 29)), disk 2 which is the Seagate ST2000DL003-9VT166_6YD04VWX has read errors and you have performed a parity sync with read errors (corrections to parity made) and there are disk capacity/disk full issues as well.  Suggest tackling your disk and capacity issues and things should improve.

Edited May 23, 2017 by unevent

[jang430]

Hi unevent, yes, the Hitachi drives are my cache drives. Figured they act in redundant, so ok to have 1 of them conk out anytime. As for the Seagate, what do you mean by 'performed parity sync with read errors?' The errors are written onto parity? Integrity of data sacrificed?

Sent from my LG-D855 using Tapatalk

[unevent]

May 7 parity check was started, later canceled then later started a correcting check.  Encountered multiple read errors on disk 2, parity completion status of 0.

May 14 parity check started, multiple read errors again, corrections to parity:

Disk 2:
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428432
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428440
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428448
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428456
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428464
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428472
May 14 05:55:40 Tower kernel: md: recovery thread: P corrected, sector=2628428480

May 21, parity check again, no corrections.

 

I did notice your parity checks are occurring a couple hours before the mover is scheduled.  Might want to separate those so they do not overlap.  Also  performing parity checks this often is not necessary.  It is also wise to run non-correcting checks before running correcting checks just for scenarios such as this were there are disk issues.  I gather these parity checks are on a schedule, and if true, I suggest turning that feature off - it is a bad idea unless they can be forced to be non-correcting checks.  Disclaimer: there is a lot going on in the logs and I might have missed something.  I see one correcting check, not sure if the noted parity corrections were done with a correcting check.  Older unRAID versions used to state clearly correcting vs non-correcting checks.  I think now is says 'check correct' and just 'check' for non-correcting, but could be wrong.  Check cables for disk 2 ST2000DL003-9VT166_6YD04VWX, it may be what is causing the read errors.  I see no pending sector counts, however, hardware ECC recovered error count is high with 25 uncorrected errors being reported.  27,654 power-on hours, however, it is not the oldest disk in the collection.  I would not trust this disk until the problem with it is found and corrected or the disk replaced and then ran through a preclear cycle or two.

Edited May 23, 2017 by unevent

[jang430]

Wow, after reading your initial comment, I looked at diagnostics, but couldn't find what you are saying. Which particular log do I study? To be honest, ha enough idea Parity Check was happening that often. I will try to check where to stop the error correcting from happening automatically. Will it help if instead of replacing the drive entirely, I just preclear it all over again?



Sent from my LG-D855 using Tapatalk

[unevent]

Wow, after reading your initial comment, I looked at diagnostics, but couldn't find what you are saying. Which particular log do I study? To be honest, ha enough idea Parity Check was happening that often. I will try to check where to stop the error correcting from happening automatically. Will it help if instead of replacing the drive entirely, I just preclear it all over again?



Sent from my LG-D855 using Tapatalk

if you can replace the drive that will give you more time to work with the faulty drive to determine if it is cable related or faulty drive. The ECC hardware error count is very high and there were a significant number of uncorrectable errors. This info is in the smart report for the disk. The other info was gathered from the syslog files and the pic you posted.

Sent from my ASUS_Z00AD using Tapatalk

[jang430]

Thanks unevent.  Will study it further.