FMP clients get disconnected from FMS server

[GPBdev]

Hello,

I have a problem with FMP clients that get disconnected from FMS server.

There are 7 clients running FMP 8.5 on Intel iMac's (OS X 10.4.9, 2.16 GHz, 1GB RAM) that get disconnected from the FMS (OS X Server 10.4.9, Intel XServe, 2 GHz, 1GB RAM) at random times during the day. Sometimes everyone gets disconnected at the same time. We have looked at several possible problem area's.

The XServe is the only Apple server in a Windows network and the main server for a new communications department, running AFP, SMB, FTP access for third parties and Firewall enabled on the server. There are also 6 Mac Pro's (Mac OS X 10.4.9, 2.66 GHz, 3GB RAM) that work directly on the server's AFP sharepoints for DTP and design work.

The ethernet connection of the XServe is 1000 MBit Full Duplex connected to a Cisco 2950 switch. The iMac's and Mac Pro's are connected with 100 MBit Full Duplex on a different Cisco 2950 switch. The switches are interconnected by a fibrechannel uplink.

The XServe was installed by a Mac service provider, so we don't have very much to say about the configuration or changes to the hardware. However, we did manage to persuade them to do the following:

First change we have suggested: The iMac's and Mac Pro's are going to be upgraded to a 1000 Mbit connection. People are working on the server directly, use spotlight searches in folders with 28000 images etc. I know, insane!

Second change: The amount of memory on the XServe is way too low. All memory on the server is always in use, so the memory will be expanded to 4 GB next week.

The iMac's energy saving settings were set to sleep after 15 minutes. This has been changed so that the iMac's never sleep. That obviously solved the problem of users getting disconnected at "random" (random being from the client's point of view).

However, the users are still getting disconnected about two times per week, all at the same time, usually late in the afternoon. The FMS daemon stops responding, the CPU time remains at 0%. I've monitored the list of processes on the XServe as much as I can, but FMS never exceeds more than 2-5% of CPU time, with about 5 clients using the database at a time.

The FMP config is set to never disconnect clients when idle, set to host no more than 10 files (hosting only 2 right now), previous setting was 60, and to allow a maximum of 20 client connections, previous setting 255.

I don't know of any other way to solve this problem.

I must say that the data files do not get corrupted, all the data is intact and no recovery of data files is needed.

The only thing I can think of is that FMS should not run on a server that is also used for AFP, SMB and FTP. We certainly don't do that with our IT infrastructure.

Any thoughts?

[Steven H. Blackwell]

The only thing I can think of is that FMS should not run on a server that is also used for AFP, SMB and FTP. We certainly don't do that with our IT infrastructure.

[color:red]Double bingo. You are so far out of spec with recommended best practices here that I am really surprised you're not having a lot more trouble.

Take a look at the Server Tech Brief found on the FileMaker web site here for more information.

The XServe is the only Apple server in a Windows network

Someone did not do you a favor here. If the rest of the users running FIleMaker Pro are on Windows OS, then why was this server selected? Am I missing something ehre on this?

Steven

[GPBdev]

Hello Steven,

The reason there is just one Apple XServe there is because they just started a new communications department, running entirely on Macs. The XServe was the best choice at the time. We advised them through the whole process of starting the department, as they wanted to manage all their publications in house. However, we are not responsible for the actual implementation of the hard and software. The FMS was added to the XServe a few months later, because they asked us to design a FMP database to replace an old Access database they used to manage their publications.

The IT department there did not want to support the Macs, so they isolated them from the network. The Windows PC's could not access FMS on the XServe. We then advised them to add iMac's to the Mac network, so the account and data managers could use our FMP database hosted by FMS on the XServe.

So I'm now managing FMS on the XServe for them, as there is no one there that knows anything about Macs or FileMaker. The IT department does not even make backups of the data on the XServe at all, so we added a backup schedule to FMS that makes a copy of the database every hour from 08:00 till 20:00. At 21:00 hrs, a separate Mac uploads the backups to our FTP server. That way, we can be sure that no more than one hour of changes gets lost. They report every incident to us, so we know what to expect.

Edited June 28, 2007 by Guest
Added some more bkgnd info

[Genx]

The Windows PC's could not access FMS on the XServe

... umm, hate to tell you this, but that probably just means you hadn't set it up properly, or were trying to access it incorrectly.

[GPBdev]

... umm, hate to tell you this, but that probably just means you hadn't set it up properly, or were trying to access it incorrectly.

If you read my post again, you will know why...

[Steven H. Blackwell]

FileMaker Server should not be run on a server with all these other services, especially the share points' being enabled.

Put it on its own machine or put the other services elsewhere.

I can think of no reason why clients running Windows OS should not have been able to access a correctly FileMaker Server hosted file on the OS X Server machine.

Steven

[Genx]

Okay so the mac's have been sectioned off from the Windows network... those network admin must have been too lazy to read a few manuals. Say, aren't network admin's meant to admin networks rather than just parts of them?

Anywho this:"I must say that the data files do not get corrupted, all the data is intact and no recovery of data files is needed".... Is a very brave statement to make.

If your FileMaker service (or daemon as they seem the called on Mac's) stop's responding while your databases are running and if your clients are disconnected leaving records open, data half committed etc.. your data will be corrupt, and you probably won't notice it until it starts festering on the inside until one day -- oops, and the backups from the last 6 months are useless because they all have that bit of corruption in the file.

Okay, so maybe an over statement - but it does happen. I suggest a) you get everything else off that server except FMS reinstall FMS c) swap your file for a dud clean fp7 and see what happens to the daemon at that time of week..

Then if that works, re-introduce the file. If downtime is a big issue then swap the files around an hour before the magic time. Further see if any scripts are being scheduled on the server, somethings obviously causing it to go off and I doubt it's the system clock rolling over to 3pm on a Tuesday each week that does it.

[GPBdev]

I can think of no reason why clients running Windows OS should not have been able to access a correctly FileMaker Server hosted file on the OS X Server machine.

Unless the Mac network is physically separated from the Windows network, which is the case here. Purely political, as there is no technical reason for doing so.

Thank's for your input anyway!

[GPBdev]

Okay so the mac's have been sectioned off from the Windows network... those network admin must have been too lazy to read a few manuals. Say, aren't network admin's meant to admin networks rather than just parts of them?

It's a political thing. There is no techincal reason to keep the subnets separated.

Anywho this:"I must say that the data files do not get corrupted, all the data is intact and no recovery of data files is needed".... Is a very brave statement to make.

Well, this has been my experience so far. Let's see what will happen in the next couple of weeks.

If your FileMaker service (or daemon as they seem the called on Mac's) stop's responding while your databases are running and if your clients are disconnected leaving records open, data half committed etc.. your data will be corrupt, and you probably won't notice it until it starts festering on the inside until one day -- oops, and the backups from the last 6 months are useless because they all have that bit of corruption in the file.

Process, deamon, service. It's all basically the same. Anyway, the database has been configured to save changes automatically and the best part of the 90 scripts that are in the database have been written in such a way that it's very unlikely more than one record would be lost entirely. Most of the data has been imported from an Access database, so it's mainly changes to existing data. There were a couple of empty rows in the main table, but they are automatically filtered out when I make a new version. I'm working on revision 133 right now and the data is checked with every new version.

I'm going to suggest they get a separate XServe for FMS.