System properties

  • Release version: Yokohama
  • Updated January 30, 2025
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of System Properties for Data Management in Yokohama Release

    This document explains key system properties that govern the Data Management capabilities in ServiceNow Yokohama release as of January 30, 2025. These properties provide control over the archive and destroy processes, helping you optimize performance and resource consumption during data archiving and table cleaning operations.

    Show full answer Show less

    Archive Rule and Destroy Rule Properties

    Archiving uses a producer-consumer model to manage data efficiently:

    • The ArchiveProducerJob creates chunks of record IDs (sysids) for archiving, stored in the Archive Job Execution Chunks [sysarchiverunchunk] table.
    • Each chunk corresponds to a single archive rule, with the chunk size controlled by glide.db.archive.chunksize.
    • The total maximum records processed per rule across all chunks is set by glide.db.archive.max.rule.records.
    • By default, 4 consumer jobs (ArchiverJob) process these chunks concurrently, controlled by glide.db.archiving.maxconsumerworkers.
    • Each consumer processes a number of chunks specified by glide.db.archive.max.batches before shutting down and scheduling a replacement.
    • If a chunk exceeds the processing time limit specified by glide.db.archive.chunk.max.process.time, it is marked as error, allowing detection of stalled processes.

    Important: These archive properties are only effective if the sysarchiverunchunk table exists.

    Key Archive System Properties and Their Practical Use

    • glide.db.archive.chunksize: Controls the maximum number of records in each archive chunk, influencing batch sizes for archiving.
    • glide.db.archive.chunk.max.process.time: Sets how long a chunk can remain active before being considered errored, helping detect and handle stuck processes.
    • glide.db.archive.max.rule.records: Limits the total records processed per archive rule in one batch, balancing resource usage.
    • glide.db.archive.max.batches: Defines how many chunks a consumer processes before restarting, which can affect throughput and system load.
    • glide.db.archiving.maxconsumerworkers: Controls the maximum number of concurrent consumers, allowing tuning for available system resources.
    • glide.db.archive.debug: Enables verbose logging for troubleshooting archive table schema copying.

    Adjusting these properties enables you to fine-tune archiving to your environment’s performance and resource constraints.

    Table Cleaner Properties

    Table cleaner properties help manage cleanup jobs that delete records in bulk, especially handling slow-running rules:

    • glide.db.tablecleaner.daysbeforeslowrulereattempt: Sets the number of days to wait before retrying a table cleaner rule that previously took longer than 30 seconds and stopped the job. Default is 2 days. Adjust this to control retry frequency for slow rules.
    • glide.db.tablecleaner.chunkdeletemaxtimespent: Defines the maximum time in seconds the table cleaner spends deleting records per rule during one run. Default is 1200 seconds (20 minutes). Modify this to control job run duration and system impact.

    Practical Considerations for ServiceNow Customers

    • These properties allow you to control the pace and concurrency of archiving and table cleaning, helping prevent resource exhaustion and improve system stability.
    • Modifying these values can optimize performance based on your environment size, load, and maintenance windows.
    • Use debug logging to troubleshoot archiving issues when necessary.
    • Ensure the sysarchiverunchunk table is present for archive-related properties to take effect.
    • Set appropriate retry intervals and time limits for table cleaner jobs to avoid prolonged system impact from slow queries.

    These system properties control the behavior of the Data Management capabilities.

    Archive rule and destroy rule properties

    Rules to prevent the archive process from consuming too many system resources have been automated. You can manually change the system behavior.

    The archive process uses a producer and consumer model. Records are queued for archiving in the Archive Job Execution Chunks [sys_archive_run_chunk] table in batches.

    • The ArchiveProducerJob creates chunks of sys_ids records that need to be archived. Each chunk contains records pertaining to a single archive rule. The maximum number of records in a chunk is specified by the property glide.db.archive.chunk_size. The maximum number of records for a single rule across all chunks is specified by glide.db.archive.max.rule.records.
    • The producer starts up 4 (default) ArchiverJob consumers. The exact number of consumers is specified by glide.db.archiving.max_consumer_workers.
    • Consumers read and process chunks of sys_ids. The number of chunks each consumer processes is specified by glide.db.archive.max.batches. The chunks processed by each consumer may be from different archive rules.
    • Consumers repeat reading chunks of sys_ids until none remain or the limit of chunks a consumer can process (specified by glide.db.archive.max.batches) is reached, after which it shuts down and schedules another consumer.
    • If a chunk remains in the running state longer than what's specified in glide.db.archive.chunk.max.process.time, the system assumes that the consumer abruptly terminated, and it changes the chunk’s status to error. This doesn't stop or end any running consumers.
    Note:
    The archive and destroy properties listed in the table are not used if the Archive Job Execution Chunks [sys_archive_run_chunk] table is deleted.
    To manually control how many records the archive rule and destroy processes at one interval, you can change these default settings by adding the following system properties.
    Table 1. Archive System Properties
    Name Description Type Default Value
    glide.db.archive.chunk_size Number of unique identifiers added to each record in the Archive Job Execution Chunks [sys_archive_run_chunk] table. The record is formatted as CSV values in the keys field of the Archive Job Execution Chunk (sys_archive_run_chunk.do) form. Integer 1000
    glide.db.archive.chunk.max.process.time Number of milliseconds a record can remain in the Active state in the Archive Job Execution Chunks [sys_archive_run_chunk] table. The time is the difference between the system time and the value of the Start field in the Archive Job Execution Chunks [sys_archive_run_chunk] table. Integer 600000
    glide.db.archive.max.rule.records Maximum number of records to batch per consumer, per rule. Integer 10000
    glide.db.archive.debug Option that enables verbose logging when copying the column definitions from the original table to the archive table. true | false false
    glide.db.archive.max.batches Number of chunks, which are records from the Archive Job Execution Chunks [sys_archive_run_chunk] table, processed by a consumer before it shuts down and schedules another consumer. Integer 10
    glide.db.archiving.max_consumer_workers The maximum number of concurrent consumers cluster-wide. Integer 4

    Table cleaner properties

    To set table cleaner system properties, navigate to the System Properties [sys_properties] table and add the property.

    Table 2. System properties
    Property Description

    Configure the number of days table cleaner must wait before attempting to reprocess a slow rule.

    glide.db.tablecleaner.days_before_slow_rule_reattempt

    		 When a table cleaner rule has a query that takes longer than 30 seconds to complete, the entire table cleaner job is stopped. By default, table cleaner waits two days before including that rule in the table cleaner job again.

    You can change the default waiting period by adding this property.

    • Type: integer
    • Default value: 2

    Configure a time limit for a table cleaner rule.

    glide.db.tablecleaner.chunk_delete_max_time_spent

    		 Limits how long the cleaner spends trying to batch-delete records per rule during a single run. The value is given in seconds and defaults to 1200 (20 minutes), which means the table cleaner runs hourly for a maximum of 20 minutes.

    You can change the default time limit by adding this property.

    • Type: integer
    • Default value: 1200