Overview of the Netezza Performance Server system processing

When you start the Netezza Performance Server for Cloud Pak for Data and Netezza Performance Server for Cloud Pak for Data System system, you automatically start a number of system processes. The following table describes the Netezza Performance Server processes.

Table 1. Netezza Performance Server processes
Process	Description
bnrmgr	Handles incoming connections from the nzbackup and nzrestore commands. Starts an instance of the backupsvr or restoresvr to handle each client instance.
bootsvr	Informs TFTP client (the SPUs) of the location of their initial program or download images on the host. Informs the SPUs where to upload their core file if a SPU is instructed to create a core image for debugging purposes.
clientmgr	Handles incoming connections from nz applications. This is not unlike the postmaster that handles incoming connections from nzsql, ODBC, and others.
dbosDispatch	Accepts execution plans from the Postgres, backup, and restore process or processes. Dynamically generates C code to process the query, and cross-compiles the query so that it can be run on the host. Broadcasts the compiled code to the SPUs for execution.
dbosEvent	Receives responses and results from the SPUs. As appropriate, it might have the SPUs do more steps as part of the query. Rolls up the individual result sets (aggregated, sorted, consolidated) and sends the final results back to the client's Postgres, backup, or restore process.
eventmgr	Processes events and event rules. When an event occurs, such as the system changes state, a hardware component fails or is restarted, the eventmgr checks to see whether any action must be taken based on the event and if so, it takes action. The action can be sending an email message or running an external program. For more information about event rules, see Event rules.
loadmgr	Handles incoming connections from the nzload command. Starts an instance of the loadsvr to handle each instance of the nzload command.
nzvacuumcat	At boot time, the system starts the nzvacuumcat command, which in turn invokes the internal VACUUM command on system catalogs to remove unneeded rows from system tables and compact disk space to enable faster system table scanning. During system operation, the nzvacuumcat program monitors the amount of host disk space that is used by system tables in each database. It checks every 60 seconds. If the system catalog disk space for a particular database grows over a threshold amount (128 KB), the nzvacuumcat program initiates a system table vacuum (VACUUM) on that database. The VACUUM command works on system tables only after it obtains an exclusive lock on all system catalog tables. If it is unable to lock the system catalog tables, it quits and tries again. Only when the VACUUM command succeeds does the nzvacuumcat program change the size of the database. While the VACUUM command is working, the system prevents any new SQL or system table activity to start. This window of time is usually about 1 to 2 seconds, but can be longer if significant amounts of system catalog updates or deletes have occurred since the last VACUUM operation.
postgres	Validates the access rights (user name, password, ACL). Parses the SQL, and generates the optimized execution plan. Returns the results set to the client application when the query finishes executing. Two default postgres jobs are associated with the sysmgr and the sessionmgr processes.
postmaster	Accepts connection requests from clients (nzsql, ODBC, and other clients). Starts one postgres process per connection to service the client.
sessionmgr	Keeps the session table current with the state of the different sessions that are running the system. For more information, see Session manager.
startupsvr	Launches and then monitors all of the other processes. If any system process dies, startupsvr follows a set of predefined rules, and either restarts the failed process or restarts the entire system. Controlled by /nz/kit/sys/startup.cfg
statsmgr	Handles requests for statistics from the nzstats command. For more information, see Statistics server.
statsSvr	Communicates with the nzstats command to obtain host-side operational statistics. The nzstats command communicates with the sysmgr to obtain SPU statistics.
sysmgr	Monitors and manages the overall state of the system. Periodically polls the SPUs to ensure that they are operational. Initiates state changes upon requests from the user or as a result of a change in hardware status (for example, a SPU failure).