13
Replies
13
13
Replies
New Here
,
Does your production server jrun.exe leak memory like a siv
and max out CPU?
Does this happen on the hour?
Is your development server perfectly fine?
This is the problem I was having, I tried all of the following first, and finally stumbled upon the fix yesterday.
If someone from Adobe, or a forum junkie here reads this, please remember this next time. I spent at least 2 months trying to figure this out, and have seen countless other lost strangers on this very forum who are definitely suffering from this:
First, fixes I found that might help you, but didn't work for me:
1. Patch server (always a good first step)
2. Make sure cflock (for session variables) is being used correctly
3. robots.txt, lower crawl speed ("Crawl-delay" setting). (Google Tools didn't recognize this parameter) (just remembered my robots.txt is still gimped)
4. You can run the "Coldfusion Administrator" service with desktop access (Log On tab) and use CTRL+BREAK to do a dump for infinite loop type bugs
I probably tried 5 or 6 other things randomly, my server now has hot fixes and monitoring software galore.
It's not really a bug, it's a "best practices" notice I foolishly glanced over, or never learned as a developer.
It's a troubleshooting nightmare because:
A) It's extremely hard to replicate (it starts on the hour).
B) You install a fix, see the server run great for 30 minutes, think you've fixed it, and blam, at random, for seemingly no trackable reason (you don't expect it to be hourly when you have no scheduled tasks on that system), it starts growing to 900MB mem usage and using 20-99% CPU, BEEP.
C) It is nearly impossible to replicate on a small development server.
This is what worked for me:
Example 6
Before (and after) I did this, I purged the registry entries, about 50,000, using this
Does this happen on the hour?
Is your development server perfectly fine?
This is the problem I was having, I tried all of the following first, and finally stumbled upon the fix yesterday.
If someone from Adobe, or a forum junkie here reads this, please remember this next time. I spent at least 2 months trying to figure this out, and have seen countless other lost strangers on this very forum who are definitely suffering from this:
First, fixes I found that might help you, but didn't work for me:
1. Patch server (always a good first step)
2. Make sure cflock (for session variables) is being used correctly
3. robots.txt, lower crawl speed ("Crawl-delay" setting). (Google Tools didn't recognize this parameter) (just remembered my robots.txt is still gimped)
4. You can run the "Coldfusion Administrator" service with desktop access (Log On tab) and use CTRL+BREAK to do a dump for infinite loop type bugs
I probably tried 5 or 6 other things randomly, my server now has hot fixes and monitoring software galore.
It's not really a bug, it's a "best practices" notice I foolishly glanced over, or never learned as a developer.
It's a troubleshooting nightmare because:
A) It's extremely hard to replicate (it starts on the hour).
B) You install a fix, see the server run great for 30 minutes, think you've fixed it, and blam, at random, for seemingly no trackable reason (you don't expect it to be hourly when you have no scheduled tasks on that system), it starts growing to 900MB mem usage and using 20-99% CPU, BEEP.
C) It is nearly impossible to replicate on a small development server.
This is what worked for me:
Example 6
quote:
Symptom: CPU spins at 100% - and high memory usage - about every hour after startup (large memory use too).
Here's a common one that some fall into going from development to production. The default for storing client variables is "REGISTRY". Once the number of records in the registry is large, the query to get all records and delete expired client records can take 100% CPU for minutes at a time.
Registry client storage should never be used for production systems but often developers fall into this by accident by not explicitly specifying a data source (and the ColdFusion admin defaulting to "REGISTRY"). Since the registry isn't a real database, ColdFusion has to retrieve the entire registry client tree (high memory usage) and compare the date/time one at a time to decide whether to purge a record. This is a CPU-intensive operation with an hourly purge that may only delete a few records.
Since this is a system task, it's running in a scheduler thread instead of a jrpp thread. Here's a case where a scheduler thread is relevant.
Before (and after) I did this, I purged the registry entries, about 50,000, using this
Resources
Documentation
AdChoices