10.案例Sybase分析

 

 

1. 1. Sybase数据库网络性能
      1. 网络性能

如果出现如下症状，那么很可能是网络出现了状态。这些状态主要是摘自Sybase官方文档描述。当然事无绝对，具体最后是不是网络问题还需要我们自己去确诊。

1. 进程响应时间在无明显原因的情况下发生显著变化。
2. 返回大量行的查询所用的时间比预期的要长。
3. 在正常的 SAP ASE 处理期间，操作系统处理速度变慢。
4. 在特定的操作系统处理期间，SAP ASE 处理速度变慢。
5. 某一特定的客户端进程似乎使所有其它进程都变慢。
   1. 1. 问题原因

这个世界没有无缘无故爱也没有无缘无故的恨，任何事情都是有原因的。那么网络性能问题有哪些导致因素呢？可能由网络导致的一些基本问题包括：

1. SAP ASE 的网络服务使用效率低。
2. 已达到了网络的物理限制。
3. 进程检索不需要的数据值，这无谓地增加了网络通信量。
4. 进程过于频繁地打开和关闭连接，从而增加了网络负担。
5. 进程频繁地提交同一 SQL 事务，从而导致网络通信量过多、过剩。
6. SAP ASE 没有足够的网络内存。
7. SAP ASE 网络包大小不够大，无法处理某些客户端所需类型的处理。
8. 当研究与网络有关的问题时，可考虑下列问题：
   1. 1. 哪些进程经常检索大量数据？
      2. 是否发生了大量的网络错误？
      3. 网络的总体性能如何？
      4. 利用 SQL 和存储过程执行的事务有哪些？
      5. 是否有大量进程使用两阶段提交协议？
      6. 是否正在通过网络进行复制服务？
      7. 操作系统正在使用的网络处理有多少？

1. 1. 1. 如何解决呢？

既然有问题，那么肯定是会有问题的解决办法的，官方提供的办法如下。

1. 使用多个网络
2. 对多数数据库活动都使用小包
3. 对进行大量数据传送的任务使用较大的包大小
4. 使用存储过程减少总体通信量
5. 过滤数据以避免大批量的传送
6. 将重网络负荷用户与普通用户隔离
7. 对特殊情况使用客户端控制机制
   1. 1. 诊断准备

那么问题来了，既然知道了现象，原因以及解决办法，我们是不是没有我们的事情了？NO，NO，NO，虽然解决办法这么多，但是我们需要选择哪一个才是关键。这个需要我们针对不同业务进行针对分析才能得到答案的，也是我们性能诊断的关键。

       当然，之前我们还需要了解一些信息的，所谓 工欲善其事，必先利其器。我们先来看下概念。

       首先客户端和服务器之间使用的协议称为 Tabular Data Stream™ (TDS)，它构成了许多 SAP 产品的通信基础。

SAP ASE 包括 I/O 控制器和 I/O 控制器管理器。I/O 控制器发出、跟踪、轮询和完成 I/O。每种 SAP ASE I/O 类型 - 磁盘、网络、Client-Library 以及 CIPC（对于 Cluster Edition）- 都有自己的 I/O 控制器。

SAP ASE 可以包括磁盘或网络控制器的多个实例（不允许多个 CIPC 或 Client-Library 控制器）。每个任务表示一个控制器。例如，配置三个网络任务意味着网络 I/O 使用三个控制器。

SAP ASE 配置的模式决定它如何处理 I/O。在线程化模式（缺省值）中，SAP ASE 对 I/O 使用线程化轮询；在进程模式中，SAP ASE 对 I/O 使用轮询计划程序。

1. 网络监听器

网络监听器任务最大是32个，每创建一个附加的监听器消耗资源和一个用户连接占用的资源相同。Number of user connections配置参数不仅包括网络参数监听器的数目，还包括附加的监听器端口数目。端口数据是取决于interfaces文件的。

1. 进程模式

进程模式中，每个端口使用一个监听器任务。通过从一个引擎切换到另一个来平衡负载，每个监听器都起到多个逻辑监听器的作用。

