Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8553 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Used to run FMS on a G4 1g with a L3 array. Moved it to a W2K server - still with 1g of RAM.

I remember trying to serve some of our more heavily bashed databases of off a RAM disk on the G4. First of all, I could only make a 256mb ramdisk on the mac. Second of all, it turned a rock solid server into a er,....less than rock solid server. Third of all, the performance increases were minimal.

Now on the new W2K server, I can see avg disk queues often so the array often isn't keeping up the requests. I was thinking of trying the RAM disk thing again. Anyone have any experience with this on W2K FMS?

Any advice or comments appreciated!

TIA,

Mark Maytum

Pompanoosuc Mills Corporation

Posted

This is a rehash of your first setup. If you use a shareware program from Clarkwood Software called RAMBunctious, you can have as large a RAM disk as you wish (RAM allowing), automatic write-thrus on the schedule you wish, and stability is actually improved. We have about 4 server years experience with this setup and it works quite well.

-bd

Posted

RE: quite well

I hope that means 100% smile.gif" border="0

To the W2000: our "server master" guy specifically prohibited us to upgrade server from NT4 sp6 to W2K.

In any case, what are FM settings, size of cache and max databases etc?

What are the reports after heavy day?

Posted

Hmm. We might be talking two different things here.

Rambunctious is a Mac only product (as far as I can see from their website). I'm looking for some recommended ramdisk software for W2K server.

Anatoli,

Can't imagine why your IT guy didn't want to upgrade from NT to W2K. I'm sure he had good reasons that I know nothing about.

Anyhoo, disk queues are instantaneous. They're a measure of requests to access the disk that have to wait because another is in process. At some busy points during the day DQ's are several hundred/sec. Since this is a very fast array, controller and driver. The next logical step seems to be a ramdisk.

FYI, the server cache is 40mb, files hosted are 52 (around 700mb) and max users are 100 with roughly 70-80 connected at any one time. I do graph the FMS cache hits and it seems like the line is rarely pegged at 100% anymore.

Posted

RE: Rambunctious is a Mac only product (as far as I can see from their website). I'm looking for some recommended ramdisk software for W2K server.

Anatoli: I think that properly configured server will not benefit much from RAM disk.

RE: Can't imagine why your IT guy didn't want to upgrade from NT to W2K. I'm sure he had good reasons that I know nothing about.

Anatoli: he knows. We cannot pay him enough. He is the best here, frequently doing seminars for HP and such clients.

RE: Anyhoo, disk queues are instantaneous. They're a measure of requests to access the disk that have to wait because another is in process. At some busy points during the day DQ's are several hundred/sec. Since this is a very fast array, controller and driver. The next logical step seems to be a ramdisk.

Anatoli: that is contradicting "instantaneous" and RAM disk. You need probably some of the:

1. Better design of the solution

2. More powerful hardware with 2-4 processors and perfect tuning of server.

3. Perfect network

4. Better setup of FM server. Try limit the databases and users. Increase RAM cache as much as you can e.g. 500-1000 MB. That will be better, than RAM disk.

FYI, the server cache is 40mb, files hosted are 52 (around 700mb) and max users are 100 with roughly 70-80 connected at any one time. I do graph the FMS cache hits and it seems like the line is rarely pegged at 100% anymore.

Anatoli: try increase the machine RAM at maximum and give FM much much more RAM cache. See above.

Posted

Maybe I'm being dense, but as far as I know, the maximum ram cache on FMS is 40mb. I'd *like* to set it higher, if someone knows a workaround. The server has 1g in it. But at this point, it's largely a waste as FMS isn't committing enough of it. I want more server data in memory. Whether it's cached by FMS or on a RAM disk doesn't matter to me (so far :-)).

I've never seen processor power on a FMS become a bottleneck - and it's not on ours. As for total throughput of a FM system, the bottleneck is almost always processing power of the client. I've only recently run into the problem of the FMS's disk array becoming a bottleneck under high client load.

I could split the one server into two but it seems prudent to try the RAM disk route first.

BTW, disk queues are reported by perfmon as instantaneous for a given sample period, they're not cumulative. That's what I meant by instantaneous. High disk queues/sec point to a bottleneck in the disk subsystem.

Posted

I will have a look into the stuff with RAM tomorrow at client site.

One more question: do users see some delays? In what part of solutions?

Could you give me all stats from FM server?

Posted

You are right, about 40MB. I thought, that it is only on our 128MB servers (2 of them).

BTW, if average size of record is 1k that is 40 000 records in cache. That should be sufficient.

Maybe you have bottleneck in your HW/SW configuration.

Or an W2k issue.

Give me all details, full configuration and full stats!

Posted

Are you running FMS on a W2K SERVER? or workstation? (FMS runs better on workstation). If FMS is running on W2K server OS, and the machine is not dedicated to FMS only, FMS will have low priority for processor time with file/print server services given highest processor time.

I suggest using either W2K Workstation OS or NT4.0 sp6. You will get the best performance if it is a dedicated FMS machine.

This topic is 8553 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.