Benefit of a Cache SSD?

[Endda]

I just finished setting up my unRAID box a month or so ago with the help of some people within this community(and thank you for answering all of my questions before).

 

While learning about unRAID, I have found out that it's possible to add a cache drive and that using an SSD drive for this is very beneficial. However, I'm curious to learn about what exactly the unRAID box will benefit from by adding in a cache SSD drive now that everything has been set up. I'm also curious about what changes I will have to make in order to have my current set up benefit from the cache drive.

 

I have some basic docker apps setup, couchpotato, sonarr, sabnzbd and plex. If I add in an SSD drive to the unRAID box, set it as a cache drive, what will be the immediate benefits of this addition? I assume that it will increase the speed in which I can copy data to the unRAID box. . .but is that it?

 

Will I need to go into the Docker tab, and reconfigure my installed applications to use that cache drive(like making things download to the cache drive first), or will the whole unRAID box, and my Docker apps, know to use the cache drive automatically?

 

Thanks in advance for any insight into these questions

[Stokkes]

Hello Endda!

 

I just came back to unRAID after a 3-4 year hiatus. In migrating my system back to unRAID, I took advantage of using an SSD cache drive.

 

The way unRAID is built is that any writes to your disks, the system needs to not only write that data, but it also needs to compute the parity for each block of data being copied. This means if you have VMs, or file operations occurring, every single operation will have a parity computation cost. Add a few parallel writes together and you'll notice from time to time the possibility of a sluggish system.

 

The point of the cache drive (or cache pool if you have more than 1) is exactly how it sounds, it caches any new writes to the unRAID system first on the cache drive. There is then a mover script that moves the data automatically from the cache drive to your protected array (this is configurable, default once a day).

 

It's a good practice to put your often-accessible files (such as your Plex library, that's a great example) on the cache drive. This will significantly improve Plex's performance (navigating the library, connecting, scanning, etc.). You can set specific user shares (i.e.: update for your docker containers) to be "cache only", meaning the mover script that runs once a day (or whenever you set it) will not move the data on that specific share.

 

By default however, if you are only using 1 cache drive, any data stored on the cache drive (either permanently in a cache-only share, or temporarily for new files that have yet to be copied by the mover script) are at risk for data loss if your cache drive fails. In v6, Lime-Tech implemented the ability to create a "cache pool", meaning you can put 2 SSDs (or more) and it will build a btrfs RAID1 volume (btrfs RAID1 works differently than traditional RAID1, insofar as it will ensure that each block of data is replicated across the entire pool).

 

All in all, if you're downloading things or extracting files (i.e. sonarr, sab, etc.) you would significantly benefit from having an SSD as a cache. Otherwise, every time you were to download and go through the extraction process, you'd be hitting the array pretty hard and slowing down almost everything else.

 

There's another little known benefit to the cache drive as well (whether it be SSD or not), and that's a common mistake new people make in that if they use Sabnzbd or Nzbget to download to let's say /mnt/user/download, well when it downloads a file, it will already be on your array, meaning when it sab or sonarr moves that tv show or movie to the /mnt/user/movies folder, it may not take into account your split-level settings if you have any in your User shares (unRAID will not move files from disk to disk if the file is already on the array, to satisfy the split level rules).

 

I'm sure others will chime in with more in depth benefits.

 

Cheers,

 

[Endda]

I have noticed some sluggish performance on the box while downloading lots via sabnzb. For example, if I download media A and it is finished downloaded, media B(the next thing in the sabnzb queue) will download very very slowly while sabnzb verifies, repairs and extracts media A

 

There's another little known benefit to the cache drive as well (whether it be SSD or not), and that's a common mistake new people make in that if they use Sabnzbd or Nzbget to download to let's say /mnt/user/download, well when it downloads a file, it will already be on your array, meaning when it sab or sonarr moves that tv show or movie to the /mnt/user/movies folder, it may not take into account your split-level settings if you have any in your User shares (unRAID will not move files from disk to disk if the file is already on the array, to satisfy the split level rules).

 

I do have sabnzbd to download to a user share, but I'm not sure I understand what you're talking about with the bolded part. I'm not sure what a split level rule is, or what you mean by it. My sab/sonarr/couchpotato stuff seems to be downloading and moving things properly

 

Would I see much of a benefit to use one of my current mechanical hard drives as a cache drive? I had assumed that I would only see the benefit if it was an SSD, but if setting one of my extra storage drives as a cache could help out with this sluggish performance when verifying/extracting things, then I would be eager to try it out.

 

I had assumed the sluggish performance was due to a weak CPU chip as I only put a 'Intel Pentium G3220 Haswell Dual-Core 3.0GHz LGA 1150' in there. . .but you make it seem like it's because of my setup and not the chip

[SSD]

Benefits:

 

1 - Installing Dockers and VMs on the SSD will provide significantly higher performance when running such apps on the server. Especially Dockers. I replaced my wife's laptop hard disk with an SSD and she couldn't stop saying how much faster it is.

 

2 - They never spin down so you encounter none of the spinup delays.

 

3 - Simultaneous accesses are hugely faster. So if you are DLing, PAR correcting, and unRARing on the same volume, the performance will blow away any spinning drive.

 

