FM 7 Server Slow and Unstable?

[smower]

Hello,

Is anybody out there using FileMaker Server 7 in a heavily used environment (more than 50 host databases and more than 30 users)? Has anybody ever seen it perform very slowly or crash?

We installed FileMaker server 7 on Windows 2003 Server 2x 3.2 Ghz Xeon with 5 GB of RAM. This box is dedicated to FileMaker server. We have about 94 hosted databases and an average of about 80 users on the host at one time. We tried to clean up our databases prior to converting to version seven and did additional cleanup to the databases after conversion. We also have the ODBC plug-in from server seven advanced installed although we have not made in the ODBC connections at this time were during our testing. Anyway we noticed that the performance was about five to 10 times slower than version 5.5 server even though we have almost three times the horsepower in the hardware. Our FileMaker 5.5 server is built on Windows 2000 service pack 4 2x P3 1.3 GHZ with 2GB of RAM.

We also noticed that the server crashes the services multiple times per day. When we view the performance tab of the Windows task manager of the server computer the page file usage is almost always at 2.0 - 2.02 GB when it crashes. The problem with the crash is that it doesn't just crash one database but it crashes every single database and causes users to lose data. When it crashes the users can no longer see the databases and we have to reboot the server computer and wait for the databases to load up before they can start working again.

We called technical support multiple times on this and they said to try server 7 v2 can try uninstalling and reinstalling. The computer continued to crash after uninstalling and reinstalling software. We tried reformatting the server and and reinstalling everything and it still crashed. We also tried a completely separate computer and hardware and found that it crashed also. We tried the v2 patch and it definitely lengthened the time before it crashes and provided a speed improvement, but it still crashes also with load. It only takes about 15 computers performing server-based calculations continuously for about 1.5 hours to bring it down. Server seven v1 only takes about 10 minutes to bring it down. To simulate load we set up a script in a database that runs on form layout. This layout has some date calculations in some case statements, a portal to related records in a related database, a container field and record level security in the new FileMaker seven security privileges. The security basically checks the user versus the status of the records to determine whether the user has modification rights, so it evaluates on every record. This database has about 1400 records so we set up a script to loop through the records, which obviously causes a calculation to evaluate access privileges for each record. Server 7 seems to perform these calculations on the server and bring the data back which takes about 10 to 15 seconds per record. The CPU usage on the server shows activity when the script runs which looks like it is doing calculations on the server.

We have also played with several different cache settings in FileMaker server properties. It seems like a higher we set the cache the faster the database performs in the faster crashes. We have set the cache to the bare minimum which makes the server stay alive about four times longer but still crashes and then the performance is terrible. FileMaker tech-support also have us adjust the cache flush interval settings from different intervals between one to 10 minutes. Anyway, we can repeatedly crash it consistently regardless of the settings.

We also tried hosting only three databases the v2 updater instead of 94 in the FileMaker server seven services crashed in about eight hours with 15 computers applying continuous load to it. v1 could crash in about 10 minutes with three databases and 4 computers applying load. I also ran analyzer on the three databases and addressed the issues it found before doing these tests. These databases are were converted from version 5.5 and are about .5 gigabytes in size and have relationships to each other for viewing data in the related files.

Does anybody have any similar experiences with Server 7 or does anybody have any success stories getting it to run stable with heavy load and user base or converted databases?

Thanks in advance,

[gdurniak]

Just a thought ...

We once tried running FM Server 5 on Windows 2003 Server, and it crashed every day, so we went back to Windows 2000 Professional

It would be interesting to see if FM7 Server would work any better under Windows 2000 Professional ( or work at all )

[transpower]

What is your Page File size? For 5 GB RAM, you need a 7.5 GB Page File. Ideally, Windows should be on drive C, FileMaker on drive D, and the Page File on drive E. Also, as I usually recommend, your system will run better with Terminal Server. Finally, have you run the File Maintenance options (compact file and optimize file)?

[The Shadow]

Don't set your cache size over 4 GB. FMS 7 is still a 32-bit app, it cannot address more than 4GB of memory - its a bug if it doesn't stop you from doing that.

[transpower]

Yes, The Shadow is right; I forgot the limit. Direct from Microsoft:

Configuring page files for optimization and recovery

Article ID 197379

Last Review October 14, 2004

Revision : 4.0

This article was previously published under Q197379

SUMMARY

