Drilling deeper into OpenEdge Management-supplied data

As the checklist items in Table 8–2 indicate, the administrator needs quick access to performance data. In a crisis situation such as this one, the administrator needs to know that the information available to determine, resolve, and learn from the problem situation to minimize—if not eliminate—such a crisis of this kind from reoccurring is accurate and timely.

Accessing and examining AppServer data

The administrator accesses the OpenEdge resources in the OpenEdge Management console, browsing to the AppServer resources. The network uses only one AppServer, thus the administrator can immediately click on either of the AppServer Operational views data—the Server Performance View or Broker Performance View.

Note: For detailed procedures on setting up and accessing AppServer resources, including the AppServer Operational views, see Chapter 4, "Managing AppServer Data."

Scanning alert detail on the collection page and also on individual resources displayed in the list frame, the administrator notices that there are no new alerts displayed.

The administrator then accesses the Database page and scans for relevant information in the Operational views and Informational views sections. Finding no clues related to the issues, the Server Performance View details are displayed next. The server state and server pool summary details that display in this view, however, are not helpful. In this situation, the administrator considers where the most valuable information would be found, and clicks on the Broker Performance View.

Figure 8–4 shows the data that appears in the Broker Performance View for the asbroker.

Note: In the figures presented in this section, the colors in the graphs are intended only to distinguish one data element from another.

Figure 8–4: Broker Performance View for asbroker1

The administrator scans the summarized data in Broker Requests, noting the fact that the total of Queued requests is almost the same as the total number of Rejected requests. At this point, the administrator knows that there is a problem in this area, but still needs to do more research. From the previous use of the data on the Broker Performance View page, the administrator knows that the AS Broker Activity Status graph is a representation of the Queued and Rejected values noted in Broker Requests.

The administrator clicks the binocular icon associated with the AS Broker Activity Status and the AS Broker Activity Status pinup appears, as shown in Figure 8–5.

Figure 8–5: AS Broker Activity Status for asbroker1

The pinup graph in Figure 8–5 focuses on a much smaller time frame for the data, and the data confirms the very poor performance noted on the main Broker Performance View page. In fact, the number of rejected requests really is as high as the number of queued requests. What happened at the time frame indicated on the AS Broker Activity Status to cause this dramatic situation?

The administrator now decides to access the asbroker1's log file, hoping to find more evidence of these same difficulties. Note the several No Servers available and the Clients disconnected error messages in the log, as shown in Figure 8–6.

Note: For the information that the administrator references about accessing the AppServer log file, see the "Accessing and reviewing AppServer-related log file data" section.

Figure 8–6: AppServer asbroker1 log file

At approximately the same time that the number of rejected requests was starting to approach the total number of queued requests, as shown in Figure 8–4, the error log reports that the servers are not available and that connected clients are being disconnected.

The administrator redisplays the Servers Performance View page. All the investigative activities have confirmed that a runaway AppServer process has brought down the network, leaving the users unable to perform their application transaction-related tasks.

Figure 8–7 shows the suspicious data in the CPU Use column, indicating that no CPU consumption is occurring for the servers.

Figure 8–7: Servers Performance View page for asbroker1

Again, by clicking the binocular icon, the administrator can display this data in a pinup, as shown in Figure 8–8.

Figure 8–8: Total Servers CPU for asbroker1

By clicking on PID 2996 as shown in Figure 8–7, the administrator can display the specific PID process ID number that is the problem process. By clicking the Kill button on the Broker process page, the administrator can terminate this process, ending the network and application difficulties.


Copyright © 2008 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095