如果14个引擎，有两个主端口的监听器任务，那么两个监听器任务要充当28个逻辑监听器，这样服务器就具有两个物理监听器和28个逻辑监听器。每个物理监听器负责14个逻辑监听器。

1. 线程模式

在配置为线程化轮询时，控制器管理器为每个控制器指派任务，并将此任务放入 syb_system_pool 中。因为 syb_system_pool 是专用池，所以它创建线程来为每个任务服务。此线程以独占方式为 I/O 控制器运行轮询和完成例程。因为此线程专用于执行此任务，所以此任务可阻止等待 I/O 完成，从而减少了系统呼叫和空轮询的数量。

可以创建多个线程来为每个 I/O 控制器服务，从而可以避免单线程饱和问题，出现此类问题时，单个线程无法保持高 I/O 率。

当 I/O 在操作系统级别上完成时，进程模式轮询引入 I/O 延迟。不过，引擎没有检测到 I/O 延迟，因为引擎正在运行其它任务。线程化模式轮询消除了此延迟，因为 I/O 线程任务立即处理完成，并且任何 I/O 延迟是设备的功能，不受查询线程执行置于系统上的 CPU 负载的影响。

在线程化模式中，查询处理器和用户任务在完成计划程序时无需为 I/O 轮询进行环境切换。线程化轮询减少了轮询所花时间长度（以所有线程的总 CPU 时间的百分比为单位），从而使 SAP ASE 在 CPU 消耗方面更高效。

参数number of network taks和number of disk tasks确定IO任务数量。

缺省情况下，每个 I/O 任务使用 syb_system_pool 中的线程，从而允许在 I/O 轮询期间阻止任务，进而减少忙轮询的开销。在低 I/O 负载期间，这些线程消耗很少的物理 CPU 时间。I/O 线程的 CPU 时间随 I/O 负载的增加而增加，但负载增加量取决于处理器性能和 I/O 实现。

1. IO控制器

SAP ASE中每个任务表示一个控制器。每个任务分配了操作系统线程。通常一个系统一个IO足够了，但是IO率高或单线程性能低的系统上，需要附加控制器。

使用 sp_sysmon“内核利用率”部分确定是否需要附加 I/O 任务。

在以下情况下，考虑附加 I/O 任务：

1. I/O 任务的“Thread Utilization (OS %)”超过“Engine Busy Utilization”。
2. I/O 任务的“Thread Utilization (OS %)”超过 50%。
3. Controller Activity 部分中返回“max events”的轮询大于零。
4. Controller Activity 部分中的“average events per poll”大于三。

1. 网络包大小

如果应用程序的查询结果超过网络包配置的大小，则 SAP ASE 将数据拆分为两个或两个以上网络包。由于发送每个包需要完整经过 SAP ASE 网络 I/O 机制，当应用程序结果常常大于配置的包大小时，则应该增加 network packet size 以允许传送所使用的包更少、更大，从而减少单个经过网络 I/O 机制的次数并提高性能。

SAP ASE 必须预分配大小以发送和接收最大可能大小的缓冲区，因此使用更大的包大小也意味着每个用户将占用更多的内存。

如果数据传输的实际大小常常明显小于配置的包大小，则可以减小该值以节省内存。

OLTP 发送和接收大量包含数据量极小的包。典型的 insert 或 update 语句可能只有 100 或 200 个字节。即使连接了多个表的数据检索也可能只返回一行或两行数据，且仍小于 network packet size 设置的包大小，尽管这并不影响性能。使用存储过程和游标的应用程序通常也只发送和接收小包。

决策支持应用程序经常包括大批量的查询并返回较大的结果集。

对于大多数应用程序，缺省的网络包大小 2048 工作良好。如果应用程序仅使用短查询并接收小结果集，可将 default network packet size 更改为 512。

较大的包将减少总体开销，达到更高的物理吞吐量（假设有足够多的数据要发送）。以下场景慧聪大包中受益：批量复制，readtext 和 writetext 命令，结果集较大的 select 语句，使用较大行大小的插入。

1. 1. 1. 监控诊断

在Sybase 下更改网络配置以观察对性能产生的影响时可使用 sp_sysmon

