Calculating Memory

Spud

Contributor
Joined
Oct 23, 2011
Messages
117
This might seem like a silly question but I cannot seem to find the answer so...

When calculating the amount of memory needed for a system with say 6 x 6TB drives using Z2 do you use the total RAID space 36 or the total data space 24?

So is that 36G or 24G of memory just needed for the storage? I'm guessing 24

If anyones interested I used this site https://jsfiddle.net/Biduleohm/paq5u7z5/1/embedded/result/
 

anmnz

Patron
Joined
Feb 17, 2018
Messages
286
What you do is, you ignore that outdated rule of thumb (your question doesn't actually have an answer, the rule was never meant to be that precise, and anyway it does not scale well to today's system sizes) and tell us what you will be using the system for! :) 8GB is the required minimum and may be sufficient if all you are doing is storage. 16GB would probably be a better choice. 32GB would let you run quite a few jails/VMs happily. It all depends on what you will be using the system for.
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
Max out your system ram and just don't think about it. :D
 

kdragon75

Wizard
Joined
Aug 7, 2016
Messages
2,457
Based on the information provided, you NEED at least 128GB RAM and a 1TB PCIE SSD.

JK. I have no clue.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
This might seem like a silly question but I cannot seem to find the answer so...

When calculating the amount of memory needed for a system with say 6 x 6TB drives using Z2 do you use the total RAID space 36 or the total data space 24?

So is that 36G or 24G of memory just needed for the storage? I'm guessing 24

If anyones interested I used this site https://jsfiddle.net/Biduleohm/paq5u7z5/1/embedded/result/

@anmnz is close to the mark.

I am the party who originally bumped the minimum required RAM for FreeNAS with ZFS to 8GB upon observation that lower amounts resulted in unstable systems. So I'll explain the history here - firsthand sources are the best. ;-)

Systems with 4GB or 6GB of RAM used to see instability and data loss issues with ZFS. These are scattered throughout the early days of the forum, users with AMD APU's that maxed out at 4GB RAM, etc. If you put a stupid-large amount of storage on a system with insufficient RAM (let's say 32TB on 8GB) we also used to see instability, defined as lockups or panic events. Because there's been a historical ZFS rule of thumb to try to provision 1GB of RAM per TB of disk, I created some more modern guidance (at the time, ~2012-2013) and played the wording on it to be deliberately vague.

So the question is ... Is it:

1) Actual consumed space on the pool?
2) Total available pool space?
3) Total raw disk space?

The rule as I wrote it was deliberately vague. Home hobbyists who are hoping to store more data on less RAM are allowed to read it permissively and should consider something between 1) and 2). Serious enterprise users who demand performance should be looking more towards 3). This is a rule of thumb. It isn't a hard requirement. Your system requires what it requires. But that's a useless answer to people trying to build a NAS. So some sort of sizing guidance was necessary.

As HDD sizes have ballooned and ZFS has matured, though, and as you get away from stupid-small 8GB RAM sizes, the rules soften up and there's also a huge component of "what sort of things are you doing" that play a huge role. If you try to put 64TB of HDD on an 8GB RAM system, I *guarantee* you will see poor performance and you may even experience instability, though such reports are rather uncommon these days, so perhaps that is no longer a concern. But the system will not have sufficient metadata caching ability to rapidly find new free disk space or rapidly access many files. But does that 64TB require 64GB RAM? Probably not. You might get away with 32GB or 24GB without noticeable impact. But if you are driving the system heavily, you *still* might need 128GB (or more!) of RAM to get decent performance.

It is fine to start smaller and add RAM if you are unhappy. So the best advice for you is to start with the lower amount of RAM, and make sure that you are not putting something dumb like 2GB modules into your system and filling up all the RAM slots ("slot stuffing").
 

Spud

Contributor
Joined
Oct 23, 2011
Messages
117
What you do is, you ignore that outdated rule of thumb (your question doesn't actually have an answer

Ok no dramas, I already have 32G so I guess I have nothing to worry about then, thanks dude!
 

Spud

Contributor
Joined
Oct 23, 2011
Messages
117
@anmnz is close to the mark.

I am the party who originally bumped the minimum required RAM for FreeNAS with ZFS to 8GB upon observation that lower amounts resulted in unstable systems. So I'll explain the history here - firsthand sources are the best. ;-)

So the question is ... Is it:

1) Actual consumed space on the pool?
2) Total available pool space?
3) Total raw disk space?

The rule as I wrote it was deliberately vague.

Ok so I don't keep up with all the latest happens on here and didn't know about this rule being well over ruled shall we say. So my post was more out of curiosity then anything really, but I do appreciate you explaining things, Thanks! :)

My current system is a supermicro x10sl7-f with 32G as that is the maximum amount of ram that board can take. An M1015 also and I have 10 x 3T in Z3 and 6 x 2T in Z2 at the moment with 5 jails running and 1 VM thats runs 24/7.

I do run another VM from time to time and every single time I start them I get this "Overcommit Memory?" popup and thought ok I'm overcommiting here already and...

I want to start playing around with docker but was unsure if this was going to put to much of a load on the system. I've install rancher and it wants 2G straight off the bat without even installing anything so this is the reason I asked about the 1T=1G rule.

So looking at this now, I can pretty much give rancher a crack without to much worry. While the data stored on this box isn't mission critical I'd like the keep it if possible.

Thanks for the help!
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
I think your situation is best resolved as "Go ahead and try it. If the VM causes it to suck, drop the VM or deal with the suck." Don't create ungodly large VM's or jails is probably the only relevant warning.
 

Spud

Contributor
Joined
Oct 23, 2011
Messages
117
I think your situation is best resolved as "Go ahead and try it. If the VM causes it to suck, drop the VM or deal with the suck." Don't create ungodly large VM's or jails is probably the only relevant warning.

Push it and see what happens in other words, thanks again for the help!
 
Top