Has anyone been using 2025 (22.0.2) server in production? Are there known issues? How stable is it? I’ve got some pesky issues in 21 and am wondering if 22 will make it all better.
Related, if I upgrade and have issues, can I revert back, or will my database have trouble going back?
We’re watching issues that are occurring for clients who have moved up to v22. We’re having trouble determining the reason. We cannot confirm that it is FMS v22 that is at fault. At the moment it is just a coincidence but we have a lot of clients on FMS v21 who are not seeing the same issues.
We’re getting a lot of assistance from Claris. They’ve been engaged since we reported it.
We don’t have any specifics. The general symptom is “server is slow!” Our best advice at present is to reboot server every couple of days as the problems are not evident until the machines have been running for a few days. While we know that there are some things that seem to be triggers we haven’t found a cause. And most of our clients aren’t experiencing problems at all.
Today we set up a server for Claris engineers to play with. They’re going to set up some test harnesses and do some stress tests. Hopefully they’ll see something that we can’t.
We’ve upgraded our Windows development server and haven’t noticed any issues but this doesn't have many users and is not representative.
We’re currently avoiding FM Pro v22 due to the revised installation procedures and the problems this is causing with testing and external authentication, particularly with Remote Desktop installations.
Would be interesting to know if any of the persistent cache settings are being used.
Also, are there high values (>100, roughly) for the ‘I/O Time/call’ values in Stats.log?
Or any relationship to slowness (eg, high Elapsed or I/O times in Stats.log) and high disk response times under Windows’ Resource Monitor?
While monitoring some performance issues of our own, I’ve been wondering how much of FMS’ disk activity is represented in the Stats.log under its Disk Read & Write metrics. In particular, the access to FMS’ temp files,which on Windows would be at C:\Windows\Temp. The access there can sometimes be significant if (for instance) large numbers of records are created or modified. In our case, using faster disk for Temp led to a fairly significant improvement, reducing the frequency of high I/O delays at the OS level, although I wouldn’t go as far to say a magic bullet. The infrastructure provider in this case couldn’t get us enough faster disk yet to cover the live database files though, so moving /tmp was the best we could do.
Above is on FMS 21.1.5 after the system was migrated from 20.x and to a different VM platform, on Ubuntu, and using both Persistent Cache options. So your YMMV.
Upshot is, I’d definitely like to get a better understanding of how and when FMS is using various file system locations (/tmp, live files, progressives, etc.), and also how the Persistent Cache settings might affect that, so would be interested what changes you end up making to hopefully resolve the issue.
These are good questions. They may already have been asked and answered - I'll check.
I’ve Checked.
Persistent cache settings are not considered to be part of the problems that we are seeing. Only the server process is having issues, other processes are ok.