I do not cache my writes to the server. Doing so delays getting files onto the parity protected array. Writing to a cache drive does speed up the "apparent" write speed if you are sitting watching it, but you do have to pay the piper eventually. So in truth cached writes take more total time writing to the array than non-cached.

 

When the cache drive was invented, write performance with unRAID maxed out at about 12 MB/sec. With the cache you could get about 50 MB/sec. That was 4x the speed, and well worth it. Today you can get 40-45 MB/sec uncached, and cached maybe 60 MB/sec over ethernet. That bump just not worth it to me.  And although SSD technology is improving, it is still limited in the number of write cycles. Having every bit of new data go through the SSD will wear it out quite a bit faster than not. Finally, you'd like need a larger cache and would want to consider a cache pool (2 SSDs) to protect your cache. More expense.

 

A huge cache drive is not a necessity. I have a 250G, but even a 120G would do if your VMs are modest. A ~$100 it is a no brainer IMO.

[Endda]

Benefits:

 

1 - Installing Dockers and VMs on the SSD will provide significantly higher performance when running such apps on the server. Especially Dockers. I replaced my wife's laptop hard disk with an SSD and she couldn't stop saying how much faster it is.

 

2 - They never spin down so you encounter none of the spinup delays.

 

3 - Simultaneous accesses are hugely faster. So if you are DLing, PAR correcting, and unRARing on the same volume, the performance will blow away any spinning drive.

 

I do not cache my writes to the server. Doing so delays getting files onto the parity protected array. Writing to a cache drive does speed up the "apparent" write speed if you are sitting watching it, but you do have to pay the piper eventually. So in truth cached writes take more total time writing to the array than non-cached.

 

When the cache drive was invented, write performance with unRAID maxed out at about 12 MB/sec. With the cache you could get about 50 MB/sec. That was 4x the speed, and well worth it. Today you can get 40-45 MB/sec uncached, and cached maybe 60 MB/sec over ethernet. That bump just not worth it to me.  And although SSD technology is improving, it is still limited in the number of write cycles. Having every bit of new data go through the SSD will wear it out quite a bit faster than not. Finally, you'd like need a larger cache and would want to consider a cache pool (2 SSDs) to protect your cache. More expense.

 

A huge cache drive is not a necessity. I have a 250G, but even a 120G would do if your VMs are modest. A ~$100 it is a no brainer IMO.

 

Thanks for the heads up. I definitely was looking at a 120GB one for about 70 on Amazon(Samsung)

 

Since I already have Docker setup on my regular storage, can I ask what is needed to get everything switched over?

 

Will I need to go into the Settings -> Docker and then change the Docker.img over to the cache drive? Will it copy over my entire Docker apps/setup to the cache drive or will I need to install the Docker apps and set them back up all over again?

[SSD]

Thanks for the heads up. I definitely was looking at a 120GB one for about 70 on Amazon(Samsung)

 

Since I already have Docker setup on my regular storage, can I ask what is needed to get everything switched over?

 

Will I need to go into the Settings -> Docker and then change the Docker.img over to the cache drive? Will it copy over my entire Docker apps/setup to the cache drive or will I need to install the Docker apps and set them back up all over again?

 

I cannot give you a step by step as it is not something I have done. I believe that you'd be able to copy the docker.img from the old cache to the ssd, but not sure of the exact steps. I will PM RobJ and point him to this thread. He is doing a lot of work on the wiki and if it is not there already, this seems a worthy topic.

[Endda]

Thanks for the heads up. I definitely was looking at a 120GB one for about 70 on Amazon(Samsung)

 

Since I already have Docker setup on my regular storage, can I ask what is needed to get everything switched over?

 

Will I need to go into the Settings -> Docker and then change the Docker.img over to the cache drive? Will it copy over my entire Docker apps/setup to the cache drive or will I need to install the Docker apps and set them back up all over again?

 

I cannot give you a step by step as it is not something I have done. I believe that you'd be able to copy the docker.img from the old cache to the ssd, but not sure of the exact steps. I will PM RobJ and point him to this thread. He is doing a lot of work on the wiki and if it is not there already, this seems a worthy topic.

 

Awesome! Thank you for that. I definitely appreciate any help with this

[RobJ]

Howdy Ennda, and my apologies for the long delay.  I wasn't sure how to respond, as I prefer speaking and writing about things when I feel I know what I'm talking about!  And I have 3 areas I'm weak in - VM's, Dockers, and User Shares.  I haven't used them, apart from trying the Krusader Docker for a few minutes to see how well it would work for new users, as a replacement for MC.  I do appreciate Brian calling on me now and then, I really like to help, but not when I know others would be far better.

 

Based on my understanding (not an expert, just lots of reading), moving docker.img is a matter of stopping Docker, deleting the current image, then re-enable Docker and recreating it in the desired location (/mnt/cache/docker.img is recommended), then re-adding your current templates.  All of that is in a guide by JonP, found here.  Your settings should be safe, and nothing else is moved or changed, so once your templates are restored and the Dockers are started, they *should* work just the same.  Then you can decide when and if(!) to move any other paths to the Cache drive.  It's not an all or nothing project.  Here is a post where the user moved Plex, off then back on the Cache drive.  For others, it may be obvious, or you may need to ask within the support topic for a particular Docker, as to how to move the data storage or download locations.