Skip to main content

How do I disable [Txn] messages in vertica.log?

  • March 20, 2014
  • 4 replies
  • 27 views

Michael_Johnson
We are seeing a very high rate of "INFO" log messages in our vertica.log files across the cluster.  It is not unusual to see > 2GB in a day.  This is putting unnecessary IO load on the /Catalog storage system and we would like to disable these info level messages.
Examples:
2014-03-19 17:21:28.777 Init Session:0x7f339c01c7d0-a00000054baa17 [Txn] <INFO> Begin Txn: a00000054baa17 ''
2014-03-19 17:21:29.097 Init Session:0x7f339c01c7d0-a00000054baa17 [Txn] <INFO> Starting Commit: Txn: a00000054baa17 ''
2014-03-19 17:21:29.097 Init Session:0x7f339c01c7d0 [Txn] <INFO> Commit Complete: Txn: a00000054baa17 at epoch 0xdd0227

It appears to be at least three log entries per transaction.

I can't seem to find any discussion of disabling these messages in the documentation.  I would like to bump the log level on these message one level up so that we don't get all of these INFO level messages.

Thanks!

4 replies

pviennea
Forum|alt.badge.img
  • Participating Frequently
  • March 22, 2014
Hello Michael, there is a way to disable these entries from appearing in the logs. I first would like to caution you to be aware that Vertica support will always require log information be capture and sent to Vertica in the event you need us to diagnose problems. If the requested logs are not available at time of issue it will be nearly impossible to troubleshoot root cause.

The command to stop all [Txn]<INFO> from logging is as follows:
select clear_debug_log('TXN', 'INFO');

The command to (re)start [Txn]<INFO> logging is as follows:
select set_debug_log('TXN', 'INFO');

NOTE: Please disable with caution.

Pat




Michael_Johnson_1
Thank you for the reply, that was exactly what I was looking for.

As a followup to your warnings, is there a way to move the vertica.log to a different file location than the overall catalog?  If I can put it on a different volume I may be able to leave it so verbose.

Thank you again,
Michael

pviennea
Forum|alt.badge.img
  • Participating Frequently
  • March 24, 2014
Hello Michael, your best option is to use the provided OS Log Rotate Utility.

The logrotate utility, which is included with most Linux distributions, helps simplify log file administration on systems that generate many log files. Logrotate allows for automatic rotation, compression, removal, and mailing of log files and can be configured to perform these tasks at specific intervals or when the log file reaches a particular size.

Full details can be found at https://my.vertica.com/docs/7.0.x/HTML/index.htm#Authoring/AdministratorsGuide/Monitoring/Vertica/Ro...

I hope this information is helpful.

Pat


Michael_Johnson
  • Author
  • New Participant
  • March 24, 2014
My issue isn't size and archival.  Logrotate is working just fine.  It is the IO bandwidth the vertica.log is taking on the Catalog volume.  The logging is very verbose and loading gigabytes into the vertica.log per day per node.  Even with a fairly high performance storage array backing the Catalog volume I am seeing IO queuing on this volume and decreased performance from Vertica (we have done some performance tests moving the Catalog volume to different storage subsystems).  This is why I am interested in ways to move the log file(s) over to a dedicated volume from the Catalog volume.

Thanks