Precise Application Performance Platform 10.3.x

Page History

Versions Compared

Old Version 5

changes.mady.by.user Nadja Pollard

Saved on Jan 26, 2015

compared with

New Version Current

changes.mady.by.user Nadja Pollard

Saved on Mar 21, 2021

Key

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

...

Anchor
AbouttheTierentity
AbouttheTierentity
About the Tier entity

...

For an explanation on how to define instance groups, see the Precise Installation Guide. The table below describes the information displayed in the Instance Grouping table.

Table 8- 1 Instance Grouping table

Item	Description
Group	Displays the name of the group.
Instances	Displays the number of instances linked to the group.
Engine Utilization	Displays the average Engine Utilization for the instances in the specified group.
Committed Transactions	Displays the SUM number of Committed Transactions for the instances in the specified group.
Connections Opened (Sum)	Displays the sum of opened connections for the instances in the specified group.

About viewing instances associated with an Tier in the Association area

Displays information on the Instances associated with the selected Tier in the Association area. The table below describes the information displayed in the tabs in the Association area.

Table 8- 2 Viewing information on associated instances

Tab	Description
Overview	Displays counters reporting on CPU Usage, Memory Usage and amount of Locked Data.
Network	Displays counters reporting on the number of times an engine polls incoming and outgoing packets and bytes.
Disk I/O	Displays various counters reporting on the amount of disk I/O.
Transactions	Displays counters reporting on the number of rows changed in the instance, grouped by type (insert, update, and delete).

Anchor
AbouttheInstanceentity
AbouttheInstanceentity
About the Instance entity

...

The Replication Inbound view is a combination of a few predefined graphs related to the inbound processing phase (replication agent); the view helps you identify what may be causing the latency in the replication system. The information displayed in the Instance level is a summation of all the replicated databases of the instance.

Table 8- 3 I/O vs Cmds Sent

Graph	Description
IO vs. Cmds Sent	Highlights The IO vs. Cmds Sent graph shows the number of commands processed by the RepAgent during the given period and the amount of time the RepAgent had to wait while writing to the inbound queue. Each bar represents a time period. The speed of the RepAgent is directly proportional to the speed of ASE processing the network that sends requests coupled with the speed of the Replication Server processing. What to do next If the amount of I/O wait is significant (compared to the total time each bar represents), then the specific issue delaying the RepAgent must be isolated. The amount of time a RepAgent will have to wait while writing to the inbound queue depends on how much cache is available (exec_sqm_write_request_limit) as well as the values for init_sqm_write_delay/init_sqm_write_max_delay. For more information, check the online help available on the Sybase Web site. If you see a shift in the trend of the Cmds Sent (fewer commands are sent even though the activity is the same), then perhaps something has changed in the ASE processing. Examine the Activity tab and see what was the ASE doing at that time and what, if anything, was holding it back.

Graph

Description

IO vs. Cmds Sent

Highlights

The IO vs. Cmds Sent graph shows the number of commands processed by the RepAgent during the given period and the amount of time the RepAgent had to wait while writing to the inbound queue. Each bar represents a time period. The speed of the RepAgent is directly proportional to the speed of ASE processing the network that sends requests coupled with the speed of the Replication Server processing.

What to do next

If the amount of I/O wait is significant (compared to the total time each bar represents), then the specific issue delaying the RepAgent must be isolated. The amount of time a RepAgent will have to wait while writing to the inbound queue depends on how much cache is available (exec_sqm_write_request_limit) as well as the values for init_sqm_write_delay/init_sqm_write_max_delay. For more information, check the online help available on the Sybase Web site.
If you see a shift in the trend of the Cmds Sent (fewer commands are sent even though the activity is the same), then perhaps something has changed in the ASE processing. Examine the Activity tab and see what was the ASE doing at that time and what, if anything, was holding it back.

Table 8- 4 Truncation Point Movement

Graph	Description
Truncation Point Movement	Highlights The Truncation Point Movement graph shows the number of times the RepAgent has asked the RS for a new secondary truncation point and then moved the secondary truncation point in the log. If 'Moved' is more than one less than 'Gotten', the likely cause is that a large or open transaction exists from the Replication Server perspective (either it is indeed still open in ASE or the RepAgent has not forwarded the commit record yet). What to do next Check for an open transaction in ASE. To determine if the numbers are high - you can gauge the number by dividing the 'Replicated Log Records' (which can be seen in the Log Scan Summary graph) by the RepAgent 'scan_batch_size' configuration parameter and add one to count for the additional move when it reaches the end of the log. The number should be close to what is shown.

