> #### Drilling deeper into Fathom-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, he needs to know that he has accurate, timely information available to determine, resolve, and learn from the problem situation to minimize—if not eliminate—such a crisis of this kind from reoccurring.

> ##### Accessing and examining AppServer data

> The administrator accesses his OpenEdge resources in the Fathom Management console, browsing to the AppServer resources. His network uses only one AppServer, so he 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 his collection page and also on individual resources he displays in the list frame, he notices that there are no new alerts displayed.

> He then accesses the Database page and scans for relevant information in the Operational views and Informational views sections. Finding no clues related to his issues, he next displays the Server Performance View details; however, the server state and server pool summary details that display in this view are not helpful. In this situation, he considers where he'd find the most valuable information, and he 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 only intended to distinguish one data element from another.

> Figure 8–4: Broker Performance View for asbroker1 on host pcskye

> He quickly scans the summarized data in the 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's a problem in this area, but still needs to do more research. From his previous use of the data on the Broker Performance View page, he knows that the AS Broker Activity Status graph is a representation of the Queued and Rejected values noted in Broker Requests.

> He 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 has 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 as 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.

> It now makes sense to the administrator as he redisplays the Servers Performance View page; all his investigative activities have confirmed that a runaway AppServer process has brought down his network, leaving his users unable to perform their application transaction-related tasks.

> Figure 8–7: Servers Performance View page for asbroker1

> Note the suspicious data in the CPU Use column as shown on the Servers Performance View page in Figure 8–7. This information further indicates that no CPU consumption is occurring for the servers.

> 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, he can terminate this process, ending his network and application difficulties.

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