级别： 初级 Connie Lam (hylam@hk1.ibm.com), DB2 UDB 高级支持, IBM
2005 年 11 月 18 日 了解连接集中器（connection concentrator）如何为 IBM® DB2® Universal Database™ Version 8.0 (DB2 UDB) 增加性能优势。本文介绍连接集中器的工作原理，以及何时和如何使用它。本文还要介绍性能调优和故障诊断的技巧。
简介
连接集中器是 IBM DB2 Universal Database Version 8.0 (DB2 UDB) 中的一个新特性，用于处理大量的入站连接，这些连接具有非常短暂的事务，但是却有相对较大的延迟。该特性具有以下优点：
- 系统资源不被不执行任何工作的连接（空闲连接）所占有。
- 由于多路复用的体系架构，代理之间可以相互切换以服务许多客户机应用程序。
- 服务器资源限制是基于实际的事务负载，而不是基于连接的数量。
例如，假设您有这样一个 Web 应用程序，其中的用户连接到数据库，而不是针对表记录执行大量的事务。连接集中器允许用户看起来是连接到数据库的，而实际的数据库代理仍然可以服务入站请求。
下面是一些可伸缩性和性能增强：
- 相对于运行相同负载的其他系统来说，需要更少的系统资源。
- 控制结构被分为应用程序级和代理级数据。
- 每个连接需要的内存（平均来说）和进程更少。
启用连接集中器
在数据库管理器配置中设置以下参数以启用连接集中器：
-
max_connections 的值必须大于 max_coordagents 的值，以打开连接集中器。
- 默认情况下，max_connections 参数等于 max_coordagents，因而连接集中器是不启用的。该参数控制允许连接到实例的应用程序的最大数量。范围是 [-1; max_coordagents -- 64000]。
-
max_coordagents 参数是可以存在于实例中的协调代理的最大数量。每个本地或远程应用程序事务都由一个协调代理来服务。
当连接集中器是启用的时，max_connections 限制用户连接的数量，max_coordagents 限制服务于事务的代理的数量。
连接集中器的工作原理
DB2 UDB 使用一个数据库代理来服务连接请求。每个用户连接分配一个数据库代理。代理存在于连接的整个生命周期，与连接上运行的工作负载无关。一旦启用了连接集中器，数据库代理就只在 SQL 事务期间是 “热的”。在事务边界（提交或回滚）的末尾，数据库代理与应用程序分离。然后代理是自由的，可以服务于来自其他应用程序的其他事务请求。
图 1. 连接集中器体系架构
分配器
分配器（dispatcher）是一个 DB2 进程 (db2disp)，即连接集中器的关键组件。它通过将入站的连接和事务分配给代理，而控制连接到代理的多路复用。
分配器有两种方式可以得到代理：
- 从空闲代理池找到一个不活动的代理，然后将连接或事务请求传递给该代理进行服务。
- 如果池中没有空闲的代理，就创建一个新的代理，当然这样做的前提是不会超出数据库管理器配置中设置的 maxagents/max_coordagents 限制。注意：如果创建新的代理超出了这一限制，那么连接会排队等待下一个可用的代理来服务请求。
每个分配器最多可处理几百个连接。新的连接被分配给特定的分配器，并在连接的整个生命周期中都与这个分配器保持在一起。
代理
代理由分配器创建或者从服务于一个应用程序移动到服务于另一个应用程序。事务一提交或回滚，代理就变为空闲的，并可以服务于分配器分配的请求。
数据库代理是名为 "db2agent" 或 "db2agentg" 的进程：
- db2agent 用于 DB2 UDB 数据库连接
- db2agentg 用于到大型机的网关连接
当代理与一个事务相关联时，进程名会显示它相关联的数据库名。
例如，在自动提交完成后，在 commit 或 rollback 发出之前，发出一个 select 语句。进程 listing (ps -ef | grep instname ) 将显示 "db2agent (SAMPLE)"，其中 SAMPLE 是该特定代理相关联的数据库名。
一旦提交或回滚，相同的进程将显示 "db2agent (idle)"。
连接集中器的行为
参见连接集中器的 行为。
连接池与连接集中器
连接池与代理的分配和解除分配相关联。它决定当连接断开时代理是否与连接保持在一起。
连接集中器与代理的上下文切换相关联。它决定当事务结束时代理将服务于哪个应用程序。
连接池的工作取决于连接和断开连接。连接集中器的工作取决于事务边界（提交和回滚）。
连接池有助于减少创建和终止数据库代理方面的开销。连接集中器有助于减少当连接空闲时每个代理分配的资源。
启用连接集中器必须将连接池打开？
是的，由于连接集中器需要利用连接池的功能，因此启用连接集中器必须将连接池打开。
启用了连接集中器之后，一旦到达事务边界，db2agent 就是自由的，可以服务于其他请求。如果没有入站的请求需要服务，分配器就将决定该代理是否可以保留。这时，连接池就要发挥作用了。
如果连接池是禁用的，那么该代理将被终止，因为当连接池是关闭的时，不可以保留空闲代理。如果连接池是打开的，并且保留该代理不会超出 num_poolagents 限制，那么该代理将会被保留。它将等待服务于下一个请求。如果连接池是打开的，并且保留该代理超出了 num_poolagents 限制，那么该代理将被终止。
禁止连接池而启用连接集中器的潜在问题是，一旦达到事务边界，代理就会终止。当事务结束时，大多数代理将被终止。当事务开始时，总是需要分配新的代理。这样会导致到达事务边界时的代理分配和解除分配这一巨大开销，这会影响连接集中器的功能。
调整代理的参数以适应连接集中器
有关连接集中器的一个常见问题是，“将 max_connections 和 max_coordagents 设为多大才最好？”
答案涉及到数据库管理器配置中代理的调整，正确的方法是进行微调。每个参数的设置依赖于您当前运行的系统。
以下是我的建议：
- 保持您当前的 maxagents、max_coordagents 和 num_poolagents 设置。设置 max_connections = max_coordagents + 1 而打开连接集中器。
现在连接集中器是打开的，服务器的配置仍然保持不变。所以，资源使用和可以连接到系统的用户数量应该不变，但是使用或产生的 db2agent 进程更少。
- 截取一个数据库管理器快照：
db2 get snapshot for dbm
下面来看快照输出的底部部分：
Agents assigned from pool = 0
Agents created from empty pool = 4
Agents stolen from another application = 0
High water mark for coordinating agents = 1
Max agents overflow = 0
Hash joins after heap threshold exceeded = 0
|
查找 "high water mark for coordinating agents" 一行。这表示自您的实例以启用连接集中器开始以来的所有时间点上存在的最大代理数。
在连接集中器场景中，只有在事务需要时才产生代理。因此，这个最高数字基本上就是在启用连接集中器时您同时需要的最大代理数。
这个数字每天都会改变。在一个星期内每天都截取该快照，直到相应代理的最高数字趋于稳定。这是您的系统应该具有的最小代理数。您可以参照这个数字相应地设置 max_coordagents。
例如，如果您的初始 max_coordagents 是 2000，并且连接集中器是启用的时最高数字是 500，那么为了安全起见，我可以将 max_coordagents 设置为 800。
然后您可以逐渐增大 max_connections 以允许更多的用户使用该实例。同时，继续截取快照，看随着 max_connections 的增大，最高数字是如何增大的。
最后，您应该看到，对于初始的 max_coordagents 设置，您可以允许更多的用户连接到实例。
如果在启用了连接集中器时参数没有设置正确会怎么样呢？
如果有一个新的入站请求，但是所有的代理都被占用了，意味着它们都正处于还没有提交或回滚的事务当中，那么入站的事务将被挂起。这是因为没有可用的代理可以服务于您的请求，甚至没有一个代理可以用一个错误消息返回您的请求。
当您看到这样的情况时，比如在连接集中器打开后用户请求将被挂起，那么您的 max_coordagents 设置可能不够高。
您可以增大 max_coordagents 设置，或者降低 max_connections 设置。如果不管您的 max_coordagents 设置有多高，问题依然如故，那么应该看一下问题是不是涉及到用户应用程序中缺少提交。当应用程序不经常提交事务时，代理会被一直占用。最终，所有的代理都将被占用，导致出现挂起的情况。为了解决这个问题，惟一的解决方案是让您的应用程序在每个事务完成时进行提交。如果您不能纠正这个问题，那么您的环境就不适合于使用连接集中器。
已知的限制
- 不能在打开连接集中器的情况下启用联邦参数。如果您想要使用连接集中器，就必须在数据库管理配置中指定 Federated=NO。
- DB2 UDB V7 客户机不能利用 DB2 UDB V8 连接集中器的优势，它只对 V8 客户机和本地 V8 服务器连接起作用。
免责声明
本文中的观点、解决方案和建议都是作者的经验，不代表 IBM 的官方意见。作者和 IBM 都不对本文中的任何内容负责。本文中信息的准确性基于作者在撰写本文时的知识。
参考资料 学习
获得产品和技术
讨论
关于作者  | | | Connie Lam 作为一名 IBM DB2 UDB 高级支持已经有 5 年多了。她支持全世界处于关键和系统停机情况下的 DB2 UDB 客户。她专攻 DB2 的一个组件，即连接集中器。 |
对本文的评价
| 