Graph

Description

Truncation Point Movement

Highlights

The Truncation Point Movement graph shows the number of times the RepAgent has asked the RS for a new secondary truncation point and then moved the secondary truncation point in the log. If 'Moved' is more than one less than 'Gotten', the likely cause is that a large or open transaction exists from the Replication Server perspective (either it is indeed still open in ASE or the RepAgent has not forwarded the commit record yet).

What to do next

Check for an open transaction in ASE.
To determine if the numbers are high - you can gauge the number by dividing the 'Replicated Log Records' (which can be seen in the Log Scan Summary graph) by the RepAgent 'scan_batch_size' configuration parameter and add one to count for the additional move when it reaches the end of the log. The number should be close to what is shown.

Table 8- 5 Network

Graph	Description
Network	Highlights The Network graph shows information related to the network activity. If the Number of Full Packets is a considerable percentage out of the total package sent (>= 90%), then you may need to consider increasing the send_buffer_size. What to do next Examine the send_buffer_size configuration parameters in the Objects tab.

Graph

Description

Network

Highlights

The Network graph shows information related to the network activity. If the Number of Full Packets is a considerable percentage out of the total package sent (>= 90%), then you may need to consider increasing the send_buffer_size.

What to do next

Examine the send_buffer_size configuration parameters in the Objects tab.

Table 8- 6 Log Scan Summary

Graph	Description
Log Scan Summary	Highlights The Log Scan Summary graph is an indicator of how much work the RepAgent is doing and how much information is being sent to the Replication Server. Replicated log records are records converted into LTL and sent to the RS. Not replicated log records are all log records that were scanned but not sent. What to do next If the replicated log records number is small compared to the total log records scanned, it means that most of the transactions in the log are not aimed for replication — so a large part of the log is scanned needlessly. Consider moving the few tables that need to be replicated to another database so that the total log records scanned will be smaller.

Graph

Description

Log Scan Summary

Highlights

The Log Scan Summary graph is an indicator of how much work the RepAgent is doing and how much information is being sent to the Replication Server. Replicated log records are records converted into LTL and sent to the RS. Not replicated log records are all log records that were scanned but not sent.

What to do next

If the replicated log records number is small compared to the total log records scanned, it means that most of the transactions in the log are not aimed for replication — so a large part of the log is scanned needlessly. Consider moving the few tables that need to be replicated to another database so that the total log records scanned will be smaller.

Table 8- 7 Replicated Commands Breakdown

Graph	Description
Replicated Commands Breakdown	Highlights The Replicated Commands Breakdown lists the number and type of commands that were replicated and which most affect the replication. DDL. Refers to DDL statements that were replicated. Generally this number should be zero, with only minor increases in a Warm Standby when DDL changes are made. Writetext. Shows how many Writetext operations are being replicated. DML with Text/Image. Displays how many row images are processed. What to do next If a large number of text rows are being replicated, you may want to investigate whether a text/image column was inappropriately marked or left at "always_replicate" instead of "replicate_if_changed".

Graph

Description

Replicated Commands Breakdown

Highlights

The Replicated Commands Breakdown lists the number and type of commands that were replicated and which most affect the replication.

DDL. Refers to DDL statements that were replicated. Generally this number should be zero, with only minor increases in a Warm Standby when DDL changes are made.
Writetext. Shows how many Writetext operations are being replicated.
DML with Text/Image. Displays how many row images are processed.

What to do next

If a large number of text rows are being replicated, you may want to investigate whether a text/image column was inappropriately marked or left at "always_replicate" instead of "replicate_if_changed".

About viewing Replication Outbound view graphs

The Replication Outbound view graphs view is a combination of a few predefined graphs related to the outbound processing phase. This enables you to understand what specific component(s) may be causing the latency in the replication system. The information displayed in the instance level is a summation of all the outbound processing performed for the specified instance by all the Replication servers attached to it.

Table 8- 8 SQM Processing

