1 of 1 people found this helpful
Those numbers don't look too bad. How much RAM is assigned to the virtual instance and how high did you set the cache?
The freezing is something else.. do you get errors are warnings in the Windows system/application event logs? Any DMP files in the FMS logs folder? How many processors are assgined to the instance? How much disk space and how much of that is free? What kind of disk i/o system are you running?
When the freezing happens, do you have perfmon on? If so can you see a build-up on any of the resources (cpu, memory, network, disk) that is consistent across the freeze events?
FMS12 is a very different beast under the hood than FMS11 so comparing resource usage is pretty useless. Do you have progressive backups turned on?
1 of 1 people found this helpful
Have you moved to a 64 bit OS? We found FMS 12 on 64 bit to use about twice the resouces of 32 bit FMS on the same hardware. And this was with no database loaded. This isn't just an architecture thing, it should in theory, be able to to use roughly the same, but just what we found.
If you're able to, switch back to a 32 bit OS to try it out.
Yes, we are using a 64-bit OS to take advantage of the 64-bit core processes of FMS12. That is one of the only differences between our FMS11 and FMS12 setups, although I don't think it would be acceptable to switch back, as we've promoted 12 for it's speed enhancements realized by the 64-bit architecture.
It might be good for testing purposes though.
The instance is allotted:
Processors: quad core xeon @ 2.5ghz,
Memory: 6gb ram.
FMS cache: 1,024mb
HDD space: using 36.4gb free out of 43.9 on our production data drive. 46gb free of 51.9gb on our backup drive, and 1.63gb free of 23.8gb on our system drive. Our production and backup data is in a cloud-based SAN, the system drive is local to the machine.
Backups are set to run once per evening (not progressive), and our databanks (the majority of our HDD "size") only backup once per week since the data does not change much. So there's very little overhead in our backups, only ~1-1.5gb backed up in the middle of the night each night.
Unfortunately our notification of the lockup is after the issue happens, and we have to force reboot, no RDP access at all, so we didn't have perfmon or anything else running. There are no current DMP files (the two files there have modstamps from back in July 2012).
My event.log file for filemaker does show this a few hours before the crash:
2012-12-29 07:33:07.649 -0800 Warning 86 FM12 Server Database or temporary file "filewin:/C:/Windows/Temp/FMTEMPFM2692_1.tmp" low disk space, only 253976 KB free! Searched temporary files and freed 43368 KB.
The event log for WinServ2008 shows a similar warning (The C: disk is at or near capacity. You may need to delete some files.) at the same time. It also shows an error I am not sure about:
"The event logging service encountered an error (res=1500) while initializing logging resources for channel Microsoft-Windows-Kernel-EventTracing/Admin." Right before the freeze.
I'm thinking possibly we're overloading our temp file allocation, because it's using the system drive and not our production or backup drives. I think it uses temp files during backup as well? I'm looking into a schedule to clear temporary files now.
After troubleshooting further thanks to Wim's suggestions. We've figured out that our problem is filling up our system drive with temporary files, which is causing the system to freeze.
We've set up a maintenance schedule to reboot and clear temp files, but is there any way to clear FMS12 temp files without requiring shutting down the service?
is there any way to clear FMS12 temp files without requiring shutting down the service?
You may be able to do it by just closing the files (which you can automate through the fmsadmin CLI) but I'm not sure if FMS will release the temp files based on that. You do not need to stop the service though, using the CLI you can just stop the database server and leave the helper service running.
We had the same freeze on a Windows box, that had a very small "system" drive. We simply re-directed the Windows "Temp" folder to a larger drive.
> We've figured out that our problem is filling up our system drive with temporary files, which is causing the system to freeze. We've set up a maintenance schedule to reboot and clear temp file