1. 网络监控

先监控1分钟的网络OI，(需要打开‘enable monitoring‘开关)执行并输出如下：

1> sp_sysmon "00:01:00","netio"

2> go

======================================================================

      Sybase Adaptive Server Enterprise System Performance Report

======================================================================

Network I/O Management

----------------------

  Network I/O Requests            per sec      per xact       count  % of total

  -------------------------  ------------  ------------  ----------  ----------

  Total Network I/O Requests          0.0           0.0           0       n/a

  Network Receive Activity        per sec      per xact       count

  -------------------------  ------------  ------------  ----------

  Total TDS Packets Rec'd             0.0           0.0           0

  Total Bytes Rec'd                   0.0           0.0           0

  Network Send Activity           per sec      per xact       count

  -------------------------  ------------  ------------  ----------

  Total TDS Packets Sent              0.0           0.0           0       n/a

  Total Bytes Sent                    0.0           0.0           0       n/a

(return status = 0)

       这个试验机上没有压力，所以监控数据都是0，这个咱们可以先不管，我们来看下各个参数的含义是什么吧。

       每个引擎都处理自己的网络IO。当引擎多于任务的时候，没有工作可执行的引擎会报告无IO。

其中Total Network I/O Requests是发送和接收的包的总数，根据网络每秒可处理的包数量来判断是否网络带宽到瓶颈了。

Network I/O Delayed报告延迟次数，如果为非零，那么需要警戒了。

如果从网络IO管理处监控不到什么信息，可以查看内核监控。

Total TDS Packets Received – 报告每个引擎接收到的 TDS 包数。

Total TDS Packets Received 报告在采样间隔期间收到的包数。

Total Bytes Received – 报告每个引擎接收到的字节数。

Total Bytes Received 报告采样间隔期间收到的字节总数。

Average Bytes Received per Packet – 报告在采样间隔期间收到的所有包的平均字节数。

Total TDS Packets Sent – 报告每个引擎发送的包数，以及整个服务器发送的包的总数。

Total Bytes Sent – 报告在采样间隔期间由每个 Adaptive Server 引擎发送的字节数，以及整个服务器发送的字节数。

Average Bytes Sent per Packet – 报告在采样间隔期间发送的所有包的平均字节数

1. 内核监控

监控kernel工作状态，监控输出如下：

4> sp_sysmon "00:01:00","kernel"

5> go

======================================================================

      Sybase Adaptive Server Enterprise System Performance Report

======================================================================

Kernel Utilization

------------------

  Engine Utilization (Tick %)   User Busy   System Busy    I/O Busy        Idle

  -------------------------  ------------  ------------  ----------  ----------

  ThreadPool : syb_default_pool

   Engine 0                         0.0 %         0.0 %       0.0 %     100.0 %

  Average Runnable Tasks            1 min         5 min      15 min  % of total

  -------------------------  ------------  ------------  ----------  ----------

  ThreadPool : syb_default_pool

   Global Queue                       0.0           0.0         0.0       0.0 %

   Engine 0                           0.0           0.0         0.0     100.0 %

  -------------------------  ------------  ------------  ----------

  Server Summary      Total           0.0           0.0         0.0

                    Average           0.0           0.0         0.0

  CPU Yields by Engine            per sec      per xact       count  % of total

  -------------------------  ------------  ------------  ----------  ----------

  ThreadPool : syb_default_pool

   Engine 0

      Full Sleeps                    40.4         161.5        2422      97.6 %

      Interrupted Sleeps              1.0           4.0          60       2.4 %

  Thread Utilization (OS %)     User Busy   System Busy        Idle

  -------------------------  ------------  ------------  ----------

  ThreadPool : syb_blocking_pool : no activity during sample

  ThreadPool : syb_default_pool

   Thread 2    (Engine 0)           0.0 %         0.0 %     100.0 %

  ThreadPool : syb_system_pool : no activity during sample

  -------------------------  ------------  ------------  ----------

  Server Summary    Total           0.0 %         0.0 %     900.0 %

                  Average           0.0 %         0.0 %     100.0 %

  Adaptive Server threads are consuming 0.0 CPU units.

  Throughput (committed xacts per CPU unit) : n/a

  CtlibController Activity        per sec      per xact       count  % of total

  -------------------------  ------------  ------------  ----------  ----------

   Polls                             0.0           0.0           0       0.0 %

  DiskController Activity         per sec      per xact       count  % of total

  -------------------------  ------------  ------------  ----------  ----------

   Polls                            120.5         481.9        7229       n/a

   Polls Returning Events             1.4           5.4          81       1.1 %

   Polls Returning Max Events         0.0           0.0           0       0.0 %

   Total Events                       1.8           7.2         108       n/a

   Events Per Poll                    n/a           n/a       0.015       n/a

  NetController Activity          per sec      per xact       count  % of total

  -------------------------  ------------  ------------  ----------  ----------

   Polls                              1.0           4.0          60       n/a

   Polls Returning Events             0.0           0.0           0       0.0 %

  Blocking Call Activity          per sec      per xact       count  % of total

  -------------------------  ------------  ------------  ----------  ----------

  Total Requests                      0.0           0.0           0       n/a