Graph	Description
SQM Processing	Highlights The SQM Processing graph shows the space usage of SQM queue overtime versus the number of commands written to the queue. The SQM Commands Written indicates the amount of activity performed by the replication server. What to do next Check the percentage used of the SQM and see if it is sufficient, over-allocated, or near maximum space capacity to accommodate the written commands. Examine the trend of written commands, with special attention to trend changes. Is the activity evenly distributed, or does it peak at certain times? A deviation from normal trends can be acceptable, but it may also indicate a replication activity that is unauthorized or poorly defined. If the number of commands are lower, then maybe there is a problem in inbound queue processing or in the network. Check the replication inbound statistics. If the amount of free space is lower and there is no change in the number of written commands, this may indicate that the subscriber was unable to apply the transaction. For example, an insert statement may have failed because of a duplicate key. If this example occurs, the truncation point will indicate this failed transaction and will not proceed until it is cleared manually.

Graph

Description

SQM Processing

Highlights

The SQM Processing graph shows the space usage of SQM queue overtime versus the number of commands written to the queue. The SQM Commands Written indicates the amount of activity performed by the replication server.

What to do next

Check the percentage used of the SQM and see if it is sufficient, over-allocated, or near maximum space capacity to accommodate the written commands.
Examine the trend of written commands, with special attention to trend changes. Is the activity evenly distributed, or does it peak at certain times? A deviation from normal trends can be acceptable, but it may also indicate a replication activity that is unauthorized or poorly defined.
If the number of commands are lower, then maybe there is a problem in inbound queue processing or in the network. Check the replication inbound statistics.
If the amount of free space is lower and there is no change in the number of written commands, this may indicate that the subscriber was unable to apply the transaction. For example, an insert statement may have failed because of a duplicate key. If this example occurs, the truncation point will indicate this failed transaction and will not proceed until it is cleared manually.

Table 8- 9 DSI SQT Processing

Graph	Description
DSI SQT Processing	Highlights The DSI SQT Processing graph shows space usage of the outbound queue cache. The Cache size lists the size of the SQT cache. Cached Used shows SQT thread memory usage over time. Each command structure (allocated by an SQT thread) is freed when its transaction context is removed. Consequently, if no transactions are active in SQT, then SQT cache usage is zero. If Cached Used is near the maximum cache size capacity and Trans Removed is constantly greater than zero, you may decide to increase the SQT cache size by increasing dsi_sqt_max_cache_size. Don’t increase the cache size if Trans Removed is occasionally greater than zero; this situation usually means that a transaction was removed from the cache because it was greater than the dsi_sqt_ max_cache_size. For occasional increases of Trans Removed, increasing the cache size will have the opposite effect because the latency in processing transactions ahead of them will likely result in their being removed. The SQM Read Cached indicates how many 16K blocks of cache were read by the SQM Reader thread. This number should be as high as possible. If it is constantly hitting zero, most likely there is a latency in executing the SQL at the replicate; resulting in the DSI SQT cache to reach its maximum. What to do next If Cached Used is near the maximum cache size capacity and Trans Removed is constantly greater than zero, you may decide to increase the SQT cache size by increasing dsi_sqt_max_cache_size. For occasional increases of Trans Removed, increasing the cache size will have the opposite effect because the latency in processing transactions ahead of them will likely result in their being removed. Examine dsi_sqt_max_cache_size and sqt_max_cache_size. The sqt_max_cache_size should usually be between 4-8 MB. For non-parallel DSI configuration and no Warm StandBy, the dsi_sqt_max_cache_size should be smaller than the sqt_max_cache_size. If set too high (or left at zero as default), the DSI-S thread will continuously try to fill the available DSI SQT cache from the outbound queue - often at the expense of yielding the CPU to the DSI EXEC. Consequently, the optimum size for dsi_sqt_max_cache_size is between 1-2 MB. For Warm StandBy Configurations, the DSI SQT cache should normally be equal to the SQT cache or higher because it is the DSI SQT thread that is actually sorting the transactions into commit order. For parallel DSI configurations, the DSI SQT cache should contain double the dsi_max_xacts_in_group transactions for each DSI EXEC thread. The DSI EXEC thread can effectively process many row modifications because the load can be distributed among several available DSIs. This can result in a situation where the DSI transaction rate is higher than the amount of rows read from the outbound queue. In these situations, raising the DSI SQT cache allows the DSI to “read ahead” into the queue and begin preparing transactions before they are needed.

