Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 3636 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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

post-85495-0-26069600-1416423426_thumb.p

Posted

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.

Posted

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

Posted

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.

Posted

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.

Posted

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.

  • 2 weeks later...
Posted

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

Posted

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

This topic is 3636 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.