Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This section includes the following topics:

Anchor
AbouttheStatisticstab
AbouttheStatisticstab
About the Statistics tab

The Statistics tab displays statistical information on all Sybase instances. The tab can be used to monitor your system's historical statistical information.

...

Use the Statistics tab to periodically monitor the health of your system - for example, view the statistics on CPU Utilization or Hit Ratios. Alternatively, you can use the Statistics tab to fully analyze a performance problem reported by the Collector agent.

Info

...

Statistics tab data is based on the results of the statistics counters that are gathered by ASE. These counters are cleared when using sp_sysmon to view statistics counters. If sp_sysmon is run, statistics data gathered by Precise for Sybase will not be complete. This problem can be avoided by not running sp_sysmon or by using the noclear option of sp_sysmon (available in Sybase version 12.5.3 and higher).

Anchor
HowtheStatisticstabisstructured
HowtheStatisticstabisstructured
How the Statistics tab is structured

The Statistics tab displays information on a selected entity and its associated entities. When you open the Statistics tab from the Dashboard tab or the Activity tab, the tab is launched, in-context, and depending upon your selection in the All Sybase Instances table (All or Instance), the information is displayed on the Tier or Instance level. Navigating between these tabs and the Statistics tab will change the chosen time frame. If you open the Statistics tab from another tab, the historical settings (meaning those settings which were selected when you left the tab, such as the last entity you drilled down to) are taken into account and the information displayed the last time you viewed this tab is displayed (similar to clicking the History control and returning to a previous tab).

...

Table 8-10 DSIE Transactions Processing 

Graph

...

Description
DSIE Transactions

...

Processing

Highlights

The DSIE Transactions Processing graph shows how long it took to process a transaction by a DSI/E thread breakdown to various phases.

...

  • FS Map Time

...

  • . The amount of time used to translate the replicated row functions into SQL commands. If a large amount of time is spent in this area, this may indicate that there are relatively large customized function strings; if true, there may not be any options you can take. However, you may want to check that the STS cache is sized appropriately.

...

  • Sent Time

...

  • . This represents the amount of time spent sending the command batch to the replicate data server. A long lag time may indicate inefficient batching, or a slow response to client applications from the replicate server.

...

  • SendRPCTimeAvg. This records the time spent sending RPCs to the RDB.

...

  • SendDTTimeAvg. This records time spent sending LOB data to the RDB.

...

  • Result Time

...

  • . This calculated value can be used to determine the amount of time spent processing results from the replicate server. This value also includes the execution time, because RS does very little result processing. Often, these metrics will be among the highest. You need to speed-up the replicate DBMS to improve the RS throughput.

...

  • Commit Seq. Time

...

  • . The amount of time spent waiting to commit. Here too, a high value may indicate a near-serial dsi-serialization_method, such as wait_for_commit. Alternatively, it may indicate a contention within the replicate server, possibly within the rs_threads_group.

...

  • Batch Seq. Time

...

  • . This is the time spent trying to coordinate the sending of the first batch in parallel DSIs. A long time may indicate that the dsi_serialization_method is wait_for_commit and a previous transaction is running a long time, or that the DSI thread is simply too busy to respond to the Batch Sequencing message.

...

  • Other Time

...

  • . The execution time by the replicate database outside of the replication server.

What to do next

...

  • If Other Time is the largest chunk of time out of the total transaction time, tuning RS will not help.You must do one of the following: tune the replicate database by using parallel DSIs, or use minimal columns/repdefs to reduce the SQL execution time.

...

  • If FS Map Time is high, consider rewriting the queries and simplifying them, or work with a stored procedure.

...

  • If Commit Seq. Time is high, consider lowering the number of parallel threads.

 

Table 8-11    DSIE 11 DSIE Commands Applied

Graph    Description

DSIE Commands Applied    Highlights

...

GraphDescription
DSIE Commands Applied

Highlights

The DSIE Commands Applied graph shows how many commands were successfully applied to the target database by DSI/E overtime (relevant for version 15 and higher). It can be used to measure the amount of work imposed by the replication server. You can also compare that number to the SQM Commands Written and check if there is a lag in processing commands inside the replication server.

What to do next

...

  • Study the trend of applied commands. If it has suddenly dropped, this may indicate a problem in the subscriber ASE.

...

  • Go to the Activity tab and examine the resulting batches from replication (rep server program).

About the Engine entity

The Engine entity displays predefined graphs that shows several counters in one. This enables you to immediately view relevant counters, grouped according to topic.