Graph

Description

DSI SQT Processing

Highlights

The DSI SQT Processing graph shows space usage of the outbound queue cache.

The Cache size lists the size of the SQT cache. Cached Used shows SQT thread memory usage over time. Each command structure (allocated by an SQT thread) is freed when its transaction context is removed. Consequently, if no transactions are active in SQT, then SQT cache usage is zero.

If Cached Used is near the maximum cache size capacity and Trans Removed is constantly greater than zero, you may decide to increase the SQT cache size by increasing dsi_sqt_max_cache_size.

Don’t increase the cache size if Trans Removed is occasionally greater than zero; this situation usually means that a transaction was removed from the cache because it was greater than the dsi_sqt_ max_cache_size. For occasional increases of Trans Removed, increasing the cache size will have the opposite effect because the latency in processing transactions ahead of them will likely result in their being removed.

The SQM Read Cached indicates how many 16K blocks of cache were read by the SQM Reader thread. This number should be as high as possible. If it is constantly hitting zero, most likely there is a latency in executing the SQL at the replicate; resulting in the DSI SQT cache to reach its maximum.

What to do next

If Cached Used is near the maximum cache size capacity and Trans Removed is constantly greater than zero, you may decide to increase the SQT cache size by increasing dsi_sqt_max_cache_size.
For occasional increases of Trans Removed, increasing the cache size will have the opposite effect because the latency in processing transactions ahead of them will likely result in their being removed.
Examine dsi_sqt_max_cache_size and sqt_max_cache_size. The sqt_max_cache_size should usually be between 4-8 MB. For non-parallel DSI configuration and no Warm StandBy, the dsi_sqt_max_cache_size should be smaller than the sqt_max_cache_size. If set too high (or left at zero as default), the DSI-S thread will continuously try to fill the available DSI SQT cache from the outbound queue - often at the expense of yielding the CPU to the DSI EXEC. Consequently, the optimum size for dsi_sqt_max_cache_size is between 1-2 MB.
For Warm StandBy Configurations, the DSI SQT cache should normally be equal to the SQT cache or higher because it is the DSI SQT thread that is actually sorting the transactions into commit order.
For parallel DSI configurations, the DSI SQT cache should contain double the dsi_max_xacts_in_group transactions for each DSI EXEC thread. The DSI EXEC thread can effectively process many row modifications because the load can be distributed among several available DSIs. This can result in a situation where the DSI transaction rate is higher than the amount of rows read from the outbound queue. In these situations, raising the DSI SQT cache allows the DSI to “read ahead” into the queue and begin preparing transactions before they are needed.

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.

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 Commands Applied

Graph	Description
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).

Graph

Description

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).

Anchor
AbouttheEngineentity
AbouttheEngineentity
About the Engine entity

...

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

Overview
Semaphores

About getting an overview on a Device activity

The Overview displays an overtime graph, which represents Page Requests (read and write) of the device. The following information is displayed:

Page

...

Requests. Displays the number of pages read synchronous or asynchronous and the number of pages that are written.

About viewing Semaphores

The Semaphores view displays an overtime graph, which represents Semaphore Hits and Misses. The following information is displayed:Semaphores Displays

Semaphores. Displays the number of times that a request for a device semaphore was granted immediately and the number of times the semaphore was busy and the task had to wait for the semaphore to be released.

Anchor
AbouttheDataCacheentity
AbouttheDataCacheentity
About the Data Cache entity

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

Overview
Cache details

About getting an overview on Data Cache activity

The Overview displays statistics that report on the Data Cache Hit Ratio and Utilization. The following information is displayed:

Hit

...

Ratio. Displays the percentage of time a requested page was found in a cache and was found in the wash area.

...

Utilization. Displays the percentage of searches using this cache, as a percentage of searches across all caches.

About viewing Cache Details

The Cache Details view displays statistics that report on the Data Cache Buffer Wash (Pages) and large I/Os. The following information is displayed:

Buffer Wash (Pages)

...

. Displays the number of buffers that were clean when they passed the wash marker, the number of times that I/O was already active on a buffer when entered the wash area, and the number of times that a buffer entered the wash area dirty and was not already in I/O.
Large I/

