Memory capacity on server is definitely an issue, and I now suspect it is the primary, if not the sole cause, of freezes and app crashes. However, I'm still curious why a good bulk of my solution runs fine but I can identify repeat issues with a specific database and script routine. Does that jive in some way with server memory if it's a particularly greedy script process?
The server is not going to make the clients crash. Do some performance monitoring on the server (include the FMS counters) to build a decent baseline of how stressed the server is during a 24h period of time.
Thanks. I'll be looking at the FMS countes but in the OS, I can already see the mem usage is at 98/97% consistently during peak usage hours.
If we presume server response is the cause of delays and what appear to be freezes, I agree, client crashes could be isolated to some specific script. As usual, difficult to separate the two issues at the moment. I'm still curious about the crashes especially as I haven't seen FM client just crap out and fail, no matter what I threw at it, in versions 7-11. This is like stepping back 8 years.
Any insights welcome on what could cause 12 Pro to fail outright, or ways to monitor what's happening when application force closes on it's on. Windows logging seems useless.
Some current stats:
Cache hit is at 100%, Unsaved at 0, so that looks OK.
Elapsed time avg is 4314, peak at 15.5 mil.
I/O time avg 2330, peak also at 15.5 mil
Wait time avh 825, peak at 991k.
From what I know, those averages are way over where I want them and peaks are off the chart. (Not sure how to understand avg in 4 digits when peak is 15 million. Even if that's a one time peak on all, I'm assuming avg is grading on a curve somehow, ignoring peak highs and lows.
You may wan to see if you can use the new Execute SQL functions to streamline your process some and not make it so intensive sounds like you have a lot going on in that one scripted process and you may be able to find a more efficent way to do things. I hear 12 can be faster than 11 once you rewrite things to take advantage of some it's new features. I haven't made the switch for any my customers yet and at this point plan on waiting until the next release. Good luck!
That's what I'm thinking. I will probably need to rewrite this whole process. I needed to anyway, but it still just immediately crashes one of the clients, so I need to scramble and convert.
A lot of the more recent development I've done is indeed working pretty smooth in 12, but it does seem like 12 is not very forgiving for old, legacy things that worked fine in 11. Great for fresh starts, but challenging for migrating aged and complex solutions like mine. Any advantage you see to waiting for 13 or just not bothering with 12 for now?
You are right 12 is not very kind to migrating older complex solutions which all of mine are which is why I have waited. For me I am skipping 12 I see no advantage to moving to it at this time and the layout tools are very difficult to use. Unless there is a compelling reason to move to 12 I do think you are better off waiting. If you want to discuss this more I can be reached at 707.927.4620.
Thanks, Mark! I'm all in on 12 at the moment, I did as much pre-launch QA as I could, but there are some elements that do not get full-on load testing till you launch. So I am a few days in with live data in operation. I believe my issues are all resolvablem just have to prioritize and fasttrack some rewrites.
Well then might as well stay there I suppose. I do think Execute SQL could really help you since it can reduce the need for relationships and simplify your graph so that is probably the best place to start. For me none of my customer really wanted to pay me to do any QA testing unless there was going to be some big benefit for them in 12 which I just didn't see but I am hopeful there will be features in the new version my customers will want. Good luck with things!
There is a known bug in 12 which has a high crash rate: scripted creation/opening of a new window.
This has been found to happen frequently in both converted and rewritten scripts which rely on a New Window process within the script. FMI was notified of this problem prior to the public release of the software, but no specific bug-fix has been noted to my knowledge.
If you can go through the script(s) which are causing this problem and eliminate or minimize script steps which open new windows, that may resolve most of your crash issues.
The known New Window bug usually freezes the FMP application, with a force-quit required to clear the problem (so you don't want to run into this on a local unserved file where the file itself is then crashed without proper closing).
Thanks, I'm in-house so less pressure with contracting for QA but at same time, looking to keep the time ROI under control and hope to take advantage of the SQL and other new features. I'm in process of long project to convert a lot of old legacy stuff so it seemed good to do most of this on 12.
Thanks a lot, that will really help and I suspected there was something pretty specific. That seems like it would be pretty pervasive issue; I'm surprised they haven't addressed it already in update releases or at least published some guidelines for handling or routing around needs for new windows.