Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

GC Overhead limit exceeded with debugging enabled in 5.3

Description

with no debugging template defined, but debugging enabled only for queries, I am seeing Lucee maxing out the CPU and then GC crashes after a few requests.

Just repeating the same request with debug logging enabled, sometimes it performs almost the same as with debugging disabled, others take 5 times as long.

If I disable debug logging, then it's all fine again

this was fine with the latest 5.2 snapshot, I've tried going back a few 5.3 snapshots and this problem has been there since at least 5.3.1.58

I've been playing around with this a bit trying to find a useful stacktrace, but they are all pretty random caused by hitting GC limits than anything specific

Java 1.8.0_181-b13, Tomcat 8.5.31.0

Environment

None

Attachments

6
  • 20 Dec 2018, 01:29 pm
  • 13 Dec 2018, 04:03 pm
  • 13 Dec 2018, 02:31 pm
  • 04 Dec 2018, 02:59 pm
  • 19 Oct 2018, 10:48 am
  • 19 Oct 2018, 10:47 am

Activity

Show:

Bruce Kirkpatrick 8 February 2019 at 14:17

OK. I just want to mention that the stability problem of debugging will persist for the query logging feature, which isn't related to the scope feature.

You have not given the developer control of when the query logging occurs at the request level, so the server begins storing queries for all requests (up to the limit of them set in the admin). In a real application, this makes Lucee use more memory then usual, which can crash the server or crash individual requests with out of memory related errors sometimes.

on my version, I now enable debugging per request with query string parameter to resolve this.

A production server churns through the requests so fast that you can't even click on the debugging log entry fast enough before it gets deleted many times, which is an additional problem solved by giving the developer more control. It could be done by ip, but because lucee can be behind a web server, the remote_addr field is not accurate, so I'd need to be able to use a different header if the control was given via IP. I'm just trying to help other users, since I already fixed this for myself.

Zac Spitzer 8 February 2019 at 14:15

if show debuggingoutput is set to false for a request, are the debug logs persisted?

Michael Offner 8 February 2019 at 13:57

https://github.com/lucee/Lucee/commit/f57832dcdc7cfd2832b8561a02c7c829745d0f1c

we disabled the scope caching feature altogether (for the moment), scope are simply not terministic and and be very big. if we add this again, it need much more control on what is stored exactly.

We reviewed all data from the debugging pool from that perspective.

Zac Spitzer 13 December 2018 at 16:08

attached is a quick script to dump out the size of the debugging logs

I'd suggest rather than just trying with simple test cases, try it out with some some different realworld example apps which use a framework.

Pothys - MitrahSoft 13 December 2018 at 14:32

I've created a schedule task & the url(page) having query that was stored in application scope. Task running on every 10s & query was stored in application scope with unique variable name. Also created a debugging templates every task has been logged success fully with specific interval time.

I analyze my heap dump from eclipse memory analyzer look's like below.

Fixed

Details

Assignee

Reporter

Priority

Labels

Fix versions

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Sprint

Affects versions

Created 7 September 2018 at 11:24
Updated 25 April 2019 at 10:11
Resolved 8 February 2019 at 14:07

Flag notifications