Also note that there were some other IT changes at the same time, new networking equipment went in, another server was replaced. But I have checked that there are no IP conflicts and the DHCP server is configured fine.
Also if a client force quits and re-opens then it opens fine, but I'm not sure if that is because the lag time has passed anyway.
Also note that I was working remotely, and I'm not sure 100% that the FM13 update did this. There were reports of something like this happening on FM Server 11 but not sure.
More information. I am here on-site. It happens a few times a day. I noticed that everyone froze up on the server at once, no server scheduled scripts are running, and even the local instance of Filemaker on the server froze up!!!!
Have you ever tried reverting the changes and maybe apply a lower version to your server? As I see it there is a compatibility issues there.
Unfortunately downgrading the solution isn't an option as there is no way to convert an FM13 file back into FM11 that I know. And there is tooooo much data to program up an export/import via something like csv files. What could the application be possibly doing to freeze everyone?? Server on <30% CPU utilisation, clients all on 100%. I'll watch the server CPU closer next time because it should be more like zero CPU if it's doing nothing.
So, the server has _not_ 100% cpu load when thus happens?
IS there anything in the log's of the server?
CAn You monitor the network when it happens? What switches? Cisco?
I have this with FM 11 Server, on a Mac Network. Periodic Beachballs. We need a Beachball log, to see what the machines are looking for. The whole office will lock up
The fact that you can force quit, then open normally, is also odd
Check any scripts that run on open, and check all the External References
It would also pay to run a Recover on the file, and check the Log for any "problems"
> The network tests fine, accessing the file locally has the same issue so it shouldn't be a problem with the network
> if a client force quits and re-opens then it opens fine
It sounds suspiciously like cache refreshes - all clients periodically pause. You said the database file was "huge". How huge is "huge"? Does "well optimized" mean no more than, say, 30 or so fields per table? How many records per table?
Cache refreshes occur "at idle", when something changes. It might be that, if the file size gets large enough, the clients might not have enough free RAM to hold the cached data and they're paging to virtual RAM (disk), which is what's slowing them down. Restarting the file cleans out the cache and they're okay until they get full again.
Maybe check free RAM and see what else is running on the clients?
It's not so much optimizing the Tables, but optimizing what is shown
e.g. If you try to open with Summary Fields on a form and all records found, it will lock up
> Does "well optimized" mean no more than, say, 30 or so fields per table? How many records per table?
I was actually asking the OP what he meant by "well optimized". And, since he mentioned that the "pause" behavior happens when nothing is happening (i.e., no user actions) - not when the file is being opened - I'm not certain summaries or other aggregates are the problem.
OTOH, if the database has been optimized at the schema level to minimize record payload, then record caching will be minimized and the caching burden reduced.
I did think of one other possibility. What is the backup schedule on the server? Do the pauses coincide with a backup being run? It doesn't exactly fit the symptoms (running a backup shouldn't cause clients to go to 100% CPU usage), but it may cause a "pause" behavior on the clients if the database is unusually large.
Open a copy of the file locally and see if it is stll slow. Open each layout and close it and test again.
Make sure that the statistics logging is turned on so that you can review that and look for all vitals during times that it happens.
Don't look at the CPU usage on the OS alone, looks specifically at the "elapsed time/call" and "wait time/call" FMS stats.
I would really like to see this explained, at DevCon
Not sure how FileMaker does it, but FileMaker 5 worked fine, with only a few Mb of Cache
It also seems that since Cache is set in Preferences, any paging could be controlled
> the clients might not have enough free RAM to hold the cached data and they're paging to virtual RAM (disk)
We'been moving a FM11 solution to FM13 - and had some troubles, but these troubles were network related. FM13 runs very well here - but needs a 'good' network, whatever this means. We've had Cisco switches that caused problems. After replacing them by cheap netgear, the solution was fine under FM13... maybe there were just firmware updates missing for the Cisco, but the sysman replaced them