By default, Windows places the page file on the boot partition where the operating system is installed. To determine the size of the pagefile multiply the amount of physical RAM by 1.5 to a maximum of 4095 MB. However, placing the pagefile on the boot partition does not optimize performance because Windows has to perform disk I/O on both the system directory and the pagefile. Therefore, it is recommended that you place the pagefile on a different partition and different physical hard disk drive so that Windows can handle multiple I/O requests more quickly.

However, completely removing the pagefile from the boot partition does not allow Windows to create a crash dump file (Memory.dmp) should a kernel mode STOP error occur. Not having this crash dump file could lead to extended server downtime should the STOP require a debug to be performed.

The optimal solution is to create one pagefile on the boot partition using the default settings and create one pagefile on another less frequently used partition. The best option is to create the second pagefile so that it is on its own partition, with no data or operating system-specific files.

Windows will use the pagefile on the less frequently used partition over the pagefile on the heavily used boot partition. Windows uses an internal algorithm to determine which page file to use for virtual memory management. In the above scenario, the following goals of the page file would be served:

[Steven H. Blackwell]

I will take a further and closer look at this when I have time, but one thing jumps right out at me. Windows Server 2003 in the 32 bit edition is designed IIRC for 4 GB RAM or fewer. Yet your box has 5 GB. I don't know whether this is the cause of your problem or not, but can you remove one of the RAM chips to reduce RAM to 4 GB or less?

[transpower]

Also, in boot.ini, you can set /MAXMEM = .

[smower]

Thank you to all who have responded. Here are some more details based on your questions.

Gregory D.- FileMaker's website said that VeriTest certified FM7 for Windows 2003 Server. We are using Windows 2000 server for 5.5.

Transpower - Our page file size during our testing was set at 3.57 GB. We have now bumped it up to 4.717 GB. We have Windows, FileMaker & Page File on Drive C, but the FileMaker databases are on drive D. We haven't set up the server as a full blown terminal server, but we have remote desktop turned on. We ran the optimize file from file maintenance, but not the compact file since many records still will be added to the database.

Also, regarding RAM settings:

Today 11/1/04, we also used the /PAE switch from Windows so that Large Memory support would be available since it previously only showed 3.5 GB of the RAM available. It now shows most of the RAM available to FileMaker Server and we updated the page file size. We ran the test, a looping script on about 10 computers at the same time and it still crashed once the page file hit 2.05 GB. It ran for about 10 minutes or so before it went down. The pf size in Windows task manager is starting at about 1.76 GB. If we bump our FM server cache size down to 1024 it starts the PF setting about about 865 MB, so services stay up longer since it takes longer to hit the 2 GB, but slows performance.

The Shadow- Our cache size is set to 2048. FM7 only shows that we can go to 3072. The higher we set our cache size in our testing, the higher the PF settings from Windows task manager appear, and the faster the server crashes. We have set cache size as low as 40 which increased the uptime by about 15 hours, but destroyed the performance. Every cache setting we set allows the server to still crash 1 to multiple times per day.

Steven B. - We tried this test on a box with 2 GB of RAM & Win 2003 server and it also crashed when PF settings hit about 2.02 GB.

Thank you again to everyone who has responded

[transpower]

I can suggest one more thing to try: use System Mechanic to configure Windows to write cache every 2 seconds (or at least something really low); so that if the system does crash, you lose very little, if any, data.

Again, I would suggest repartitioning your drive so that the Page File is on a separate partition from Windows and FileMaker. FileMaker (programs and data) should be on a separate partition from Windows, as well.

I do recommend Terminal Server whenever possible--there is much less data flow through your ethernet connections.

[FMDuck]

I think you may be looking in the wrong direction first. Did you clean up file references before or after conversion? I've worked on convertion of a number of solutions up to 150+ files (don't ask - I didn't design it) and seen a significant value in cleaning up file references.

Also, I'm not too skilled on hardware, but aren't you hitting a 2 Gig file size limit in Windows? When you hit this limit in FM you can often expect unrecoverable file damage.

I'm not to keen on typing (that's why I like scripting) so feel free to e-mail me and we can talk on the phone if you think some discussion may help.

[gdurniak]

One more thought ... check your switches

"When using the large amounts of memory made available through PAE X86, the number of PTEs ( Page Table Entries ) needed to track that physical memory can increase dramatically. This can lead to problems when the amount of physical memory allocated to the kernel for storing PTEs is reduced, such as when using the 4GT switch. With 4GT, the smaller amount of virtual memory allocated to the kernel means that the number of PTEs that can be recorded by the memory manager is much smaller"

From: http://www.microsoft.com/resources/docum...3tr_pae_how.asp Info on PAE and Paging File Size

A related post says "If you are an intensive IO system you may see system crashes with this switch"