Slow WebUI


Recommended Posts

Greetings Unraid!

 

I'm a fresh user of Unraid. Only  got started this week with it and so far I'm very impressed!

 

It's mostly going fine for me for the moment, had some disk issues and stuff I dealt with...Now however I've noticed that my dockers webUI are loading extremely slowly. Plex has the most issues out of all of them. I can't even load the dashboard when launching plex. I'm never maxing out on CPU or RAM, far from it actually.

 

I've also noticed (dont know if related) that I never max out my download speed on nzbget. It's around 2-4MB/s all the time. My max is around 31MB/s usualy..

 

Does anyone have any ideas? Like I mentioned I'm a rookie when it comes to unraid so I'm not sure really what to look for. I've attached my diag if that helps!

tower-diagnostics-20180327-0651.zip

Link to comment

Were you running a parity check when this diagnostic was taken? Of course, parity checks will impact other I/O.

 

I see you have set your docker image to 40GB. And you had gotten warnings of it filling up before. This is almost certainly a sign of misconfigured dockers writing into the image instead of into mapped unRAID storage. If things are working correctly you won't need nearly that much space for docker image, and it won't fill up.

 

I see you have almost filled up a 500GB cache also. Are you still doing the initial data load on this server? Probably makes more sense to not cache for the initial load.

 

See the Docker FAQ linked in my sig for more about filling up docker image. If you can't see my sig, go to the upper right of this forum page, click on the dropdown and go to Account Settings and turn on View signatures.

Link to comment
21 minutes ago, trurl said:

Were you running a parity check when this diagnostic was taken? Of course, parity checks will impact other I/O.

 

I see you have set your docker image to 40GB. And you had gotten warnings of it filling up before. This is almost certainly a sign of misconfigured dockers writing into the image instead of into mapped unRAID storage. If things are working correctly you won't need nearly that much space for docker image, and it won't fill up.

 

I see you have almost filled up a 500GB cache also. Are you still doing the initial data load on this server? Probably makes more sense to not cache for the initial load.

 

See the Docker FAQ linked in my sig for more about filling up docker image. If you can't see my sig, go to the upper right of this forum page, click on the dropdown and go to Account Settings and turn on View signatures.

Hi!

 

Thanks for useful information!

 

I have checked all my docker paths and im pretty sure they're correct? (see image)

 

 

I'm unsure what you mean with the initial data load to be honest. Where do I check this? :)

I went through your signature and checked the FAQ, great info but as a rookie on this topic I'm not sure I can guarantee I've done it correctly.

 

I'll post a new diag here, made sure im not running parity  check.

 

docker.png

tower-diagnostics-20180327-1525.zip

Link to comment

In addition to the docker mappings, you have to go into each application and make sure each application is configured so that it is only writing into the mapped container volumes. Writing into something other than the mapped container volumes is exactly what causes docker image to fill up.

 

By initial load, I just mean are you currently copying a lot of data to your server? People often set up a new server and then copy a lot of stuff to it in the beginning.

 

If not, why is your cache drive so full?

 

Link to comment
14 minutes ago, trurl said:

In addition to the docker mappings, you have to go into each application and make sure each application is configured so that it is only writing into the mapped container volumes. Writing into something other than the mapped container volumes is exactly what causes docker image to fill up.

 

By initial load, I just mean are you currently copying a lot of data to your server? People often set up a new server and then copy a lot of stuff to it in the beginning.

 

If not, why is your cache drive so full?

 

 

Ah how stupid of me not to think of it.... I went in and looked at the folder sizes. It looks like nzbget is filling it up with the downloads im doing. But isn't that the point really? Download to the cache -> Move it to the array?

 

 

/mnt/cache/appdata/nzbget/downloads is where 388Gb is currently holding

 

 

 

On the other note, I'm not doing any other transfers. I completely wiped my library and everything when I redid my server into unraid. I know that wasn't neccesary but it was fine for me. I'd rather start over :)

 

Worth to note: I am downloading ALOT of stuff currently, am I downloading too fast or something? (My downloading speed is quite slow as mentioned).

 

Ive gone through all dockers i have and got the screenshots below. To me they look fine?

docker3.png

docker4.png

docker2.png

Link to comment

I don't see anything obvious in the screenshots. You might take a look at the section of the Docker FAQ that talks about filling up due to excessive logging.

 

As for the cache drive filling up. you might reconsider how you actually want each of your user shares to use cache. Most of the writes to my server are unattended downloads (sound familiar?) or scheduled, unattended backups, and I am not at all concerned with how long these writes take since I am not sitting there waiting for them to complete. So I have these user shares set to not use cache and they get written directly to the array where they are protected by parity. Any share you do have set to cache-yes is just going to be rewritten to the array at a later time anyway, an (additional?) unattended write.

 

How often do you have mover scheduled? If you are really downloading that much in just one day (the default mover frequency) it is going to be working pretty hard to move it all. 

Link to comment
39 minutes ago, trurl said:

I don't see anything obvious in the screenshots. You might take a look at the section of the Docker FAQ that talks about filling up due to excessive logging.

 

As for the cache drive filling up. you might reconsider how you actually want each of your user shares to use cache. Most of the writes to my server are unattended downloads (sound familiar?) or scheduled, unattended backups, and I am not at all concerned with how long these writes take since I am not sitting there waiting for them to complete. So I have these user shares set to not use cache and they get written directly to the array where they are protected by parity. Any share you do have set to cache-yes is just going to be rewritten to the array at a later time anyway, an (additional?) unattended write.

 

How often do you have mover scheduled? If you are really downloading that much in just one day (the default mover frequency) it is going to be working pretty hard to move it all. 

 

 

It makes more sense to have the usenet downloads not to go to cache. Since the speed is not really needed there anyways (I have max 31Mbit/s download so it can't bottleneck on a HDD right?). Then I should reconfig it to store on the array I suppose.

Link to comment
2 hours ago, ohdear94 said:

It makes more sense to have the usenet downloads not to go to cache. Since the speed is not really needed there anyways (I have max 31Mbit/s download so it can't bottleneck on a HDD right?). Then I should reconfig it to store on the array I suppose

To me its the opposite.  Makes more sense for downloads to go directly to cache.  You don't need to worry about always having two or more drives spun up currently, and who cares about redundancy on a download, since if the cache drive happens to fail, Radarr/Sonarr will simply just download it all again...

Link to comment
3 hours ago, Squid said:

To me its the opposite.  Makes more sense for downloads to go directly to cache.  You don't need to worry about always having two or more drives spun up currently, and who cares about redundancy on a download, since if the cache drive happens to fail, Radarr/Sonarr will simply just download it all again...

I just dont understand the point. Why download to the cache at all? What benefit is it really. Its gonna be moved to the array anyhow so its just an extra write? 

Link to comment
27 minutes ago, ohdear94 said:

I just dont understand the point. Why download to the cache at all? What benefit is it really. Its gonna be moved to the array anyhow so its just an extra write? 

  • Verifying, Repairing, and Unpacking etc will take a ton more time, and result in massive thrashing on both the parity drive and data drive(s) storing the downloads.  
  • From a power / $ perspective, you're saving more because you're only using a very low power cache drive for everything vs 2 power hungry spinners for an extended period of time insead of the minutes required for mover to do its thing on the file at night

But, ultimately at the end of the day the results will be the same, and its all up to you.

 

Link to comment

If you are downloading so much that mover takes a significant chunk of time, then ideally you would set things up so that downloads go to cache but the final stage of post-processing targets the array.

 

At the other end of the spectrum is my downloading, where very little is automated since I am not interested in TV Series and only occasionally add to my Movie collection.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.