← Managing Output FormatsMigrating Objects with the Promotion Module →

Regular Activities for Redwood Server

All housekeeping has been scheduled to run in intervals of 15 minutes by default, which should be sufficient for most systems.

Customizing Housekeeping

When your system is very busy and one or more of the following processes runs for too long or uses too many system resources at any given point in time, you might want to consider scheduling these processes less frequently or at specific times.

Please note that changing the periodicity of these processes can have the following consequences:

  • statistics data will tend to be outdated the more you widen the interval
  • keep clauses will be honored late the more you widen the interval which can affect disk space and overall performance
  • the total amount of disk space used by processes for output and logs at peak times will increase, since the output is deleted later files will pile-up

The Following submit frames are associated with the above processes and should be used to influence their periodicity:

  • System_UpdateJobStatisticsSubmitFrame
  • System_ProcessKeepClausesSubmitFrame
  • System_DeleteJobFilesSubmitFrame

See the Tuning Redwood Server and Submit Frames sections for instructions on changing the submit frames which control periodicity of these tasks.

Archiving Processes and Chains

The Active Archive module allows you to archive processes with their output to an external archive system based on the leading enterprise document management system Report2web. This allows you to offload the central Redwood Server and keep it responsive all while keeping your output and metadata available.

Automatically Deleting Processes and Chains

You control the size of the history (number of processes in the repository) with the keep clauses which can be specified on the process; optionally, you set a specific date/time on the KeepExpiration field of the process. By default, all processes are kept, it is however strongly recommended to specify a keep clause for every process that is to be scheduled regularly. See Automatically Deleting Old Processes for more information.

Retention Warnings

Redwood Server allows you to specify retention limits which, when reached, will display a warning. The default limits are:

  • 100 000 processes in Redwood Server
  • 10 000 new processes over a period of 24 hours
  • 80% of processes without a specific keep clause

The warning is displayed if 80% of non-system processes do not have a keep clause set and either the maximum number of processes has been reached ( 100 000 ) or the number of new processes over a period of 24 hours reaches 10 000.

You can specify your own criteria using the retention registry entries.

Deleting Processes and Chains Manually

There are two basic ways of deleting processes in the user interface:

  • You can select one or more in the processes monitor (the same way you would on your platform, for example, hold down the Shift key as you choose on Microsoft Windows) and use the context-menu.
  • You can delete all completed processes of a process using the context-menu of the process.

When you are in an emergency situation and you need to delete a great number of old processes to free-up disk space or increase database performance, you can use the process System_RemoveOldJobs. Please do not schedule the process regularly, use keep clauses instead.

Archiving Cleared Events

Keeping all cleared events will eventually fill up the event table of your database and impact the performance of Redwood Server. It is recommended to schedule System_ArchiveEvents at regular intervals. The interval depends on the time you want to keep cleared events for easy access to history data and the number of events that get raised and cleared. Ideally, try to keep the number of events below 10 000; fewer is even better. This number takes the minimum recommended maximum heap of the JVM into account; if you have a powerful server with a large maximum heap of the JVM you can keep over 1 000 000, however, smaller is always better.

tip

If you have a large number of events, the System_ArchiveEvents process definition can potentially fail; in this case you should use the parameters to archive very old events first and progressively archive the rest until you are happy with the result. Don't forget to submit the process with a regular schedule; ideally using the desired age of events; use the desired age of events for the schedule as well.

Deleting Old Operator Messages

Operator messages can accumulate over time, especially if you make heavy use of operator messages. The central Redwood Server also generates operator messages for system downtimes which cause process servers to lose connection with the physical servers, for example. These potentially cause the operator messages overview to slow down. It is therefore recommended to schedule a process regularly to remove old operator messages. Schedule the System_RemoveOperatorMessages process to periodically remove old operators, for example, operator messages older than 3 months with a monthly submit frame.

Database Housekeeping

Redwood Server makes heavy use of the database and constantly performs modifications to the database, creating and dropping records. This means that you must closely monitor the filesystem space used by your database and pay attention to fragmentation of database files, tablespaces, and other means of filesystem space allocation used by database objects. Regardless of your database flavor (Microsoft SQL Server, DB2, Oracle ...) your database must be administrated by an experienced DBA.

The Monitoring tree by default monitors some database-related statistics, like number of records and delta number of records. The monitoring section of the documentation also contains an example of how to monitor Oracle database processes. You can build on that to create your database flavor-specific monitoring module.

Cleaning Ghost Records up on MS SQL Server and SAP/Sybase ASE Databases

Customers using a great number of processes with many parameters and short keep clauses can experience the build-up of ghost records in the indexes on JCS_JOBPARAMETER0. This can slow-down the system and use up a tremendous amount of space. If you cannot reduce the number of parameters, you will have to rebuild the indexes regularly on that table; the frequency depends on the volume of parameters.

SQL Server

You schedule a rebuild of the indexes at regular intervals, using the following commands, for example:

ALTER INDEX PK__JCS_JOBP__D9CE5306737017C0 ON JCS_JOBPARAMETER0 REBUILD
ALTER INDEX JCS_JOBPARAMETER00 ON JCS_JOBPARAMETER0 REBUILD
ALTER INDEX JCS_JOBPARAMETER01 ON JCS_JOBPARAMETER0 REBUILD

SAP/Sybase ASE

On Sybase, you can use the following syntax:

reorg rebuild JCS_JOBPARAMETER0 PK__JCS_JOBP__D9CE5306737017C0
note

Please check the names of the indexes in your database.

See Also

← Managing Output FormatsMigrating Objects with the Promotion Module →