...

O. Displays the number of times a large I/O was requested for a buffer and the number of times it was denied.

Anchor
AboutthePerformanceCounterorCounterInstanceentity
AboutthePerformanceCounterorCounterInstanceentity
About the Performance Counter or Counter Instance entity

The Performance counter or Counter Instance entity displays statistical information on the selected counter. Precise for Sybase collects counters reported by Sybase. These counters determine which aspects of the objects to monitor. For example, the Sybase Memory Object contains the Mempages_alloced counter.

The Overview displays general details of the selected counter and overtime graph, which represent the counter value. In some of the selected counters, two overtime graphs are displayed: a graph that displays the number of transactions over time and another graph that displays the counter value per committed transaction.

Anchor
AbouttheWaitEventsentity
AbouttheWaitEventsentity
About the Wait Events entity

Available for Sybase versions 12.5.0.3 and higher, the Wait Events entity displays the name of the wait event group, the number of waits experienced by this event group and the summed amount of time accumulated by wait events and summed occurrences.

The following view is displayed:

Overview

About getting an overview of Wait Events

The Overview displays general details of the selected counter. The following information is available:

Event

...

group. Displays the name of the wait type.
Event

...

name. Provides a description of what is causing the event.
Time waited (avg)

...

. Average time waited for wait events, over the selected time period.
Times waited

...

graph. Displays the time waited for wait events vs. the time waited for group events.
Wait

...

graphs. Displays the number of wait events vs. the number of wait events for group events.

Anchor
AbouttheReplicationServerentity
AbouttheReplicationServerentity
About the Replication Server entity

The Replication Server entity displays predefined graphs which represent statistics related to the outbound processing phase and inbound (repagent statistics) processing phase for the selected Replication Server in the Selected time frame.

Info

...

The Precise for Sybase Replication server collector agent collects statistics only for the Sybase ASEs which are monitored by Precise and use the specified replication server for replicating data. If the same RS also serves other ASEs that are not monitored by Precise or another RDBMS (such as: Oracle, SQL Server, etc.), the statistics of those instances will not be collected and displayed.

The following views are available:

Replication Inbound
Replication Outbound

See About the Instance entity on page 85.

Anchor
AbouttheReplicatedDatabasesentity
AbouttheReplicatedDatabasesentity
About the Replicate(d) Databases entity

The Replicate(d) databases entity displays predefined graphs which represent statistics related to the outbound processing phase and inbound (repagent statistics) processing phase for the selected database in the Selected time frame.

Info

...

The Precise for Sybase Replication server collector agent collects statistics only for the Sybase ASEs that are monitored by Precise and use the specified replication server for replicating data. If the same RS also serves other ASEs that are not monitored by Precise or another RDBMS (such as: Oracle, SQL Server, etc.), the statistics of those instances will not be collected and displayed.

The following views are available:

Replication Inbound
Replication Outbound

See About the Instance entity on page 85.

Anchor
HowtheStatisticstabcanhelpyouidentifyperformanceproblems
HowtheStatisticstabcanhelpyouidentifyperformanceproblems
How the Statistics tab can help you identify performance problems

...

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

Anchor
ExaminingthekernelutilizationofSybaseovertime
ExaminingthekernelutilizationofSybaseovertime
Examining the kernel utilization of Sybase over time

You can examine a Sybase instance over time to confirm that the amount of Sybase engines configured in your system is optimal.

...

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

Table 8- 12 Utilization status

Engine Busy	CPU Yields	Status
Low	Low	Engine is CPU starved
Low	High	Engine is inactive
High	Low	Engine is busy
High	High	Engine 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.

...

If the sample includes idle time, or the I/O traffic is "bursty," , it is possible that a high percentage of the checks were returning I/O during the busy period. If the results in this category seem low or high, you can configure the frequency of the checks.

Increasing the amount of time that Adaptive Server engines wait between checks may result in better throughput, because Adaptive Server engines can spend more time processing if they spend less time checking for I/O.

Anchor
ExaminingIOstatistics
ExaminingIOstatistics
Examining I/O statistics

To examine I/O statistics

...

You can also use this information to check I/O distribution patterns over the disks and to make object placement decisions that can help balance Disk I/O across devices. For example, does the data show that some disks are more heavily used than others? If you see that a large percentage of all I/O went to a specifically named device, you can investigate the tables residing on the device and then determine how to remedy the problem.

