SystemMonitorService -(systemMonitor-SystemMonitorService)

You can use the service when developing applications to make sure that there are sufficient resources to maintain your application over time. The information obtained from this service can, in some cases, be translated to histories for tracking over time and can cause the generation of alarms to monitor specific error conditions or limits.

Using the System Monitor Service is not recommended in every production environment since it consumes resources (in the form of histories and heap memory). Instead, it is best used on a single device in a population as a sample. It can be useful for confirming memory leaks on a platform where you suspect one might exist, or to determine high water marks for the NRE Configuration.

To access, expand Config > Services and double-click SystemMonitorService.

This service and the monitors it provides are mostly implemented in Java and can be used on both Supervisor and controller platforms, both Niagara products and Niagara Portability Software Development Kit (NPSDK) products. However, theSocket State Monitor is used specifically with Tridium JACE devices. The RAM Disk Monitor is only for embedded devices that uses a RAM disk for alarm and history records. The Socket State Monitor is further specific to the Tridium JACE since it is tied to the netstat, an application that is only available through the Tridium spy.

While these monitors are valid for Supervisors, they are probably of lesser value in those environments since resources on Supervisor platforms are expected to exist in abundance. For example, it might be of little value to monitor something like the System Memory on a Supervisor platform because it may have multiple gigabytes of space. However, you can elect to monitor this if you choose.

The System Monitor Service may be of particular value in any embedded controller, including third-party controllers, that elect to use the NRE Configuration View, to control the size of various memory pools.

When dealing with the pools defined here, space not actually used is space wasted. If you can use the associated monitor (that is., Heap Memory Monitor, Meta Space Memory Monitor, Code Cache Memory Monitor or RAM Disk Monitor) to determine that you are not actually using the amount of space you reserved, then you can confidently lower that pool’s size as a means of providing memory for another pool. For instance, if the Meta Space Memory Monitor shows the allotted memory is only half used in a long running station, then you can safely reduce the size of that pool to free up memory for the Heap Space or System Reserve.

For more details, see documentation that is in the NPSDK.

• Java Heap Space is used to allocate memory and store references for new Java Objects. Heap Space size requirements will increase with the number of components in a station.

• Java Meta Space stores class and method data, static variable data, and other internal Java Virtual Machine metadata. Meta Space size requirements typically increase as more modules are installed on a platform.

• Java Code Cache is used to store native code produced by the Java VM Just In Time (JIT) Compiler. Increasing Code Cache may improve the performance of your station but may risk exhausting other memory pools.

• RAM Disk stores station alarm and history data. RAM Disk size requirements increase with the number of history and alarm records in a station.

• System Reserve is used to reserve system memory for background system services that otherwise would be consumed by the Niagara Runtime Environment. Increasing the System Reserve can promote overall system stability.

When added to station Services, the System Monitor Service is enabled by default. For any of the monitors provided by the service, there is no enabled state. The monitors are either present and collecting or absent. If you do not wish to monitor a particular pool, delete the corresponding monitor from the service.

In general, configurable properties for any monitor are context specific to the monitor and self-explanatory. Exceptions are the Generate Alarm and Log Memory to History properties, which are described in the following sections.

For any monitor that supports limit properties like Minimum System Memory Limit (System Memory Monitor) or Minimum Heap Memory Limit (Heap Memory Monitor), the Generate Alarm boolean indicates that an alarm should generate when this limit is crossed. For example, if Free Heap Memory were to drop below 512K (or other specified number) when polled, an alarm should be generated to indicate that the event occurred.

The generated alarm uses the relevant alarm information (Alarm Source Info, etc.) associated with any particular monitor.

The Generate Alarm action for the different monitors works as follows:

• Platform Monitor – causes an alarm if the 3011 port is no longer responding to traffic (that is, the Niagara daemon has exited or is frozen)

• System Memory Monitor – causes an alarm to fire if the Free System Memory drops below the specified limit.

• Heap Memory Monitor – causes an alarm to fire if the Free Heap Memory drops below the specified limit.

• Metaspace Memory Monitor – is not used

• Loaded Classes Monitor – is not used

• CPU Idle Cycles Monitor – is not used

• CPU Used Cycles Monitor – is not used

• Code Cache Memory Monitor – is not used

• RAM Disk Monitor – causes an alarm to fire if the RAM disk’s freespace falls below 5%.

• Socket State Monitor – causes an alarm to fire if the monitor detects any socket from the spy:/platform diagnostics/netstat -A to be in the CLOSE_WAIT state. This is only valid for Tridium JACEs.

The history for any particular monitor follows the rules as defined in the monitor’s History Config, allowing you to configure retention policies, capacity, tags, etc., as with any history extension. The intervals of these configs should be kept at the default so that the history is always generated as a consequence of theCheck System action.

The Log Memory to History action for the different monitors works as follows:

• Platform Monitor – is not implemented

• System Memory Monitor – trends Free System Memory for each fire of the System Check Time Trigger.

• Heap Memory Monitor – trends Free Heap Memory.

• Metaspace Memory Monitor – trends Used Metaspace Memory.

• Loaded Classes Monitor – trends Java Classes loaded.

• CPU Idle Cycles Monitor – trends Idle CPU Cycles over the last collection period.

• CPU Used Cycles Monitor – trends Used CPU Cycles over the last collection period.

• Code Cache Memory Monitor – trends Used Code Cache Memory.

• RAM Disk Monitor – trends Used RAM Disk Space.

• Socket State Monitor – is not implemented