DEV Community

Michael
Michael

Posted on • Originally published at gbase8.cn

Reducing GBase 8a gcware Log Volume to Save Disk I/O

#gbase #database #数据库 #performance

The gcware component in a gbase database cluster is responsible for consistency management and node state tracking. By default, it logs at the INFO level, which records every session creation and destruction. In environments with frequent short‑lived connections, these logs can grow to several gigabytes per day, generating unnecessary disk I/O. This guide shows how to adjust the log level to slash the log volume and reduce I/O pressure.

The Problem: Verbose Session Logging

With the default INFO level, you'll see entries like these for every connect/disconnect cycle:

Jun 05 08:29:30.011095 INFO  [GCWARE] CCS destroy session 3423
Jun 05 08:29:30.166465 INFO  [GCWARE] CCS create session 6,1,43,3986,20
Jun 05 08:29:30.166514 INFO  [GCWARE] register session with sessionid 3986
Enter fullscreen mode Exit fullscreen mode

Under heavy connection churn, this alone can produce GB‑sized log files daily, wasting disk throughput.

The Log Level Parameters

The log verbosity is controlled by two parameters that are not present by default in the configuration file. They must be added manually to the logging block of gcware.conf (or corosync.conf depending on your version).

A restart of the gcware service is required for changes to take effect.

logfile_priority (File Log Level)

This parameter sets the minimum severity for entries written to the log file. The default is info. When you set a lower priority (higher severity), only messages at that level or above are kept.

Value Messages Logged
debug All messages (most verbose)
info info, notice, warning, err, crit, alert, emerg
notice notice and above
warning warning and above
err err, crit, alert, emerg
crit crit and above
alert alert and above
emerg Only the most critical events

Example configuration that raises the threshold to err (errors and above only):

logging {
    fileline: off
    to_stderr: no
    to_file: yes
    to_syslog: no
    logfile: /opt/10.0.2.201/gcware/log/gcware.log
    gcware_system_log: /opt/10.0.2.201/gcware/log/gcware_system.log
    debug: off
    timestamp: on
    logfile_priority: err
}
Enter fullscreen mode Exit fullscreen mode

Note: If the debug parameter is set to on, logfile_priority is ignored and all messages are written regardless.

syslog_priority

This parameter works exactly like logfile_priority but applies to syslog output. It only takes effect when to_syslog is set to yes. In most deployments, syslog is disabled and this parameter can be ignored.

When to Adjust

  • Stable production clusters: Raise the level to err or warning. The volume drops dramatically while still capturing real problems.
  • Troubleshooting windows: Temporarily lower the level back to info (or even debug) to collect detailed traces, then revert.
  • Development / test environments: Keep at info or debug for full visibility.

Summary

A simple logfile_priority adjustment in your gbase database gcware configuration can eliminate gigabytes of pointless session logging and reclaim disk I/O. After making the change, restart the gcware service and verify the cluster remains healthy with gcadmin. This small tweak is especially valuable in environments with high connection turnover, where it can noticeably improve overall node responsiveness.

Top comments (0)