Anchor
Examiningnetworkactivity
Examiningnetworkactivity
Examining network activity

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:

...

Switch to the Network view.
Check the ratio between the Packets graph and the Bytes graph to see if the network packet size is used to its maximum capacity.
Consider configuring its size.

Anchor
Examiningmemorybottlenecks
Examiningmemorybottlenecks
Examining memory bottlenecks

Lack of memory or a high memory consumption rate can cause paging. A page fault occurs when a process requires code or data that is not in its working set (its space in physical memory), thereby causing the page to be retrieved from disk and written to the physical memory. If there is not enough space in the physical memory, a chosen page needs to be written to disk to free space.

...

Examine the Memory view that reports the number of pages allocated and deallocated in each time slice.
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.
Switch to the Memory view to see information about the success and failure of Memory Requests for Worker Processed in the Memory Requests graph.
If some of the requests have failed you may need to increase the value of the Memory per Worker Process parameter.
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.
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.

Anchor
Examiningaspecificcounterovertime
Examiningaspecificcounterovertime
Examining a specific counter over time

A wide range of performance counters generated by Sybase are collected by the Precise for Sybase collect instance statistics process. These performance counters are sampled every 15 minutes and displayed in this tab over time.

A performance group is a Sybase Performance Group resource, such as a Sybase Lock. Each performance group contains a few counters that determine which performance aspects to monitor. For example, the Sybase Memory Performance group contains counters called Pages Allocated (Sybase counter: mempages_alloced) and Pages Released (Sybase counter: mempages_freed).

Some performance counters have separate instances. An instance refers to a particular occurrence of a counter. For example, the Device-Counters Performance group has counters such as Disk Cache Misses (Sybase counter: p_misses) and Disk Cache Hits (Sybase counter: p_hits), but because several devices exist, each counter is divided into instances.

...

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

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

Precise Website	Solutions	Support	Support Portal	Community	About Us	Legal

...

Scroll Ignore

scroll-pdf	true
scroll-office	true
scroll-chm	true
scroll-docbook	true
scroll-eclipsehelp	true
scroll-epub	true
scroll-html	true

Newtabfooter
alias IDERA
url http://www.idera.com
|
Newtabfooter
alias Products
url https://www.idera.com/productssolutions/sqlserver
|
Newtabfooter
alias Purchase
url https://www.idera.com/buynow/onlinestore
|
Newtabfooter
alias Support
url https://idera.secure.force.com/precise/
|
Newtabfooter
alias Community
url http://community.idera.com
|
Newtabfooter
alias Resources
url http://www.idera.com/resourcecentral
|
Newtabfooter
alias About Us
url http://www.idera.com/about/aboutus
|
Newtabfooter
alias Legal
url https://www.idera.com/legal/termsofuse

Content

Space Tools

Versions Compared

Old Version 5

New Version Current

Key

Anchor
AbouttheTierentity
AbouttheTierentity
About the Tier entity

About viewing instances associated with an Tier in the Association area

Anchor
AbouttheInstanceentity
AbouttheInstanceentity
About the Instance entity

About viewing Replication Outbound view graphs

Anchor
AbouttheEngineentity
AbouttheEngineentity
About the Engine entity

About getting an overview on a Device activity

About viewing Semaphores

Anchor
AbouttheDataCacheentity
AbouttheDataCacheentity
About the Data Cache entity

About getting an overview on Data Cache activity

About viewing Cache Details

Anchor
AboutthePerformanceCounterorCounterInstanceentity
AboutthePerformanceCounterorCounterInstanceentity
About the Performance Counter or Counter Instance entity

Anchor
AbouttheWaitEventsentity
AbouttheWaitEventsentity
About the Wait Events entity

About getting an overview of Wait Events

Anchor
AbouttheReplicationServerentity
AbouttheReplicationServerentity
About the Replication Server entity

Anchor
AbouttheReplicatedDatabasesentity
AbouttheReplicatedDatabasesentity
About the Replicate(d) Databases entity

Anchor
HowtheStatisticstabcanhelpyouidentifyperformanceproblems
HowtheStatisticstabcanhelpyouidentifyperformanceproblems
How the Statistics tab can help you identify performance problems

