Identify Abnormal Process
The Enterprise Server Processes page is used to identify abnormal processes through evaluating kernel-level data.
These are the navigation steps to access the enterprise server process page:
Select the enterprise server instance in server manager.
You should see the <EnterpriseOne Enterprise Server> instance.
Make sure that the server is up and running.
Go to the <Runtime Metrics> section.
Click on the <Process Detail> link.
You should see the <Enterprise server Processes> page.
The enterprise server process has the following sections:
Process and Batch Summary (not modified).
Resource Charts – Top EnterpriseOne Processes (New).
Processes (modified).
This page has a new section called Resource Charts - Top EnterpriseOne Processes and a modified section called Process List. The enterprise server process detail page will have the top ten individual processes for percent CPU usage and memory usage (in MB) designated in graph format. The top ten processes are chosen from all currently running EnterpriseOne Server processes. The time-frame of the data collected will be indicated along the x-axis of the graphs. How much data is represented will depend on when the Server Manager Console services were started and the collection intervals for the monitors that were specified (refer to Configuration Setup).
This graph enables the administrator to visually determine which process to troubleshoot, by providing an easy reference for the top memory or CPU consuming processes. The Process ID can be identified and then used to identify the process entry in the table in the Process List section to access more detail.
Next on this page is a table of all Enterprise Server processes. Six columns have been added to this table that can be sorted on. This is the Process List section:
The columns in the Process List are:
Field |
Description |
|---|---|
Process Name |
The name of the kernel process. The name indicates which kernel definition the kernel belongs to. |
Process Type |
The description of the Enterprise Server process type. |
Process ID |
The operating system assigned process identifier for the kernel process. |
Process Status |
The current state of the processes. May be RUNNING, STOPPED, or ZOMBIE. |
JDE Log File Size |
The size of the error log file commonly referred to as jde.log for the enterprise server process. The size is specified in bytes. |
Debug Log Size |
The size of the debug log file commonly referred to as jdedebug.log for the enterprise server process. The size is specified in bytes. |
Connected Users |
The number of users that are currently connected to this kernel. This is applicable to security and callobject kernels only; other kernels do not maintain persistent connections with a particular user. |
Total Requests |
The total number of JDENET messages that have been processed by the process. |
Outstanding Requests |
The number of JDENET messages 9requests) that are queued up for the kernel process. |
Memory (MB)* (applies to all E1 processes) |
The virtual memory usage in megabytes for the process. An increase in this value over time could indicate a leak that needs to be analyzed. |
CPU %* (applies to all E1 processes) |
The amount of %CPU consumed by EnterpriseOne server process. The %CPU is reported directly for SUN and HP platform and is a calculated value in WINDOWS, IBM i, AIX and LINUX platform. For example, on a 4-processor machine, a process using all of 1 CPU might be reported as using 25% or 100%. |
Threads* (applies to all E1 processes) |
The number of OS threads stared in the EnterpriseOne server process including any Java threads if the process loads a JDEJVM. |
JDE Caches* (does not apply to jdenet_n processes) |
The cache count for the process. This is the total number of JDE Caches in the EnterpriseOne server process which are opened by calling jdeCacheInit API. These caches are generally created by EnterpriseOne Business Functions. They are necessary for Business Functions to do their work. But an increase in this value over time could indicate a leak that needs to be analyzed. The application developer should call jdeCacheTerminate API in business function code to fix the JDECache leak. |
Total Open JDB Transactions* (does not apply to jdenet_n processes) |
The total number of open JDB transactions which includes both AUTO and MANUAL transaction. This resource is opened by calling JDB_InitUser API which is either called with JDEDB_COMMIT_AUTO or JDEDEB_COMMIT_MANUAL. An increase in this value over time could indicate a leak that needs to be analyzed. The application developer should call JDB_FreeUser API in business function code to fix the JDB Transactions leak. |
Manual Open JDB Transactions* (does not apply to jdenet_n processes) |
The number of MANUAL open JDB transactions are opened by calling JDB_InitUser API with JDEDEB_COMMIT_MANUAL. The number of manual open JDB transactions is directly linked with manual-commit database connections. This number should be zero in a normal environment. If this number is growing then it may result in database connection leaks and may cause the enterprise database to reach the maximum number of connections which will bring the entire EnterpriseOne environment (enterprise server and JAS servers) to a halt and consequently no EnterpriseOne user can get their work done. The application developer should call JDB_FreeUser API in business function code to fix the JDB Transactions leak. |
Database Connections** |
The total number of open Database Connections includes AUTOcommit, Select For Update (SFU) and MANUAL-commit connections. An increase in this value over time could indicate a leak that needs to be analyzed. The AUTO and SFU connections have a small maximum limit whereas the MANUAL commit connections have no limit and can grow really high and will eventually hit the maximum global connections available in the database server. The manual commit open Database Connections are tied with the number of open manual commit jdb transactions. The next step should be to capture Memory Diagnostics or All Diagnostics from the server manager process detail page. The JDB transactions for different user sessions logged in the process should be reviewed and all of the open manual JDB transactions should be reviewed for a suspect where the apps BSFN code or tools code has called JDB_InitUser with MANUAL COMMIT MODE but has not called the JDB_FreeUser. The JDB transactions has the file name, line number and function name which should help the developer to locate the code faster and review if the specific code does not call JDB_FreeUser at all or does not call when the code returns with an error or exception path. |
JDE Cache Records** |
This is the total number of JDE Cache Records in the EnterpriseOne server process for the specific user which is created by calling the jdeCacheAdd API, for example. These cache records are generally created by EnterpriseOne Business Functions. They are necessary for Business Functions to do their work. But an increase in this value over time could indicate a leak that needs to be analyzed. The application developer should call the jdeCacheDelete (to delete cache records) or jdeCacheTerminate (to remove the entire cache) API in business function code to fix the JDE Cache Record leak. |
All of the columns in the table are sortable. To sort rows in the table based on a particular column, simply click the column header. Clicking the column header again will sort the rows in the table in the reverse order. Using the sort capability, the administrator can identify EnterpriseOne Server processes that are using an "abnormal" amount of memory, CPU, JDE caches, or open JDB transactions (manual-commit OR total).
If there is a process that the administrator wants to analyze in more detail, they should click on the link for the process (in the "Process Name" column) to be taken to the Individual Process page.