Does resetting a windows server running FileMaker Server (weekly, monthly, whatever) result in a more stable server?
2 Likes
In the past I recall needing to reboot Windows servers all the time and this made me wonder just how long it has been since I last rebooted our FileMaker server. It has been 185 days. I am not exactly sure when this changed but I feel it has been many years since I felt windows server was not very reliable. This is part of the reason I decided to ditch my Linux server this year.
We host 41 databases ranging from tiny and almost never used to large over 40GB databases used daily by 8 employees. We currently still have FileMaker server 18 installed 19 will be installed soon.
Windows server 2019 standard
Intel Ceon E5-1410 V2 2.8GHz
32GB RAM
The server this replaced was older and not fit for the job I seem to recall having to reboot it now and then but even then it was not that often.
I will note that I do not think waiting 185 days with out a windows update is a good idea and will be updating tonight.
1 Like
Claris itself tries to restart the cloud server daily.
(if nobody is logged in)
But restarting every month to get some system update installed may also work fine.
There may be no real need to restart except maybe to clear leaked memory.
1 Like
We are currently running 18 Windows cloud VMs and support onsite Windows servers.
It is essential that you run the latest Microsoft patches on a monthly basis for security purposes. Usually, these require a reboot to complete installation. We always manually close all hosted FileMaker files before restarting.
Restarting any computer will always reset caches, memory, etc. Also, some of the older versions of FileMaker Server needed resetting, for instance v14 had a problem where calculations wouldn’t update until the FileMaker Service was restarted and various versions have many problems with the FileMaker Server Script Engine (FMSE). We’ve about to upgrade a v16 server to a v19 and hope this will improve, as the FMSE restart is a weekly issue and we have to run a robot to monitor and inform us if this happens.
Regards
Andy
1 Like
The goal here is to maximize uptime and that comes only from proper monitoring so that you'll know exactly what is going on with your servers, with plenty of proactive warning so that you'll know when it is time to reboot the server.
Most FM deployments don't bother with monitoring and just opt to blunt-force reboot once in a while as a substitute. Most of those reboots are not needed.
1 Like
As in 'a filemaker client'? What is it that you are tracking that you couldn't get from regular monitoring or monitoring through something like Zabbix?
1 Like
Hi Wim
The server is a W2012 server and has been in service for over 7 years, so Zabbix wasn’t on our agenda then. Also, we didn’t start having problems until FMS v16, which caused all sorts of background and user related issues (the famous ‘Finding....’ issue only arose with v16 for us).
To be honest, the robot has worked really well and we’re just starting a W2019 Server VM build that will run FMS v19 and take over from the old server (it has taken us this long to complete the changes needed as a result of the MDI/SDI impact of moving beyond FMP15, hence upgrading earlier wasn’t an option. - this is an SBA server, hence shared hosting. We’ll take a different approach on that.
The FMSE issue is totally random, it can be in the middle of the morning under maximum load, during evenings when backups are taking place or on a Sunday afternoon when very few people are accessing it. We’re keeping our fingers crossed for FMS v19 and take it from there.
Regards
Andy
1 Like
I appreciate everyone's replies. Also I'll have to start learning what little I know from scratch when we switch over to Linux.
There seem to be 3 times to proactively restart a FileMaker Server
- On a schedule
- based on monitoring data
- To install updates
- It is interesting that Claris has configured the cloud server to restart daily (unless there are user connections).
This would indicate that the people who wrote the software think/know that there are reasons to restart.
I would imagine that enough of the code across the various FileMaker Server platforms is the same, to consider that configuration decision as implicit advice.
- Monitoring using Zabbix is a great value add, providing the ability to react to real data and actual conditions on a FileMaker Server.
There are a great number of data points that Zabbix can monitor, both on the FileMaker side and the operating system side. That said, there might be other items that Zabbix can NOT pick up such that an automated nightly restart during downtime adds additional value.
Perhaps doing both is best practice?
No, think deployment - not software development. It's the people that do the DevOps, not the people that write FMS... given that they do the patching of the server and they are probably very aggressive with keeping up with small security patches on the Linux side. Plus whatever else they want to patch based on all the monitoring they do.
@tonywhitelive Do you think Claris is restarting the box or simply the service?
Also, even if I agree the FMS codebase must be pretty similar across the different OSes, it would seem to me that choosing to restart a server and the elements motivating such a decision can have a great deal to do with the actual OS (or even hardware) and maybe not so much to do with the software running on that apparatus (even if I am certain there can be some good reasons stemming from that too).
I like your observation and it is quite interesting. I guess I would like to know more about why Claris opted to implement daily restarts.
Curious to see how it will influence others.
There's a good analogy with airplanes here. Obviously the number of flying hours count when it comes to maintenance but the number of take-offs and landings count for just as much if not more because that's where extra strain is put on the hardware.
The overarching best practice is: if it ain't broken, don't touch it.
Question is: when do you know whether it is broken, even just a little tiny bit?... answer is monitoring.
1 Like
Just adding to this thought. It's that monitoring data that will often lead to finding the cause of the problem that requires a restart. If you solve that problem, then the need for a restart can be reduced or eliminated. Thus removing some of the strain on the server hardware.