(return status = 0)

        内核监控可以提供SAP ASE服务器引擎的繁忙程度，CPU将控制权交给操作系统的频率、引擎检查网络和磁盘IO的次数以及每次检查时所找到的处于等待状态的引擎的平均IO数。

Engine Utilization (Tick %)确定SAP ASE服务器引擎是过多还是过少。可能是操作系统工具报告的CPU使用率不同。

"User Busy" – 用户任务，例如用户连接。

"System Busy" – 内部任务，例如管家。

如果执行某项任务，引擎将报告 "CPU Busy"；如果空闲，引擎将报告 "Idle"。如果 SAP ASE 有任何未完成的 I/O 而引擎处于空闲状态，则引擎将被视为 "I/O Busy"。如果有一个未完成的 I/O 和三个处于空闲状态的引擎，则每个引擎都将被视为 "I/O Busy"。

通过检查 sp_sysmon 输出中的问题以及进行调优以缓解争用，即使引擎报告的繁忙时间在 80-90% 范围内，响应时间仍旧非常快。如果此值一直很高（大于 90%），则增加引擎可能会缩短响应时间和提高吞吐量。

Full Sleeps – 引擎在其完全休眠间隔内保持休眠状态（即，在休眠时未接收可运行任务）。完全休眠很可能导致另一次休眠。完全休眠不会增加延迟。

Interrupted Sleeps – 引擎被可运行任务从休眠状态提前唤醒。中断式休眠很可能导致预定任务。中断式休眠可能会增加延迟。

"% of total" 数据是一个引擎的放弃次数占所有引擎的组合放弃次数的百分比。

Total CPU Yields 报告基于所有引擎的组合数据。

当引擎不忙时，它会在与 idle timeout 参数有关的一段时间后放弃 CPU。

线程使用率

Thread Utilization (OS%) 显示每个 SAP ASE 线程在操作系统级别花费的时间。这部分时间是线程实际使用 CPU 的时间。

Pool Summary 表示在线程池中使用的线程所占的百分比。Server Summary 描述在 SAP ASE 中使用的线程所占的百分比。

User time 报告在 sp_sysmon 采样间隔期间内线程在用户空间内执行代码（即，在 SAP ASE 中运行）的时间百分比。"System time" 报告在 sp_sysmon 采样间隔期间内线程在系统空间内执行代码（即，在操作系统内核中运行）的时间百分比。这种区别与 Engine Utilization (Tick %) 部分中报告的 "User Busy" 和 "System Busy" 无关。

       在现场环境中发现引擎中的IO Busy达到了10%以上。

       那么IO Busy是什么东西？为何这么高？

1. IO Busy

Kernel中发现IO Busy高后，监控diskio,

Disk IO Management下发现磁盘并无瓶颈。

查看net io下的

接受和发送的包数量较多，但是并没有导致延时。

1. 1. 1. 参考文档

《SAP_ASE_Performance_and_Tuning_Series_Basics.pdf》