Need to delay startup of Filemaker Server

[Bob bader]

I am trying to get filemaker to load databases from an external volume. I have an alternate location setup for the filemaker databases, but, when I boot the machine, Filemaker loads the databases in the default location, but not in the alternative location. However if I stop the database server and the start it, everything loads. I suspect filemaker may be launching before the external driver gets mounted at boot. I would like to delay the launch of filemaker on boot. I called tech support and they did not have any ideas on how to do this. Filemaker tech support did give me the command line start/stop. But I don't want to have the server boot, start filemaker, then have my command stop it, wait a minute and start it again.

Thanks

Bob

[Steven H. Blackwell]

This is a particularly bad configuration. What happens if the "external drive" drops off the LAA/WAN. That will be an almost sure guarantee of file damage. Keep the databases on a partition or a separate physical drive on the server CPU itself.

Steven

[Bob bader]

The external volume is actually an XSAN volume mounted via fibre channel with redundant paths. Since it is fibre channel volume, thats why I think it takes a little bit longer to load.

[Rich Willis]

I agree with Mr. Blackwell that his is an awkward and potentially dangerous configuration at best, but if you are constrained to use this configuration, I recommend either running an applescript with a timer delay to launch FMS on login, or if your server is started automatically each day, you can have iCal run an applescript with or without a delay to launch FMS, at a specific time.

[Bob bader]

Thanks for the info, running the databases from redundant path, xsan (raided ) volume should give me more protection from an internal drive, and Xsan can give me some easy fail-over options. I am running this on OS x server so when the machine boots, it does not login as a user, nor do I want it to for security reasons.

Bob

[genevieve charbon]

You could set FMS to NOT run when powering up, and then launch it through some applescript after this AppleScript mounted the volume OK.

But like the other said your idea is basically useless. And so is RAID for databases. Databases are small (yes mine weights 1.3Gb but that's small) and the performance is not throughput bound (like you would gain with RAID) but latency bound. RAID (even RAID 0) creates latency. So RAID is BAD for database.

Plus RAID, is NOT about security. It's there to overcome the higher probability of a drive failure. BACKUP is there for security.

You'd be much more well served with a non raid set-up (speediest) and with a backup set every 15 minutes to another drive.

If you're concerned about speed : GO SSD

But I've yet to prouve that FMP is so much drive I/O bound and would benefits from it. I've made several tests using RAM disk which showed no improvements at all, except taht backups (from the ram disk to a HD) were much faster

as for server perfrmance THE bottleneck is network latency, but there's practically nothing that can be done for it

[Dave Graham]

Thanks for the info, running the databases from redundant path, xsan (raided ) volume should give me more protection from an internal drive, and Xsan can give me some easy fail-over options. I am running this on OS x server so when the machine boots, it does not login as a user, nor do I want it to for security reasons.

I'd be interested in your feedback about Xsan performance. An Apple Systems Engineer that I spoke with said that Xsans were notoriously poor for small reads/writes, which is precisely the type of traffic you'd commonly see in most FileMaker installations.

Back to the problem at hand. Since you aren't expecting a user to login, you'll have to implement either a launchd daemon or old style StartupItem. I'd write a shell script with a single command:

fmsadmin OPEN

I'd look into writing a LaunchDaemon which includes something like a StartOnMount or WatchPaths key. When the file system or watched path becomes available it will trigger your shell script and call the open command.

From the terminal you can type "man launchd.plist" for the various options. You might consider duplicating an existing plist file and modifying it to suite your needs.

Heck, you might even be able to get away with adding a WatchPath key to FileMaker's com.filemaker.fms.plist. Keep in mind that tinkering around at this level carries risks and if you don't know what you are doing you should consider hiring a consultant or finding another alternative. You've been warned! :-)

[genevieve charbon]

An Apple Systems Engineer that I spoke with said that Xsans were notoriously poor for small reads/writes, which is precisely the type of traffic you'd commonly see in most FileMaker installations.

as I said, ALL RAID sucks for small reads/writes, because all RAID have to access the chunks of data on many drives, each of which have to access the chunk, so adding access time. Plus, the RAID has to reconstruct the file.

Nothing beats a single fast drive, and nothing beats RAM Disk or SSD (SLC SSD)

But as I've no evidence that hardware gives you performances with FMS, in fact I've experienced very low gains throgh high end Hardware versus normal one.

Edited January 16, 2009 by Guest

[Dave Graham]

I could've sworn I posted a reply on this, but I don't see it so here goes again.

as I said, ALL RAID sucks for small reads/writes, because all RAID have to access the chunks of data on many drives, each of which have to access the chunk, so adding access time. Plus, the RAID has to reconstruct the file.

Nothing beats a single fast drive, and nothing beats RAM Disk or SSD (SLC SSD)

Genevieve: The single largest bottleneck in an I/O operation is the physical disk access. A RAID array can spread I/O operations across many disks simultaneously thereby providing a massive speed increase depending on your RAID type. Although RAIDs are far better at sequential vs. random access, a good RAID is still far better than a single disk.

A RAM disk is fast but it's volatile and would shouldn't be considered a reliable medium for hosting a database. Regardless, a decent RAID should still outperform a RAM disk.

SSDs offer significant improvements in seek times, and can certainly provide better performance for some operations, but it's not a clear overall winner against a good RAID. If you have performance statistics to the contrary I'm all ears. Anyone tried a RAID of SSDs?

But as I've no evidence that hardware gives you performances with FMS, in fact I've experienced very low gains throgh high end Hardware versus normal one.

This has been exactly the opposite of my experience. It's been a few years since I did specific FileMaker benchmarks on RAID vs. single disk performance, and I wish I held on to the results. A good RAID will provide a fairly substantial performance boost to FileMaker Server as well as redundancy.

[genevieve charbon]

I disagree, your points are valid if we're looking at throughputs MB/s where RAID is better because it adds the speed of each drives.

Here we're looking at I/O per seconds.

So A SSD raid would defeat the point of SSD which is random access time.

If your raid involves mutiples drives, you're just at best equal the speed of one drive in access speed.

Plus the RAID as to reconstruct the data on the fly because it scatered it accroos multiple drives.

Here we're looking at the time to fetch and get ONE particular bit of file not many bits of files. FMP is mostly sequential.

As for FMP SERVER performances. I've never saw the CPU get past 30% utilisation (and with ram disk plus all database in cache). That's for a 5 people access.

with one running some hevay script.

The botteleneck is the network speed, and more precisely the network I/O per seconds not throughput (which we can't do anything about, maybe infiniband).

I'm should have been more specific and said I was talking about FM SERVER performances with few people (5 + 1 with heavy script).

FMP Client, YES, it uses the machine performance.

I'm not talking about hundred of clients doig heavy stuff simulatneously which is possibly where you could have seen the benfits of RAID and better hardware