Troubleshooting excessive logging (syslog)SummaryThe syslog table in an instance can grow very large due to excessive and if this happens, you may notice issues such as: Disk space issues on the host database server if the syslog shards grow really largeSlow performance or even timeouts when trying to query the System LogsInstructionsTo investigate excessive logging (system logs -> all), use the tips below to look for a pattern and see what is appearing most in the log table. Keep the data result set small & using a filter on created. If the query times out with a filter condition of 1 day or more, consider using an even smaller time frame of an hour, or even 15-minute chunks. If you do decide to grab some smaller chunks, make sure to check a few different time slots to make sure the logging patterns that you are seeing are consistent. (All>Created between 2021-09-14 10:00:00 and 2021-09-14 10:15:00)Here you are looking for any patterns - do you see the same message repeated very frequently?Add in additional columns like context_map which can sometimes help pinpoint the source of the loggingIt is not recommended to remove the condition filter, as this will trigger a very expensive query on the database (it will union all the syslog shards together which is a bad idea) Check the instance for any long running jobs or user transactions. Often either of these could be the cause of the issue, or it could be jobs that run fast but repeat frequently. To find any long running jobs or user transactions, Filter Navigator -> Active Transactions (all nodes). Sort on the age column. Once the excessive records have been identified, review the Message and/or Context Map column for clues as to the problem script/piece of codeOnce the suspected problem is fixed, check the log tables for the last 15 minutes to see if the logging has reduced. If the logging has reduced for the log message that was targeted, that is good news. Remember that the syslog tables are configured with table rotation, which means that syslog is a logical table but behind the scenes there are 8 physical tables on the database. Each table or shard is responsible for 7 days worth of logs. Every 7 days, the oldest table/shard is deleted. So this means that even if you stopped the excessive logging, the space utilised by the log messages will only be reclaimed or freed up when it's the turn of the syslog table to be rotated out (deleted). Support can help to truncate the tables if there is an urgent or important need.Have you recently added any gs.log statements to code to troubleshoot an issue but forget to remove the statements afterward? Related LinksKB0819668 Service Catalogue item to identify top 10 tables in an instance (if you see syslog on this list, it probably needs a review)