Anchor
ExaminingthekernelutilizationofSybaseovertime
ExaminingthekernelutilizationofSybaseovertime
Examining the kernel utilization of Sybase over time

Anchor
ExaminingIOstatistics
ExaminingIOstatistics
Examining I/O statistics

Anchor
Examiningnetworkactivity
Examiningnetworkactivity
Examining network activity

Anchor
Examiningmemorybottlenecks
Examiningmemorybottlenecks
Examining memory bottlenecks

Anchor
Examiningaspecificcounterovertime
Examiningaspecificcounterovertime
Examining a specific counter over time

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

Content

Space Tools

Page History

Versions Compared

Old Version 5

New Version Current

Key

AnchorAbouttheTierentityAbouttheTierentityAbout the Tier entity

About viewing instances associated with an Tier in the Association area

AnchorAbouttheInstanceentityAbouttheInstanceentityAbout the Instance entity

About viewing Replication Outbound view graphs

AnchorAbouttheEngineentityAbouttheEngineentityAbout the Engine entity

About getting an overview on a Device activity

About viewing Semaphores

AnchorAbouttheDataCacheentityAbouttheDataCacheentityAbout the Data Cache entity

About getting an overview on Data Cache activity

About viewing Cache Details

AnchorAboutthePerformanceCounterorCounterInstanceentityAboutthePerformanceCounterorCounterInstanceentityAbout the Performance Counter or Counter Instance entity

AnchorAbouttheWaitEventsentityAbouttheWaitEventsentityAbout the Wait Events entity

About getting an overview of Wait Events

AnchorAbouttheReplicationServerentityAbouttheReplicationServerentityAbout the Replication Server entity

AnchorAbouttheReplicatedDatabasesentityAbouttheReplicatedDatabasesentityAbout the Replicate(d) Databases entity

AnchorHowtheStatisticstabcanhelpyouidentifyperformanceproblemsHowtheStatisticstabcanhelpyouidentifyperformanceproblemsHow the Statistics tab can help you identify performance problems

AnchorExaminingthekernelutilizationofSybaseovertimeExaminingthekernelutilizationofSybaseovertimeExamining the kernel utilization of Sybase over time

AnchorExaminingIOstatisticsExaminingIOstatisticsExamining I/O statistics

AnchorExaminingnetworkactivityExaminingnetworkactivityExamining network activity

AnchorExaminingmemorybottlenecksExaminingmemorybottlenecksExamining memory bottlenecks

AnchorExaminingaspecificcounterovertimeExaminingaspecificcounterovertimeExamining a specific counter over time

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

Anchor
AbouttheTierentity
AbouttheTierentity
About the Tier entity

Anchor
AbouttheInstanceentity
AbouttheInstanceentity
About the Instance entity

Anchor
AbouttheEngineentity
AbouttheEngineentity
About the Engine entity

Anchor
AbouttheDataCacheentity
AbouttheDataCacheentity
About the Data Cache entity

Anchor
AboutthePerformanceCounterorCounterInstanceentity
AboutthePerformanceCounterorCounterInstanceentity
About the Performance Counter or Counter Instance entity

Anchor
AbouttheWaitEventsentity
AbouttheWaitEventsentity
About the Wait Events entity

Anchor
AbouttheReplicationServerentity
AbouttheReplicationServerentity
About the Replication Server entity

Anchor
AbouttheReplicatedDatabasesentity
AbouttheReplicatedDatabasesentity
About the Replicate(d) Databases entity

Anchor
HowtheStatisticstabcanhelpyouidentifyperformanceproblems
HowtheStatisticstabcanhelpyouidentifyperformanceproblems
How the Statistics tab can help you identify performance problems

Anchor
ExaminingthekernelutilizationofSybaseovertime
ExaminingthekernelutilizationofSybaseovertime
Examining the kernel utilization of Sybase over time

Anchor
ExaminingIOstatistics
ExaminingIOstatistics
Examining I/O statistics

Anchor
Examiningnetworkactivity
Examiningnetworkactivity
Examining network activity

Anchor
Examiningmemorybottlenecks
Examiningmemorybottlenecks
Examining memory bottlenecks

Anchor
Examiningaspecificcounterovertime
Examiningaspecificcounterovertime
Examining a specific counter over time