Several things come to mind to check:
- Do you have any scheduled FMServer backups running which might coincide with that overload? If yes, is verification running on backups?
- Is this MacMini used exclusively as FMServer, with no other software open on it? No Mail retrieval schedule, etc...
- Any users with remote access to the FM Server machine for any file-sharing or software use?
- Any non-FMServer backup software?
- Any auto-settings for checking system software updates?
- Any non-FMServer operations on that machine which could be turned off as non-essential to FMServer.
Sounds like scheduled backup to me
- The FM developer and I connect remotley to administer the server.
- No file sharing.
- No third party backups.
- Indexing turned off.
- No mail service or print services.
- We have turnd off all non-esential services
1 of 1 people found this helpful
I have suffered from a similar issue many years ago, but I can see that this does not fit with your comment that FMS 12 did not exhibit the same problem.
However, my first approach would be to recover all files and test the new files on the same server - to see if the same issue shows up again.
This may be difficult to achieve, but it would confirm if the problem is file-based or server-based.
You can then check the Recovery logs for any clue as to what the Recover procedure decided it needed to fix.
In my case, the problem stemmed from a corrupted index that caused the server to hang for about 4 minutes whenever any user selected the layout on which it was used - it was driving a portal on that layout.
In the end I had worked out which layout was involved and then I slowly increased the size of the Database window on that layout from the smallest size until FileMaker found it had to get data using the relationship which triggered the corrupt index. I remember that this took a few weeks to track down.
Of course your situation may be different, but I hope that these notes may help.
Best wishes - Alan Stirling. London UK.
So do you have FM Server performing scheduled backups of the databases, and are the backups including file verification?
Any chance there are energy-saving settings on your MacMini which may be kicking in at times? I found that a full reboot was necessary on one Mini after turning off all energy-saver prefs before the old settings quit causing the disk to go to sleep periodically.
Yes there are FMServer backups with some of them with verification. The backups do not coiencide with the cpu surge. I does not appear to be the backups.
We replaced the Mac Mini temporally with an old MacBook running FMS 13 and run test. It is a little slower response but no runaway CPU problems during a couple of hours of testing. We will see what happens during tomorrows work day. If it is stable I will format HD and do a fresh install of OS 10.9.2. on the MacMini.
I hope to make it until Apple releases a new Mac Mini and we can upgrade.
Be sure to check the energy preferences on the server, not just on MacMinis, but especially on any laptop converted to use as a server, and reboot after turning off any sleep-like options.
(I have a MacBook Air used for a test-FMServer on which it's almost impossible to get it to run plugged-in without kicking into sleep mode at some point. It's OK for testing but would definitely cause connection failures if used in live multi-client service.)
One thing we ran into early on with our mini server is that we couldn't run OS X Server (10.9) on a mini and FMS 13. This was at the time a known issue and I don't know that it was ever resolved. One of the issues we had with it was not being able to launch the new Admin Console. We ended up reformatting the mini drive, installing FMS *only* on the mini (skipping OS X Server completely), and it's been fine ever since.
You might check as well that Time Machine isn't also running on the mini, and that the OS isn't set to put the HD to sleep, Power Nap is turned off, and set to Prevent the computer from falling asleep (these are all in System Preferences under Energy Saver).