Check the folder size over at C:/Windows/Temp on your server, you'll likely find your answer.
Usually we try to make sure our servers are running with no more than 70% full disk space. If your C:/ drive is below 5gb of free space, try and do something to clear up drive space.
Performing a maintenance reboot of filemaker server every once in a while is a good idea as it will force the release of cached data, ram allocation and any abandoned processor threads that could have gotten out of control.
You may want to figure out if there is any way to optimize your report so it doesn't take as long, such as a scheduled script that the server runs to cache information for the report, or switching calculated fields to auto-enter values.
Essentially the error is just as it reads. You ran low on disk space, so filemaker needs to carefully clear other things out of the temp cache so it can reallocate it.
2 of 2 people found this helpful
Sorry, I meant check C:/Windows/Temp on your client that is running that report. Assuming you are seeing that error on your client side from filemaker pro as opposed to it running on the server.
It looks like you're trying to cache all that report data realtime on your client side, when in essence you should probably be using Perform Script on Server to build that data on the server side. This will greatly speed up your reports, and not require a large temporary cache on your client side.
This will also put the cache in one location, rather than spread across multiple client VMs and essentially duplicating the same temp data across multiple users.
Yeah we checked the temp folders in AppData and all was ok .. as sometimes they do get big..
And the server was rebooted 2 days ago so I dont think it has anything to do with the server...
I'm thinking of using PSOS to run these reports .. but I will have to test it first to ensure it doesnt slowdown the server and affect other users ???
Just seen your second post .. Yeah I will go with the PSOS i think....
If optimized correctly, it should greatly improve the performance of your database for all users, enough that you wouldn’t notice any hit during day to day operations.
Jonn Howell had a pretty good session at devcon last year that may be a good watch for you:
Brilliant, thanks Mike
I will watch this for sure
3 of 3 people found this helpful
I'll repeat the usual warning here: PSoS works well but it changes the deployment game a bit potentially. Your FMS box has to be absolutely up to the task or you will introduce more performance problems instead of solving them. Your FMS now becomes an application server with potentially many simultaneous virtual user session each taking their own slice of processing power, memory and disk i/o. Over and beyond what it requires for its db engine tasks.
That's one small beef I have with Jonn Howell's presentation: it offers one solution (queuing) but doesn't mentioning solving the issue at its root: making sure the server deployment is up to the task.
1 of 1 people found this helpful
Agreed, which leads me to another good blog post covering how filemaker server performs and allocates resources:
This is the highest level performance documentation I've seen (so much that I have it bookmarked). It is a top to bottom guide about getting FMS to perform at its best.
You didn't specify explicitly, but are the ~80 xenapp users on the same server (hardware) that is running FMS?
How many of those 80 users are running these reports simultaneously? How many times per day?
While freeing up disk space for the xenapp users is a short-term fix to the error at hand, the switch to PSoS in your case (as wim noted) can greatly increase the demand on those FM server processes. This is entirely dependent on load. But you will notice FMS recommends no more than 25 simultaneous script "sessions" be running on FileMaker server at a time.
Earlier I mentioned that caching report data and updating it via a server scheduled script may be an option as well. This would alleviate demand from the PSoS operations, consolidating it to a single script session that is updating and re-caching report data. Just something to think about.
The Database (7.5gb) run on a single VM instance with FMServer 14.
The 80 users are running off 6 XenApp servers. FMPro14
And to be fair these large reports are run only a few times per month by only a few (3 or 4) different users, so Im hoping it wont be an issue..
Just to note .. I have incremental backups running (set to 30 mins) ..