October 21, 2002 As noted last time, were going to shift gears a bit with this posting and talk about a subject near and dear to our hearts...how to manage memory in Helix 5.
Since this experiment began back in June, weve made every effort to solve each technical problem presented to us in a timely and effective manner. A few times in the past few months, weve encountered situations where the lack of comprehensive or definitive information about this memory management has resulted in, to be generous, a less-than-satisfying experience for some Helix users. It appears that, in spite of the availability of rather profuse documentation on the subject, these users either have not seen, or just cant figure out what to do when they find their way to the Memory Preferences dialog depicted above.
Too often, when faced with a new feature or a change to an old feature, theres a tendency on the part of users to attempt to apply old knowledge to new problems. The rules have changed in Helix 5 and you need to look at memory management issues through new eyes. This is our first--and hopefully only--proactive attempt to explain what these differences mean on a practical level. Before moving into the discussion, we need to point out that there are three major obstacles to creating the aforementioned, much-needed comprehensive or definitive information, illustrated by the three obviously ridiculous questions that follow:
Obstacle #1: Why cant everyone be just the same as everyone else?
Helix users seem to come from nearly every walk of life, and their knowledge levels range from novice to know-it-all. And be they developers, end-users, business users, personal users, network clients or technicians, their levels of expertise never seem to correlate with their system- or Collection-maintenance habits. (This is a nice way of saying that there are still too many supposedly well-informed people who fail to keep their systems in optimal condition, run the Helix utility programs or even back up their work.)Occasionally, we have the added burden of dealing with the inability or unwillingness on the part of a few people to provide us with real email return addresses or telephone numbers. [You know who you are. So do we, and we want to help, but youve got to give us a way to reach you. Why put us to work for you if you dont want to know whats crashing your Collection?]
Obstacle #2: Why cant there be just one simple Helix Collection?
If all this diversity didnt make Helix Technical Support difficult enough, there is the absolutely inalienable fact--and this cant be emphasized strongly enough--that no two Collections are alike.This can even be said for a Collection that is duplicated from another one. Two seemingly identical Collections may certainly have different amounts of data in them. Two Collections of exactly the same size might have vastly different structural components. And when we talk about structural complexity, theres no simple rule of thumb to determine what that term means. There are Collections smaller than a megabyte that are structurally more complex than those many times larger. And structural complexity is not necessarily merely a function of how many relations are found within a Collection.
Obstacle #3: Why cant everyone just use exactly the same computer?
The situation is further exacerbated by the practically limitless vista of hardware configurations. Each computer has a CPU, a hard drive, some amount of memory, user settings that are almost always in a state of flux and an infinite variety of @&#$ installed in their system folders. Is your Collection running in a RAM disk? Is it on an NT server? And then theres the networking issues. Are you on Ethernet or LocalTalk wiring? Are you using AppleTalk or TCP/IP?
What does it all have to do with managing memory in Helix 5?
Well, there are, sadly, no hard and fast rules that can be applied to the great diversity of Helix situations. However, and in keeping with our theme of attempting to be very general, there are three areas that you as a user must be responsible for managing. These are:
Responsibility #1. Your knowledge of Helix and how best to use the tools it provides.
This is a subject far too vast to ever be covered on a single web page. The sheer diversity of applications makes it virtually impossible to create a single volume that adequately conveys how to use Helix. We hope it wont be too much longer before we can resume Helix training. Until then, folks, youre on your own here. Fortunately for most of you, Helix is forgiving enough to let you get away with almost anything you can concoct.Responsibility #2. How your hardware and software are maintained
A section of our Helix Reference (available as a free download from this web site) offers very smart guidelines about this. If you arent doing at least what is recommended therein, you should probably be ashamed of yourselves...especially when your Collection cracks and you have no backups.Responsibility #3. The amount of memory they apply to their Helix application and how to optimally allocate that memory.
Today, were going to focus on this one because the information in our Helix Reference is admittedly long on technical and short on procedural. Clearly more of you seem to be reading whats written here than reading the Helix Reference, so as long as weve got you for a little while, were going to strike while the iron is hot. And even though we can only offer--at best--some very general guidelines, the increased incidence of calls about this issue of late has caused us hop off our 5.0.3 and OS X development cycles for a moment and attempt to clear up some common misconceptions about memory management in Helix 5.
Lets begin with the most frequently asked question:
Do I Have To Use These Features? What If I Just Ignore That Screen?
OK. Suppose you just download 5.0.x and install it, crank the RAM up to where you last had it and go back to work. Is there a downside to this?
All things being equal, everything should work, memory-wise, about the way it worked in 4.5.5 or whatever you were using before you upgraded. Actually, prior to this version of Helix, when you increased the RAM allocation to a Helix application in the Finder, Helix simply divided that additional RAM between its own internally-managed Data and Structure caches. For those of you who have delved deeper into this subject in the past, we know its much more complicated than that, but remember, the purpose of this discussion is to arrive at some very general guidelines.
The downside is simple: youre not taking advantage of one of the key features of the Helix 5 product line. You paid for your upgrade and youre ignoring a potentially powerful tool that could considerably lighten your workload.
Where Is This Screen? How Does It Work?
As noted above, were going to attempt to create some very general rules. Were going to call them the "General Rules of RAMJet(")" and well start, as the Marx Brothers would say, with the first number:
1st General Rule of RAMJet: Turn off Virtual Memory
Sorry folks. Go out and buy yourself some real RAM. The price of computer memory right now is about as low as it will ever get. If you havent maxed out the RAM on your computer, theres probably no better time than NOW to fill those empty slots.
That seemingly small detail has surfaced in a number of calls, and unless you have VM off, none of the rest of this discussion will make any sense. If you must use some application that requires VM to be on, use it either on another machine or when Helix is not being used.
2nd General Rule of RAMJet: Turn AutoSave On and Save and Clear Caches Off.
AutoSave OFF is BAD. Make sure its ON. While in that dialog, make sure Save and Clear Caches is OFF. If youre using a Data cache, why would you want to clear it out after saving?
3rd General Rule of RAMJet: Know Where It Is
Four Helix applications have Memory Preferences: RADE, Server, Engine and the Helix Utility. You arrive at the screen above by selecting "Preferences" from the Edit menu or by typing command-semicolon when in any of these applications. Note that in RADE, the "Preferences" menu item is deletable from a User menu. Therefore, you may restrict access to this function if your collection design requires removing this command. In that situation, it will only be available in RADE when in Design Mode.
The most dramatic performance improvements generally seen--and this is based strictly on anecdotal evidence--is in the use of the Helix Utility. Users with enough RAM to get maximum benefit from this feature have reported that Collections that used to take an hour to run through the Helix Utility now run in under 10 minutes, some in under 5. Thats a pretty significant improvement. Whether we like it or not, one of the big sins frequently committed by Helix users is not running the Helix Utility often enough and one of the principal reasons given in informal surveys of why they dont is that it takes so long to run.
Later, youre going to learn about certain kinds of Helix errors that address Data and Structural memory caching. If you should see one of these errors while using Helix Client, or Helix Update Collection, which do not have Memory Preference settings, increase the amount of memory you allocate to these applications in the Finder.
4th General Rule of RAMJet: To use RAMJet, the Custom Caches must be On
Where is the improvement coming from? Custom Caches or RAMJet? By now, the name we have given our rules should give you the answer.
You really dont have much of a choice about this. You cant use the Data and Structure caches separately or exclusively. Turning on one turns on both. And without these, RAMJet cannot be turned on.
There are rare instances where it might make sense for you to adjust the size of the Data Cache. Some operations, for example, require that the Data cache be of a certain size (the exact numbers depend on multiple factors: number of records, number of Fields in records, total size of record data, number of Relations involved in the action, etc.) so setting it to its minimum value can sometimes result in 5xxx errors (more about which below). In these cases it is necessary to increase the data cache. You should view this as a concession, not an improvement. Having a smaller Data cache is better than having to have a larger Data cache. Sometimes the larger cache is unavoidable, but no less regrettable.
Generally speaking, however, the Data cache will always fill to overflowing and there's nothing you can do about it. No matter what you do, it will always fill to a point where there is around 72K free (this number may vary).
The purpose of the Data cache is to speed Helix by keeping recently read data in RAM, avoiding disk access. If youre going to use RAMJet, the Data cache is redundant and pointless. It should be kept out of the way as much as possible. The best approach is to minimize the delay and effect by keeping the data cache as small as possible.
At the risk of oversimplifying this, most often, increasing the size of the Data cache is like putting a larger bandage on a bleeding wound. Itll keep blood from dripping on the floor sooner, but eventually, the patient will still bleed to death if the bleeding doesnt stop.
5th General Rule of RAMJet: Start Small and Work Your Way Up
When you first enable the Caches and turn on RAMJet, try to ignore your inner voice, in particular the one telling you to crank up the cache settings. We say this in part because when you do eventually call for help, were going to ask if you tried this.
Since the Data cache setting is for the most part irrelevant, our advice is to start by leaving the custom caches at their default settings. Start low and observe the error codes. If you get 7xxx errors, increase the structure cache (in 2 MB increments). If you get 5xxx errors, increase the data cache (in 1 MB increments). If either problem persists beyond a doubling of the default settings, stop what youre doing and call technical support.
Now if you absolutely do know it all and you want to get any deeper into this, you should start by making periodic inspections of the Server Info screen during the day. Both caches will fill as the day goes on. The Structure cache needs to be set large enough that it never becomes completely full. We recommend keeping it large enough so there is always 1,000-2,000K of free space. And keep in mind that a good network administrator will keep an eye on changes to the size of the Collection over time and make appropriate adjustments so that the amount of overall RAM devoted to their Helix RADE or Server provides an adequate ceiling as the Collection grows.
6th General Rule of RAMJet: Unless you have enough real RAM to get your entire Collection into RAM, you will probably not derive maximum benefit from the use of this feature.
If you have a small Collection and more than enough RAM, you are probably not having speed and performance issues that would drive you to experiment with custom cache and RAMJet functions, even in The Helix Utility.
However, a significant number of Helix users have been using Helix for years and years and have Collections that have grown extremely large. Some of these users--and you know who you are--cant seem to bring themselves to part with any of their information so their Collections never achieve any kind of size stability and just keep on growing. These Collections would probably benefit most from the use of custom caches and RAMJet, provided, of course, that the machines are expandable to the amount of RAM needed and that someone actually buys and installs it. Remember what we said earlier about the price of memory!
Having said this, let us not discourage you from using RAMJet if you dont have enough RAM to totally enclose your Collection. Plenty of users have reported that the Helix Utility runs much faster than before on the same size Collection even though they dont have nearly enough RAM to get the whole thing in there. Just make sure that when you try it, do it on a Collection you have properly tested and backed up.
7th General Rule of RAMJet: Performance and Stability are NOT directly proportional
This statement of cold, cruel fact is a rule that must be respected. To illustrate its importance, we offer this graphic:
Theres almost always a trade-off between performance and stability. The faster you drive, the less control you have over your car. As you increase memory allocations you increase stability (to a point) and you decrease performance (again, to a point).
Obviously, too little memory causes problems of its own. but once you've gotten past the 'memory starved' situation of, for example, a 200 MB Collection running on Helix Server with 20 MB allocated, you then face the foggy world of not knowing where the perfect settings are.
Each type of memory (OS, Helix application, RAMJet, Structure cache, Data cache, plus other internal caches) has its own pair of curves, where too little or too much is bad. In between too little and too much is a pretty wide range of acceptable or "workable" values and "just right" is at some unknown spot in between. Because each memory type has its own curve, getting the settings right for one parameter might move another into a danger zone. Finding the compromise that allows everything to function acceptably is the hard part.
One of the purposes of RAMJet feature, besides the obvious RAM disk emulation, is that it gives you control over the Structure and Data caches. The larger and more complex the Collection, the longer the battle will be to find the set of values for your Collection. Working to get those settings optimized is WORK, but in all but the rarest of cases, persistence will pay off.
Bottom line question: How much RAM do I allocate to my Helix application in the Finder?
Depending upon the Helix application youre using (e.g., Helix RADE, Helix Server, etc.), Get Info in the Finder and find out what the minimum memory requirement is for that application. To this number, add the total of your custom caches plus the size of your Collection and then add another 10% or so to give it some breathing room, both for during the day as it uses memory, and over time as it grows in size.