Late 2013mac pro 12 core 2.7gHz

 

OS = 10.9.5

 

FMS = 13.0v4

 

Attached graphic shows elapsed wait time on the same piece of hardware and databases with similar number of clients doing simliar day to day work.

 

Day 1 with 64 gig of RAM ( half to FMS ), and Day 2 with 16 gig of RAM ( half to fms ) 

 

All performance metrics look to have improved with less memory. This of course defies my logic. 

 

Does anyone have any insights?

 

Thank you,

Drew

Yes, that can happen.

 

That was true with previous versions of FMS as well although the penalty was not as big.  Over time the best practice with FMS had become to set the cache to the max, when the max was 800MB.  Now the potential max is much higher and there is a definite point of diminishing returns, to the point of negative impact.

 

However interpret those stats very carefully.  Two days is not a relevant time-frame.  Collect the stats log over a longer period of time and start with the cache set low, say back to 800MB and check a few times per day over the first few days to see if the cache hit % remains close to 100%.

 

I don't think that there is a FMS stat for "elapsed wait time", there is one for "wait time per call" and "elapsed time per call", both have to do with processor activity, not so much memory.  If the user activity on day two was slightly less intensive in nature than on day 1 then the processors would be taxed less and you'd see the results you are seeing.

So do the monitoring over a prolonged period to really nail it down.

Thank you for the reply Wim!

 

The stat was actually elapsed time per call. 

 

What other stats besides the cache hit % is memory related? I ask about memory mainly because it is really the only thing in my control besides a different box. 

 

In general I am seeing much worse performance than when I was running....

10.8.5

FMS 13.0v4

Mac Pro Duel 4 core @ 2.93

12 gb ram ( half to fms ).

Drive was on a PCI Express SSD ( http://eshop.macsales.com/shop/SSD/PCIe/OWC/Mercury_Accelsior/RAID)

 

Having more ram, and more cores, I am surprised by all this.

 

Thanks again for your well respected insight!

Drew

800mb cache saw much better performance yesterday… i don't get it!

Well, FMS has to expend resources keeping track of the cache - inspect it for changes etc. The higher you set it to more resources it needs.  And those are wasted if the cache is not being used.  So you are not increasing performance with a higher cache beyond the point that is needed, you're decreasing performance.

So would you decrease the cache size until the logs show less than 100% and then nudge it up just above that level?

Yes, that has always been the best practice.  You don't want to set it too low obviously so leave yourself some margin and monitor the stats log for a few weeks after making the change.

Doesn't it also relate to how big your files are?

ie. Having 6GB cache for a 300MB database doesn't seem too helpful to me.

Doesn't it also relate to how big your files are?

 

 

Of course, but also the activity of the users in that file.  That's why you can rely on the FMS stats to help guide you.

Doesn't it also relate to how big your files are?

ie. Having 6GB cache for a 300MB database doesn't seem too helpful to me.

True, but your size assumption is off. All combined, I'm over 20gb

Moved the server back to older hardware with OS on RAID 10 SSD, and database files on this http://eshop.macsales.com/shop/SSD/PCIe/OWC/Mercury_Accelsior/RAID) with same server settings getting much better performance. Seems to me the drive situation in the 2013 MacPro was the limiting factor.

The hard drive subsystem is the single most critical factor in server configuration.  The FileMaker, Inc. SE's (now rebranded as Consulting Engineers) identified this multiple versions ago in their excellent White Paper.  Quality and durability and resilience of the drives are the governing factor.

 

Thanks, Drew, for updating us on this situation.

 

Steven