The following views are available:•    Overview

  • Overview

...

  • Network

...

  • Disk I/O

About getting an overview of CPU yields and engine utilization

...

The Device entity displays predefined graphs that report on device activity and performance. The following views are available:•    Overview

  • Overview

...

  • Semaphores

About getting an overview on a Device activity

...

The Data Cache entity displays predefined graphs that report on the activity of the Data Cache. The following views are available:•    Overview

  • Overview

...

  • Cache details

About getting an overview on Data Cache activity

...

The following view is displayed:

•    Overview

...

  • Overview

About getting an overview of Wait Events

...

The following views are available:•    Replication

  • Replication Inbound

...

  • Replication Outbound

See About the Instance entity on page 85.

...

The following views are available:•    Replication

  • Replication Inbound

...

  • Replication Outbound

See About the Instance entity on page 85.

...

You can identify a performance problem by doing one or more of the following:•    See

  • Examining the kernel utilization of Sybase over time

...

...

  • Examining I/O statistics

...

...

  • Examining network activity

...

...

  • Examining memory bottlenecks

...

...

  • Examining a specific counter over time

...

Examining the kernel utilization of Sybase over time

...

The table below describes what the utilization status of an engine indicates.

Table 8-12    Utilization 12 Utilization status

Engine

...

BusyCPU YieldsStatus
LowLowEngine

...

is CPU starved

...

LowHighEngine is inactive

...

HighLowEngine is busy

...

HighHighEngine is busy

To improve kernel utilization, it is recommended to check the Disk I/O and Network view. This is done to determine if the number of checks for I/O or Network that the engine performs, is ideal or are overhead.

...

To examine I/O statistics1.    Open

  1. Open the Overview view of the specific instance entity.

...

  1. Examine the I/O Wait value in the In Sybase graph to detect bottlenecks within the device subsystem.

...

  1. Check for I/O Pacing and I/O Device Contention values in the Task Context Switches - Reasons graph.

...

  1. If increased I/O Wait is the result of an activity in the instance, open the Activity tab to continue your analysis of the application's performance.

I/O Pacing reports how many times an I/O-intensive task switched off an engine, due to exceeding an I/O batch limit. This limit can be configured.

...

To determine which devices are having possible performance problems, drill down to the Device entity located in the Association area. In the Association area table you can see the Page Requests and the Sum of Semaphores for the different devices. Drilling down to one of the devices will enable you to see these counters over time.

 

In the Page Requests graph you can see the amount of I/O reads and writes.

...

You can examine network traffic over a specified time period to detect bottlenecks. Network performance can be improved by one or more of the following:•    Enhancing

  • Enhancing the application

...

  • Reducing the amount of data returned

...

  • Configuring the network packet size parameter with a reasonable number that avoids many packets from being sent or received (causing overhead)

...

  • Reconfiguring the network configuration

To examine network activity do one of the following1.    Examine

  1. Examine the In Sybase graph and check the Network I/O Wait value.

...

  1. Check the Task Context Switches - Reasons graph to see if Network Packet Sent is a major cause of task switching.

...

  1. If so, check the applications on the problematic instance to see if it's possible to reduce the amount of data returned.

OR1.    Switch

  1. Switch to the Network view.

...

  1. Check the ratio between the Packets graph and the Bytes graph to see if the network packet size is used to its maximum capacity.

...

  1. Consider configuring its size.

Examining memory bottlenecks

...

To examine memory bottlenecks1.    Examine

  1. Examine the Memory view that reports the number of pages allocated and deallocated in each time slice.

...

  1. If you spot a high value in one of the time slices, open the Activity tab to continue your analysis of the application's performance.

...

  1. Switch to the Memory view to see information about the success and failure of Memory Requests for Worker Processed in the Memory Requests graph.

...

  1. If some of the requests have failed you may need to increase the value of the Memory per Worker Process parameter.

...

  1. Switch to Data Cache view to see information on how effective cache design is. A high Hit Ratio from the Hit Ratio graph and small amount of Page Request Misses from the Utilization graph may indicate effective cache design.

...

  1. If you see a low Hit Ratio and a lot of Page Request Misses, investigate statistics for each of the Data Caches by selecting the Data Cache entity in the Association area.

 

Examining a specific counter over time

...

To examine a specific counter1.    Select

  1. Select the associated required performance group from the Associations list.

...

  1. Select the required counter.

...

 

Precise. Performance intelligence from click to storage. Learn more > >

...