Garbage collection pause: GC event causing request delays

Excessive server-side scripting with large data processing operations creating temporary objects that overwhelm the heap space. (high likelihood)

Memory leaks from poorly written Business Rules, Script Includes, or scheduled jobs that retain object references beyond their useful lifecycle. (high likelihood)

Large database query results being loaded into memory without proper pagination or streaming, particularly in reports or data exports. (medium likelihood)

Inadequate JVM heap size configuration for the instance workload, causing frequent full garbage collection cycles. (medium likelihood)

Third-party integrations or plugins consuming excessive memory through inefficient data handling or connection pooling issues. (low likelihood)

Step 1: Navigate to System Diagnostics > Stats > Memory Usage to examine current heap utilization, garbage collection frequency, and identify peak usage patterns.

Step 2: Check System Log > Application Logs for concurrent error messages or stack traces that might indicate which scripts or operations triggered the GC pressure.

Step 3: Review active Business Rules, Script Includes, and scheduled jobs in System Definition > Business Rules and System Definition > Scheduled Jobs for inefficient code patterns like large loops or unfiltered queries.

Step 4: Analyze database query performance in System Diagnostics > Stats > SQL Stats to identify slow queries that might be loading excessive data into memory.

Step 5: Implement query pagination using GlideRecord.setLimit() and proper indexing on frequently queried tables to reduce memory footprint of data operations.

Step 6: Contact ServiceNow support to review and potentially adjust JVM heap size settings if analysis shows consistent high memory utilization above 80%.

Step 7: Enable system property glide.gc.log_verbose to capture detailed garbage collection metrics for ongoing monitoring and trend analysis.