奇怪的 JRUN 问题。 JRUN 每两个小时消耗 50% 的内存
我有奇怪的 JRUN 问题。我已经在 Amazon EC2 实例上安装了 ColdFusion 9.0，似乎一切正常，除了 JRUN 在特定时间跨度内消耗了大约 50% 的内存。
在连续的两个小时内，CPU 使用率达到 50%，然后在接下来的 45 分钟到一个小时内，它可以正常工作，在接下来的两个小时内，CPU 使用率再次达到 50%。我没有运行任何计划文件。
另外，如果有人指导我如何知道哪个请求导致 JRUN 占用内存，我将不胜感激。 
感谢 MIKE 的建议，但似乎我已经启用了矩阵，但在 JRUN 运行时找不到任何更改正常，占用 50% 左右的内存。由于字符数的限制，我将日志作为单独的答案发布。此外，我还尝试停止 IIS，以确保没有外部请求发送到 ColdFusion，并且 FusionReactor 显示没有发送到 JRUN 的请求，但仍然使用高内存。
由 JRun 创建于 09/22 08:00:35
09/22 08:00:35 指标 Web 线程（繁忙/总计）：1/31 会话：0 总内存=684672 可用=228809 09/22 08:01:35 指标 Web 线程（繁忙/总计）：2/34 会话：0 总内存=761792 可用=364733 09/22 08:02:35 指标 Web 线程（繁忙/总计）：1/34 会话：0 总内存=773568 可用=338352 09/22 08:03:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=781696 可用=283261 09/22 08:04:35 指标 Web 线程（繁忙/总计）：3/36 会话：0 总内存=790784 可用=325807 09/22 08:05:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=794432 可用=301484 09/22 08:06:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=768640 可用=221172 09/22 08:07:35 指标 Web 线程（繁忙/总计）：1/38 会话：0 总内存=793984 可用=245422 09/22 08:08:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=790080 可用=376290 09/22 08:09:35 指标 Web 线程（繁忙/总计）：1/38 会话：0 总内存=792832 可用=307553 09/22 08:10:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=792000 可用=337115 09/22 08:11:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=789184 可用=240118 09/22 08:12:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=789440 可用=342658 09/22 08:13:35 指标 Web 线程（繁忙/总计）：1/39 会话：0 总内存=787520 可用=347211
在此阶段之后，JRUN 以 50% CPU 使用率运行。
09/22 08:14:35 指标 Web 线程（繁忙/总计）：1/39 会话：0 总内存=770112 可用=211797 09/22 08:15:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=726208 可用=249031 09/22 08:16:35 指标 Web 线程（繁忙/总计）：1/38 会话：0 总内存=715392 可用=158240 09/22 08:17:35 指标 Web 线程（繁忙/总计）：1/39 会话：0 总内存=705600 可用=239585 09/22 08:18:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=718848 可用=175842 09/22 08:19:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=687488 可用=204397 09/22 08:20:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=701440 可用=185422 09/22 08:21:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=671744 可用=154754 09/22 08:22:35 指标 Web 线程（繁忙/总计）：2/35 会话：0 总内存=664320 可用=163835 09/22 08:23:35 指标 Web 线程（繁忙/总计）：1/33 会话：0 总内存=674752 可用=195576 09/22 08:24:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=661760 可用=203445 09/22 08:25:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=656576 可用=174511 09/22 08:26:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=651968 可用=194924 09/22 08:27:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=632896 可用=152896 09/22 08:28:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=633984 可用=215603 09/22 08:29:35 指标 Web 线程（繁忙/总计）：1/34 会话：0 总内存=630720 可用=198136 09/22 08:30:35 指标 Web 线程（繁忙/总计）：2/35 会话：0 总内存=616512 可用=140867 09/22 08:31:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=613824 可用=140683 09/22 08:32:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=605184 可用=166131 09/22 08:33:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=608448 可用=132906 09/22 08:34:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=609344 可用=180291 09/22 08:35:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=603008 可用=161821 09/22 08:36:35 指标 Web 线程（繁忙/总计）：2/36 会话：0 总内存=604672 可用=150526 09/22 08:37:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=606144 可用=162952 09/22 08:38:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=602048 可用=136201 09/22 08:39:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=606656 可用=116793 09/22 08:40:35 指标 Web 线程（繁忙/总计）：1/37 会话：0 总内存=602880 可用=120984 09/22 08:41:35 指标 Web 线程（繁忙/总计）：1/36 会话：0 总内存=607424 可用=112235 09/22 08:42:35 指标 Web 线程（繁忙/总计）：1/35 会话：0 总内存=607424 可用=135657
I have strange JRUN issue. I have installed ColdFusion 9.0 on Amazon EC2 instance and seems everything working good except JRUN eating up arround 50% of memory for particular timespan.
For countinous two hours it take 50% of CPU usage and then next 45 min to an hour it work normally and again it take 50% for next two hours. I am not running any schedule file.
Also I will appreciate if anyone guide me how we can know which request causing JRUN to eat memory.
Thanks for suggestion MIKE, but it seems that I already enable matrix but cann't find any changes when JRUN was running normal and taking arround 50% memory. As limitation of number of character I am posting log as separate answer. Also I have tried to stop IIS to make sure no external request come to ColdFusion and FusionReactor shows no requests to JRUN but still using high memoery.
Created by JRun on 09/22 08:00:35
09/22 08:00:35 metrics Web threads (busy/total): 1/31 Sessions: 0 Total Memory=684672 Free=228809
09/22 08:01:35 metrics Web threads (busy/total): 2/34 Sessions: 0 Total Memory=761792 Free=364733
09/22 08:02:35 metrics Web threads (busy/total): 1/34 Sessions: 0 Total Memory=773568 Free=338352
09/22 08:03:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=781696 Free=283261
09/22 08:04:35 metrics Web threads (busy/total): 3/36 Sessions: 0 Total Memory=790784 Free=325807
09/22 08:05:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=794432 Free=301484
09/22 08:06:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=768640 Free=221172
09/22 08:07:35 metrics Web threads (busy/total): 1/38 Sessions: 0 Total Memory=793984 Free=245422
09/22 08:08:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=790080 Free=376290
09/22 08:09:35 metrics Web threads (busy/total): 1/38 Sessions: 0 Total Memory=792832 Free=307553
09/22 08:10:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=792000 Free=337115
09/22 08:11:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=789184 Free=240118
09/22 08:12:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=789440 Free=342658
09/22 08:13:35 metrics Web threads (busy/total): 1/39 Sessions: 0 Total Memory=787520 Free=347211
After this stage JRUN was running at 50% CPU Usage.
09/22 08:14:35 metrics Web threads (busy/total): 1/39 Sessions: 0 Total Memory=770112 Free=211797
09/22 08:15:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=726208 Free=249031
09/22 08:16:35 metrics Web threads (busy/total): 1/38 Sessions: 0 Total Memory=715392 Free=158240
09/22 08:17:35 metrics Web threads (busy/total): 1/39 Sessions: 0 Total Memory=705600 Free=239585
09/22 08:18:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=718848 Free=175842
09/22 08:19:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=687488 Free=204397
09/22 08:20:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=701440 Free=185422
09/22 08:21:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=671744 Free=154754
09/22 08:22:35 metrics Web threads (busy/total): 2/35 Sessions: 0 Total Memory=664320 Free=163835
09/22 08:23:35 metrics Web threads (busy/total): 1/33 Sessions: 0 Total Memory=674752 Free=195576
09/22 08:24:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=661760 Free=203445
09/22 08:25:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=656576 Free=174511
09/22 08:26:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=651968 Free=194924
09/22 08:27:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=632896 Free=152896
09/22 08:28:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=633984 Free=215603
09/22 08:29:35 metrics Web threads (busy/total): 1/34 Sessions: 0 Total Memory=630720 Free=198136
09/22 08:30:35 metrics Web threads (busy/total): 2/35 Sessions: 0 Total Memory=616512 Free=140867
09/22 08:31:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=613824 Free=140683
09/22 08:32:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=605184 Free=166131
09/22 08:33:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=608448 Free=132906
09/22 08:34:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=609344 Free=180291
09/22 08:35:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=603008 Free=161821
09/22 08:36:35 metrics Web threads (busy/total): 2/36 Sessions: 0 Total Memory=604672 Free=150526
09/22 08:37:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=606144 Free=162952
09/22 08:38:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=602048 Free=136201
09/22 08:39:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=606656 Free=116793
09/22 08:40:35 metrics Web threads (busy/total): 1/37 Sessions: 0 Total Memory=602880 Free=120984
09/22 08:41:35 metrics Web threads (busy/total): 1/36 Sessions: 0 Total Memory=607424 Free=112235
09/22 08:42:35 metrics Web threads (busy/total): 1/35 Sessions: 0 Total Memory=607424 Free=135657
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如 Dan Short 在此查询的那样，如果您能获得有关 JRun 或更重要的是 JVM 正在做什么的完整详细信息，那就更好了。我已经多次解决这些问题并建议您启用“指标和 GC 日志记录”。您可以在这两篇博客文章中找到如何执行此操作的详细信息...
http://www.cfwhisperer.com/post.cfm/10-steps-to-a-stable-and-performant-web-application-step-2< /a>
http:// /www.cfwhisperer.com/post.cfm/10-steps-to-a-stable-and-performant-web-application-step-3
启用此日志记录后，我们实际上可以看到发生了什么和我建议至少记录 24 小时才能准确。
As Dan Short queries here it would be better if you get full detail about what JRun or more importantly, the JVM is doing. I have worked on these issues many times and suggest you enable "metrics and GC logging". You can find details of how to do this in these two blog posts...
http://www.cfwhisperer.com/post.cfm/10-steps-to-a-stable-and-performant-web-application-step-2
http://www.cfwhisperer.com/post.cfm/10-steps-to-a-stable-and-performant-web-application-step-3
Once you have this logging enabled we can actually see what is going on and I would suggest at least 24 hours of logging to be accurate.
在花了很多时间之后，我发现存储在注册表中的客户端变量导致了整个问题，而用于清除客户端变量的 ColdFusion 线程每小时运行一次，占用了太多的 CPU 使用率。这是完整的故事。
http://www .thecfguy.com/post.cfm/strange-coldfusion-issue-jrun-eating-up-to-50-of-cpu
After spending much time on it I figure it out that client variables stored in registry was causing whole issue and ColdFusion thread for purging client variable which was running every hour taking too much CPU usage. Here is full story.
http://www.thecfguy.com/post.cfm/strange-coldfusion-issue-jrun-eating-up-to-50-of-cpu