Jump to content

[SOLVED]Memory usage Question


Recommended Posts

Hello, on my unraid server I have cashe_dirs running with 4GB of memory, when I run the top command I see that I am using 3.9GB and have only .1GB free.

 

I’m wondering if this is normal and if I want to run Plex or air video what are my options?  

 

If I upgrade memory would cashe_dirs take up that free space?  

 

What would be a good amount of memory to run cashe_dirs and Plex or air video?

 

Thx for the help

 

Link to comment

I myself have 4GB memory in my server while running cache_dirs and Plex. I have not had any issues at all. The memory dips down to as low as ~10MB available when im building a new library or watching a movie or something along those lines. If nothing is being streamed and server is idle, my situation is much like yours, majority of the memory is being utilized, but i have never run into any out of memory errors or anything like that. I was also however thinking of adding another 4GB since memory is so cheap now.

Link to comment

So if i understand you the system will adjust the memeroy usage to fit the current needs of the server.  Meaning it would shrink cache_dirs memory usage if another program needs more memory?

 

Not necessarily cache_dirs specifically - just the overall system cache.

 

Everytime you do some disk i/o the kernel will try to cache it in any unused memory - at some point it will fill your memory but this is fine as it can juggle the amount used for caching to let your programs have what they need. If your programs need more the memory / disk cache will be reduced accordingly.

 

cache_dirs just runs a perpetual find loop over all your disks, which reads the metadata of the directory structure / filenames etc and forces the kernel (as it's being read from disk) to put it into the cache. Next time you do a dir listing - it comes from the cache rather than disk and avoid potential spin ups.

 

So yes, in principle you're correct.

Link to comment

cache_dirs just runs a perpetual find loop over all your disks...Next time you do a dir listing - it comes from the cache rather than disk and avoid potential spin ups.

 

I'm confused by this.  if it's running a perpetual loop over all the disks, isn't *that* keeping them spun up, in order to read them?

 

doing this cache_dirs mod is on my agenda, but this confuses me.

 

I will eventually install a cache drive, and figure it will stay spun up due to the plugins I'll be running, but I want the rest of the disks to sleep when possible.

 

thanks

Link to comment

cache_dirs just runs a perpetual find loop over all your disks...Next time you do a dir listing - it comes from the cache rather than disk and avoid potential spin ups.

 

I'm confused by this.  if it's running a perpetual loop over all the disks, isn't *that* keeping them spun up, in order to read them?

If the data is in the linux disk buffer cache, it is read from there, and the physical disks are not accessed at all.  So no, unless that data ends up being the least recently accessed, it is not reused by a different process requiring memory.  That is also why the loop needs to scan all the disks every few seconds... to make sure the metadata does not end up the least recently accessed.

 

Joe L.

Link to comment

Thank you.  I completely believe you, but I'm still confused.

 

In my mind, in order to to scan all the disks every few seconds, it would need them active.  I'm guessing since it works, that I just had an incorrect understanding, and that this scanning does not require them to be spinning.

 

Either way, I need to get this working on my box soon, waiting for directories to open is no fun  >:(

Link to comment

I believe what Joe is saying is this..

 

To help keep the OS efficient, the kernel itself caches data to ram. (not to be confused with cache_dirs itself).

That the the kernel cache starts to flush older data from its cached data in  RAM.

In order to keep the metadata for the drives at the top of the "recently used" list, Cache_DIRs does a rescan of the drives on a schedule.

Because the Metadata for the drives is still somewhere in the Kernels RAM Cache, it only has to read the metadata (thus simulating a physical drive read) that is still in RAM. doing this bumps the cache_dirs metadata back to the top of the recently used kernel cache in RAM.

 

If I understand this correctly, It sounds pretty efficient and a neat hack to do this.

Link to comment

Because the Metadata for the drives is still somewhere in the Kernels RAM Cache, it only has to read the metadata (thus simulating a physical drive read) that is still in RAM.

 

If I understand this correctly, It sounds pretty efficient and a neat hack to do this.

 

That makes perfect sense, thanks.  I agree, very clever solution.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...