10.案例Sybase分析

浅沫记忆

• 
  
  • Sybase数据库网络性能
    
    
    • 网络性能
      
    
    
  
  

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

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

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

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

• 
  
  • 
    
    • 如何解决呢？
      
    
    
  
  

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

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

那么问题来了，既然知道了现象，原因以及解决办法，我们是不是没有我们的事情了？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 使用轮询计划程序。

• 网络监听器
  

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

• 进程模式
  

进程模式中，每个端口使用一个监听器任务。通过从一个引擎切换到另一个来平衡负载，每个监听器都起到多个逻辑监听器的作用。
如果14个引擎，有两个主端口的监听器任务，那么两个监听器任务要充当28个逻辑监听器，这样服务器就具有两个物理监听器和28个逻辑监听器。每个物理监听器负责14个逻辑监听器。

• 线程模式
  

在配置为线程化轮询时，控制器管理器为每个控制器指派任务，并将此任务放入 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 实现。

• IO控制器
  

SAP ASE中每个任务表示一个控制器。每个任务分配了操作系统线程。通常一个系统一个IO足够了，但是IO率高或单线程性能低的系统上，需要附加控制器。
使用 sp_sysmon“内核利用率”部分确定是否需要附加 I/O 任务。
在以下情况下，考虑附加 I/O 任务：

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

• 网络包大小
  

如果应用程序的查询结果超过网络包配置的大小，则 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 语句，使用较大行大小的插入。

• 
  
  • 
    
    • 监控诊断
      
    
    
  
  

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

• 网络监控
  

先监控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 – 报告在采样间隔期间发送的所有包的平均字节数

• 内核监控
  

监控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是什么东西？为何这么高？

• IO Busy
  

Kernel中发现IO Busy高后，监控diskio,
Disk IO Management下发现磁盘并无瓶颈。
查看net io下的
接受和发送的包数量较多，但是并没有导致延时。

• 
  
  • 
    
    • 参考文档
      
    
    
  
  

《SAP_ASE_Performance_and_Tuning_Series_Basics.pdf》