CFMX CPU Activity

Even though this article refers to CF5, it may be an issue in MX as well.  We ran into this same problem with CF5 and it sounds like the same as yours, with random memory spikes that appear to be associated with jrun process.

ColdFusion Server 5: Management Logs Can Cause High CPU Utilization  
TechNote 21807  

http://www.macromedia.com/v1/Handlers/index.cfm?ID=21807

Yes, your guess is similar to mine. I read the technote. CFMX, however, is very different, so the files, instructions, etc. are different. Also, I'm not sure you meant to say 'memory spikes'. On our system, memory gradually grows, but it never 'spikes'. CPU utilization jumps to 50 to 60%, and stays there for a few minutes, then drops down. And, I neglected to say earlier that this CPU utilization can definitely be attributed to jrun, as Task Manager indicates that in the process listing.

You may consider signing up to the CF-talk list, where there is currently a huge discussion regarding CFMX and CPU usage and CFMX performance.
You can go to http://www.houseoffusion.com to subscribe.

Personally,CFMX sucks.  I have found numerous problems with it and it really isn't all that it's cracked up to be.

I'm stickin with CF Server 5

Good luck to anyone trying to accomplish anything with CFMX

Thanks to DBrown for the reference. I poked around in their archives and found some discussions of speed, although all speed discussions I found did not touch on my issues. I think  that I will post there, though, also.

For those interested, we solved all of our problems with CFMX. It turns out that if you use Registry storage for client variables for a production server, even with modest traffic, the server will get CREAMED and eventually fail. In our case we got around 340,000 registry keys over a few week period, then the server started messing up on tracking CFID and CFToken, and generating new ID's when it shouldn't, it generated massive numbers of page faults, bumped up CPU utilization a lot, had gradual memory growth until all available memory except about 3 MB was taken by CFMX, etc. Eventually we could not add a user to the machine, could not edit the registry, etc. It was quite difficult to recover from this condition.

It turns out that the registry is a lousy place to try to maintain a rapidly-shifting data store of this type. What ends up happening is that a registry branch called Clients ends up with a gigantic list of keys. The maintenance of this list is basically hokey, and results in horrible fragmentation of the hive file, resulting in huge growth compared to the actual data size, poor access speed, and so on. Furthermore, Microsoft Windows misreports the max size allocation of the Registry once it gets beyond a certain size, as documented in their tech notes Q142719, Q126402, and Q124594.

Macromedia claims in their docs that you should not use Registry store for client variables for high traffic sites. What they should say is DO NOT USE REGISTRY STORE, PERIOD! Get off it as soon as you have a working data source, which should be fairly early in your development cycle. Registry client store is OK to verify a newly installed server, and for a little bit of puttering around, but you should use a data source for your store right away, and not look back. They make it quite easy, as long as it is an SQL data source.

I hope no one else has to go through what we went through learning this rather expensive lesson.

Now that we are using an SQL client variable store, CFMX is quite well-behaved, and life is good!

dn

No comment has been added lately, so it's time to clean up this question.
I will leave the following recommendation in the Cleanup topic area:

PAQ/Refund

Please leave any comments here within the next four days.

mrichmon
EE Cleanup Volunteer