db2代理和优化

DB2 的代理 (agent) 是位于 DB2 服务器中的服务于应用程序请求的一些进程或线程。当有外部应用程序连接至 DB2 实例提出访问请求时，DB2 的代理就会被激活去应答这些请求。一般 DB2 的代理被称为工作代理，工作代理大概有三种类型：空闲代理、活动的协调代理、子代理。

  • 空闲代理：指的是没有任何任务的代理。这种代理不服务于任何远程连接也不服务于本地连接，处于一种备用或待命状态。
  • 活动的协调代理：指的是处于工作状态的代理，每一个外部应用程序产生的数据库活动连接的都有一个活动协调代理来为它服务。
  • 子代理：指的是接受协调代理分发出来的工作的下一级代理。在 DB2 V95 以前，只有在多分区环境 (MPP) 或节点内并行环境 (SMP) 下才存在子代理，在 DB2 V95 中所有环境中都可能存在子代理。

在 DB2 服务器中有一个代理池，当实例刚启动后这里便有一些代理（其数量取决于实例参数 NUM_INITAGENTS）。在没有任何数据库连接时，它们处于待命状态，就是空闲代理。而当有外部程序连接至数据库时，这些代理开始得到命令去服务于这些新建的连接，这时它们就变成了活动的协调代理。这些协调代理再将请求逐步细分，分配给下一级代理即子代理去处理。如果当前的代理都已经在工作了，同时又来了新的请求，数据库管理器会产生一个新的代理去应答。当事务处理完毕而且数据库连接断开后，协调代理要么返回代理池变回空闲代理，要么就自动消失了（取决于实例参数 NUM_POOLAGENTS）。这就是一个代理的生命周期。

回页首

相关的配置参数

通过执行 DB2 get dbm cfg 可以看到以下几个和代理相关的实例参数：MAXAGENTS，NUM_POOLAGENTS，NUM_INITAGENTS，MAX_COORDAGENTS，MAX_CONNECTIONS，MAXCAGENTS。下面对它们做一下简要介绍：

  • MAXAGENTS：这个参数为当前实例中全部代理的数量，包括协调代理，空闲代理和子代理之和。不过这个参数在 DB2 V95 中已经不再使用了。
  • NUM_POOLAGENTS：这个参数用来控制代理池中的空闲代理的数量。当活动的代理完成工作返回代理池变成空闲代理时，如果数量超过了这个参数，那么这个代理就会自动消失了。注意：在连接集中器激活的情况下，代理池中的空闲代理数目在某一时刻可能会超过 NUM_POOLAGENTS 的大小，以应对突发的高密度连接。
  • NUM_INITAGENTS：这个参数就是前面提到的在实例刚刚启动时便生成的一些空闲代理的数目。这是为了提高性能，因为这些代理可以随时变成协调代理去应答外部应用请求，而不用临时再生成新的代理。
  • MAX_COORDAGENTS：这个参数决定了在实例中在同一时刻最大的协调代理的数目 ( 在多分区环境指的是一个节点上的最大协调代理数 )。
  • MAX_CONNECTIONS：这个参数决定了允许连接至一个实例的最大的连接数 ( 在多分区环境指的是一个节点上的最大连接数 )。
  • MAXCAGENT：这个参数决定了实例中的令牌的数量，一个协调代理只有得到了令牌才能去服务于应用程序。当没有得到令牌时，协调代理只能等候。不过这个参数在 DB2 V95 中也已经取消了。

还有一个连接参数 MAXAPPLS 可以通过 db2 get db cfg for database_name 得到，它是一个数据库级别的参数，这个参数决定了同时连接至一个数据库的最大连接数。在一个实例下的所有数据库的 MAXAPPLS 值之和不能超过实例参数 MAX_CONNECTIONS。

回页首

连接集中器

1. 基本原理

从 DB2 V8 开始，DB2 实例中有一个叫做连接集中器的特性，可以用来优化数据库的连接。缺省情况下，在实例创建的时候，MAX_CONNECTIONS 与 MAX_COORDAGENTS 的值是一致的。这个时候每一个协调代理唯一地服务于一个连接。比如说有 1000 个连接就要有 1000 个协调代理为之服务。这对服务器是一个很大的负担，因为每一个代理都要消耗一定的资源。而当我们将 MAX_CONNECTIONS 的值设定的比 MAX_COORDAGENTS 大，这时 DB2 的连接集中器就被激活了。它允许多个连接对应于一个代理。

连接集中器的功能与 DB2 CONNECT 中的连接池相似。不过连接集中器比连接池的优点在于它能够重用外部连接，即多个排队的应用程序可以重复使用一个存在的连接，而连接池则需要先删除再重建一个连接去服务于一个新的应用程序。在连接集中器中每个协调代理并不唯一地服务于一个连接，当某个外部连接断开后，协调代理被分配给其他连接。这样。同时允许更多的连接连到数据库，并且减少了每个连接的内存消耗，避免了频繁的删除和创建代理所带来的系统开销。下面是连接集中器的具体工作原理：

首先将 MAX_CONNECTIONS 的值设定的大于 MAX_COORDAGENTS 去激活连接集中器。在连接集中器中代理被分成逻辑代理和工作代理。逻辑代理与外部应用程序对应，它并不对应与某个特定的引擎分配单元 (EDU)。工作代理和前面定义的一样，是具体的引擎分配单元。当逻辑代理多于工作代理时连接集中器就被激活了。当有多个连接同时连接到服务器时，连接被一一分配给各个逻辑代理。逻辑代理再去请求工作代理的服务。

比方说，代理池是一个饭店，在饭店里通常都是顾客多于服务员。刚开始，还没有顾客 ( 相当于外部应用 ) 的时候。有一些值班的服务员在饭店里待命（相当于实例启动时在代理池中创建的空闲代理 NUM_INITAGENTS）。一旦来了应用请求（顾客），调度程序（相当于领班）就去安排服务员开始工作，服务员就开始忙起来去招呼顾客。这时服务员的角色相当于协调代理。她们接待完顾客后便将菜单传达给厨师和小工 ( 相当于子代理 )。而当顾客越来越多，超过了最初的值班服务员数量。服务器就生成新的代理来服务于这些应用，就好像是从员工宿舍叫来更多的服务员来工作。当在场服务员数达到了一个数目 (MAX_COORDAGENTS)，饭店的所有服务员都在工作了，没有其他的在编服务员了。这时新来的顾客 ( 外部应用 ) 只能坐在座位上等候了。MAX_CONNECTIONS 在这里相当于饭店里的总的就餐座位数，当顾客数目 ( 外部应用 ) 达到了这个数值，后来的顾客只能离去了（相当于连不上数据库）。

这里需要注意的是 MAX_CONNECTIONS 并不是指同时连在实例上的活动的连接，因为有些连接即使连在实例上了，也要等候协调代理服务，当前活动的连接数与活动的协调代理数相等。当一个协调代理处理完一个应用程序后，它会被分配给其它等候的应用，相当于服务员去服务于其他等待着的顾客。在饭店中还有一些座位是专门为服务员休息准备的 ( 这个座位数相当于 NUM_POOLAGENTS)。当顾客渐渐散去，越来越少的时候，部分服务员 ( 协调代理 ) 已经无事可做，就返回这些座位（变成空闲代理）。当这些座位也被占满了，那么再有服务员 ( 协调代理 ) 返回休息时，就没有可供休息的座位了 ( 假设服务员不能坐就餐座位 )。这些服务员就只有返回员工宿舍了 ( 相当于代理的删除 )。图 1 反映了这一流程。图中实线箭头表明当前状态，虚线箭头表明将要发生的事件。

图 1. 代理的工作流程图

2. DB2 V9.5 新特性

在 DB2 V9.5 中有一个新特性，就是 MAX_CONNECTIONS 和 MAX_COORDAGENTS 都可以被设置成 AUTOMATIC。如果你认为系统可以承受所有的连接，同时又想限制被协调代理消耗的资源，你可以只将 MAX_CONNECTIONS 设定为 AUTOMATIC， MAX_COORDAGENTS 设定为一个数值。这时系统认为可以连到实例的连接数时无限的。如果你对最大连接数和协调代理数都不想做限制的话，你可以将它们都设为 AUTOMATIC。如果这时 MAX_CONNECTIONS 设定为 AUTOMATIC 的数值大于 MAX_COORDAGENTS 设定为 AUTOMATIC 的数值，连接集中器也就被激活了。而后，服务器就以刚才的两个数值之比作为参照 ( 这里叫做集中率 ) 按比例根据连接数来相应调整协调代理。示例如下：

db2 update dbm cfg using MAX_CONNECTIONS 300 AUTOMATIC;

db2 update dbm cfg using MAX_COORDAGENTS 100 AUTOMATIC;

这时集中率为 300/100=3，当连接在 1 到 100 时会创建协调代理，大于 100 小于 301 时就不会创建新的协调代理了。再从 301 增加到 400，又会增加 100 个协调代理，大于 400 小于 601 时又停止增加了……即每增加 300 个连接会增加 100 个协调代理。当前的具体数值可以通过 db2 attach to instance_name， db2 get dbm cfg show detail 得到。在这里允许设为 AUTOMATIC 有下面两种情况：

  • MAX_CONNECTIONS 为 AUTOMATIC 而 MAX_COORDAGENTS 为一定值。
  • MAX_CONNECTIONS 与 MAX_COORDAGENTS 同时为 AUTOMATIC。

当然连接集中器也有一些局限性：

  • 联邦数据库不支持连接集中器
  • 连接集中器对使用 withhold feature 的应用程序无效
  • 全局临时表在事务完成时必须显式关闭，否则连接集中器就会被关闭
  • 连接两阶段提交事务的连接只能用来连接两阶段提交事务的连接，同理连接一阶段提交事务的连接也只能用来连接一阶段提交事务的连接。
  • 不能在线激活连接集中器，也就是说，需要重启实例才可生效。

如果既不想使用连接集中器，又不想限制数据库连接的数目，可以运行下面的命令：

db2 update dbm cfg using MAX_COORDAGENTS AUTOMATIC；

db2 update dbm cfg using MAX_CONNECTIONS AUTOMATIC；

回页首

代理和连接常见问题分析与优化

1．连接超限问题

在 DB2 V8，V9.1 中所设置的 MAX_CONNECTIONS 或 MAXAGENTS 值比较小时，如果出现了外部连接数过多就会出现错误。错误如清单 1 所示。

清单 1. db2diag.log 诊断日志
2008-01-15-14.30.13.090289-360 I12983210A1195     LEVEL: Info
PID     : 762076               TID  : 772         PROC : db2acd
INSTANCE: db2inst1             NODE : 000
APPID   : *LOCAL.db2inst1.080115203015
EDUID   : 772                  EDUNAME: db2acd
FUNCTION: DB2 UDB, DRDA Communication Manager, sqljcReceive, probe:30
MESSAGE : ZRC=0x8136001C=-2127167460=SQLZ_RC_NO_CONNECTION, SQLT_SQLJC
          "No connection"
DATA #1 : String, 11 bytes
CCI Error:
DATA #2 : unsigned integer, 8 bytes
...

这时可以通过下面命令来查看当前的连接数：

清单 2. 查看当前的连接数
$ db2 list applications

Auth Id  Application    Appl.      Application Id
                  DB       # of
         Name           Handle
                  Name    Agents
-------- -------------- ---------- ---------------------------------------------
----------------- -------- -----
DB2INST1 db2taskd       583        *LOCAL.db2inst1.080112150958
                  SVT_DB 	 1
DB2INST1 db2stmm       582        *LOCAL.db2inst1.080112150957
                  SVT_DB 	 1
DB2INST1 java           592        *LOCAL.db2inst1.080115201505
                  SVT_DB   1
DB2INST1 java           572        *LOCAL.db2inst1.080115201445
                  SVT_DB   1
DB2INST1 java           585        *LOCAL.db2inst1.080115201458
                  SVT_DB   1
DB2INST1 java           565        *LOCAL.db2inst1.080115201437
                  SVT_DB   1
DB2INST1 java           584        *LOCAL.db2inst1.080115201457
                  SVT_DB   1
DB2INST1 java           590        *LOCAL.db2inst1.080115201503
SVT_DB   1
DB2INST1 db2bp         591        *LOCAL.db2inst1.080115201502
...

可以查看这时的连接数与 MAX_CONNECTIONS 的值的比较，从而做出调整。这时应当注意，在 v9.1 或 v9.5 环境下，有两个服务器内部的特殊应用 db2stmm 和 db2taskd 不应算作外部连接。db2stmm 是用来管理内存自动调节特性的代理，db2taskd 是用来分配数据库后台任务的代理。示例中的 java 代表外部连接来自 JAVA 应用程序。db2bp 代表来自 CLP(DB2 命令窗口 ) 的一个连接。可以看到这些连接都连到了数据库 SVT_DB 上。

接下来可以通过 db2pd 命令来查看当前的代理数：

清单 3. 通过 db2pd 命令来查看当前的代理数
$ db2pd –agents –db SVT_DB
Database Partition 0 -- Active -- Up 1 days 01:24:44
Agents:
Current agents:      36
Idle agents:         0
Active coord agents:  28
Active agents total:   28
Pooled coord agents:  8
Pooled agents total:   8

Address            AppHandl [nod-index] AgentEDUID Priority   Type     State
   ClientPid  Userid   ClientNm Rowsread   Rowswrtn   LkTmOt DBName
0x0780000000DABD60 522      [000-00522] 2315       0           Coord    Inst-Act
ive 655614     db2inst1 db2bp    375793     9620       NotSet SVT_DB
0x07800000027A4160 523      [000-00523] 6170       0           Coord    Inst-Act
ive 655614     db2inst1 db2stmm  0          0          NotSet SVT_DB
0x07800000027A5700 524      [000-00524] 6427       0           Coord    Inst-Act
ive 655614     db2inst1 db2taskd 0          0            NotSet SVT_DB
0x0780000000DAD840 525      [000-00525] 5158       0           Coord    Inst-Act
ive 655614     db2inst1 db2wlmd  0          0          NotSet   SVT_DB
0x07800000027A0080 526      [000-00526] 5415       0           Coord    Inst-Act
ive 655614     db2inst1 db2evml_ 0          0          3         SVT_DB
0x07800000028C0080 566      [000-00566] 10810      0           Coord    Inst-Act
ive 905284     db2inst1 java     160282     102        NotSet SVT_DB
0x07800000027AB2C0 567      [000-00567] 7469       0           Coord    Inst-Act
...

在这里看到 Idle agents 值为 0 表明代理池中已经没有空闲代理了（State 全都是 Inst-Active）。这时可以将 Current agents 的值与 MAXAGENTS 的值的比较，或者 Active agents total 的值与 MAX_COORDAGENTS 的值的比较，从而做出相应调整。

对于这种问题还可以通过分析数据库管理器的快照来作出调整：

清单 4. 分析数据库管理器的快照
db2 get snapshot for dbm：
...
Remote Connection Executing in the Database Manager = 58
Local Connection Executing in the Database Manager  = 1
...
Agents assigned from pool                      = 38
Agents created from empty pool                 = 158
Agents stolen from another application         = 1
High water mark for coordinating agents        = 60
Max agents overflow                            = 3
Hash joins after heap threshold exceeded       = 0
……

可以看到 Max agents overflow 的值等于 3，说明有 3 次生成代理数超过限制的情况。这时会在 DB2diag.log 中看到前面的错误信息。此时必须调节 MAXAGENTS 的值以修复当前错误。可以将 MAX_COORDAGENTS 设定为与 High water mark for coordinating agents 相同的值，在单分区环境下可以将 MAXAGENTS 设定与 MAX_COORDAGENTS 一样，在多分区环境 (MPP) 或节点内并行环境 (SMP) 中，根据节点数来计算出结果 MAXAGENTS =(N+1)* MAX_COORDAGENTS (N 为节点数 )。另一方面在 MAX_COORDAGENTS 不是 AUTOMATIC 的情况下，如果 Remote Connection Executing in the Database Manager 的值与 Local Connection Executing in the Database Manager 的值之和接近 MAX_COORDAGENTS，这时要适当增大 MAX_COORDAGENTS 的值。

一般说来有这样的原则，当在连接数据库是出现内存错误时，调节如下参数：

  • 在单分区并且没有节点内并行性 (SMP) 的情况下增大 MAXAGENTS 的值。
  • 在多分区 (MPP) 或者节点内并行环境 (SMP) 的情况下增大 MAXAGENTS 或 MAX_COORDAGENTS 的值。
  • 在连接集中器激活的情况下，增大 MAX_CONNECTIONS 的值。

2. 连接挂起问题

还有一个与连接相关的问题：在首次连接数据库时，连接时间总要长一些。这是因为数据库在为首次连接分配内存，主要是缓冲池。连接时间长短取决于操作系统的内存调用情况以及缓冲池的大小。有时用户常常会为了提高应用性能盲目的扩大缓冲池，造成缓冲池设置得太大，甚至超过了数据库共享内存，使得实例无法为数据库分配足够的内存，在连接数据库时就会出现挂起现象。而这时想将缓冲池设小也没办法了，因为数据库连不上，无法设置缓冲池。这也是一个常见的问题。遇到这种问题时，有些用户甚至被迫重建数据库。其实这个问题可以通过设置 DB2 注册参数 DB2_OVERRIDE_BPF 来设置缓冲池的大小，从而能够再次连接数据库。在缺省情况下 (v9.1，v9.5) 缓冲池的大小被设置成 -2（通过 select npages from syscat.BUFFERPOOLS 得到），这说明缓冲池时自动增长的，这种情况下最好不要修改缓冲池的大小，可以让 DB2 自动去调节。

3. 常见通信错误

通常在连接数据库时还会遇到的一些与网络通信相关的错误，这些错误号如：SQL30080，SQL30081 等等。可以用以下一些方法去尝试解决：

  • 执行命令 db2set –all 来检查一下是否有 DB2COMM=TCPIP 一项，如果没有则应该添加上。
  • 执行命令 db2 get dbm cfg | grep SVCENAME 来检查 SVCENAME 设定的服务是否在 /etc/services(UNIX) 中定义了 (WINDOWS 是在 %windir%\system32\drivers\etc\ services)。当然如果 SVCENAME 是一个端口号，则不用在 services 中定义。（端口号应小于 65536）
  • 执行命令 netstat –a 检查输出中是否有 services 中定义的端口或服务在监听。如果没有，则可能需要重启网络或机器。
  • 这种问题也可能是防火墙导致的，在 Linux 上可以通过编辑 /etc/sysconfig/iptables 文件来绕过防火墙 ( 需要 root 权限 )。
  • 在 WINDOWS 有时还会遇到“No buffer space available(maximum connections reached?)”的错误消息，这种错误和 DB2 无关，需要增大 WINDOWS 的注册表参数值：
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

如果遇到其他特殊的问题可以通过命令 DB2 ? sqlxxxxx 来根据得到的提示去分析具

体问题。

4. 性能优化

调节 NUM_POOLAGENTS:

对于决策支持系统，由于连接数较少，NUM_POOLAGENTS 可以设为一个较小的值从而避免过多的空闲代理而浪费资源。而对于在线事务处理系统，由于连接数较多，可以设为一个较大的值从而减少频繁创建和删除代理所产生的系统消耗。具体数值可以通过分析数据库管理器快照来进行调节 :

清单 5. 通过分析数据库管理器快照来调节 NUM_POOLAGENTS
db2 get snapshot for dbm
...
Agents assigned from pool                      = 38
Agents created from empty pool                  = 158
Agents stolen from another application             = 1
...

当 Agents created from empty pool / Agents Assigned From Pool 的比值较小时，说明代理的重用率比较高。当比值比较大时，说明这时代理的创建、删除比较频繁，此时需要增大 NUM_POOLAGENTS 来减少系统频繁创建、删除代理时的资源消耗。当 Agents stolen from another application 的值较大时也应当增大 NUM_POOLAGENTS 的值。当然如果 NUM_POOLAGENTS 设得太大，可能会产生很多不必要的空闲代理长时间滞留在代理池中，造成资源的浪费。在 V8，V9.1 中 NUM_POOLAGENTS 的缺省值为 MAXAGENTS 的值的一半，而在 V9.5 中 NUM_POOLAGENTS 的缺省值被设为 AUTOMATIC( 初始值为 100)，这样数据库管理器可以自动管理代理池中空闲代理的数目。

调节 NUM_INITAGENTS：

NUM_INITAGENTS 的值最好和 NUM_POOLAGENTS 值一致。这样可以减少处理事务时生成代理的时间，而将这部分等待时间转移到启动实例时，这对用户来说是最理想的。

调节 MAX_CONNECTIONS 与 MAX_COORDAGENTS：

激活连接集中器，即设定 MAX_CONNECTIONS 大于 MAX_COORDAGENTS，这样可以节省 DB2 代理的数目，减少资源消耗，扩大连接数。在 V9.5 中最好将 MAX_CONNECTIONS 与 MAX_COORDAGENTS 都设为 AUTOMATIC，这样可以让 DB2 自动根据连接数来调节代理数。

回页首

DB2 V8，V9.1，V9.5 代理的差异性

DB2 在从 V8 到 V95 中代理特性有很多的改变，表 1 中列举了一些典型的特性上的差异供读者参考。

表 1：DB2 不同版本之间代理的差异性

特性
V8
V9.1
V9.5
新代理 - DB2taskd
DB2stmm		 DB2taskd
DB2stmm
代理存在形式 UNIX: 进程
Windows: 线程		 UNIX: 进程
Windows: 线程		 UNIX: 线程
Windows: 线程
SUBAGENT
存在环境		 MPP
SMP		 MPP
SMP		 MPP
SMP
SERIAL
代理是否支持 AUTOMATIC 否 否 是
是否支持参数
MAXAGENTS
MAXCAGENTS
AGENTPRI		 是 是 否
是否支持监控元素
MAX_AGENT_OVERFOLOWS		 是 是 否
MAX_CONNECTIONS 缺省值 MAX_COORDAGENTS MAX_COORDAGENTS AUTOMATIC
NUM_POOLAGENTS 缺省值 MAXAGENTS/2 MAXAGENTS/2 AUTOMATIC
MAX_COORDAGENTS 最大值 MAXAGENTS MAXAGENTS 64000
NUM_INITAGENTS 最大值 NUM_POOLAGENTS NUM_POOLAGENTS 64000
时间： 2024-12-14 21:09:05

db2代理和优化的相关文章

Nginx反向代理及优化

Nginx反向代理及优化 一.反向代理概念 反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器. 通常的代理服务器,只用于代理内部网络对Internet外部网络的连接请求,客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中.不支持外部网络对内部网络的连接请求,因为内部网络对外

db2 常用参数优化

常用参数修改: db2 "update db cfg for bmc using BUFFPAGE  51200" db2 'alter bufferpool ibmdefaultbp size 51200' db2 "update db cfg for bmc using LOGSECOND 200" db2 "update db cfg for bmc using SORTHEAP 1024" db2 "update db cfg

nginx 反向代理企业级优化介绍

1,nginx 服务器内核参数生产配置优化 原文地址:http://blog.51cto.com/skinglzw/2161582

让数据库飞起来 十大DB2优化技巧

DB2是IBM出口的一系列关系型数据库管理系统,分别在不同的操作系统平台上服务.下文中将为大家讲解DB2十大优化技巧. 为了帮助DB2 DBA 避免性能灾难并获得高性能,我为我们的客户.用户和 DB2 专家同行总结了一套故障诊断流程.以下详细说明在 Unix.Windows 和 OS/2 环境下使用 DB2 UDB 的电子商务OLTP 应用程序的10 条最重要的性能改善技巧,希望下文中涉及到的内容对大家能够有所帮助. 一. 监视开关 确保已经打开监视开关.如果它们没有打开,您将无法获取您需要的性

SAP+DB2 糟糕的报表查询『ZCOR0015』 优化全程记录

ZCOR0015的优化全过程记录文档 2015年3月,今天无意翻到这篇写于2010年7月的文档,回想那时的工作,毕业3年初出茅庐的我面对接触不多的SAP+DB2竟敢操刀动斧,自信满满. 虽然这过程一路坎坷,数次判断几乎全都被打脸验证,看着如小强般坚毅的我,哈哈~ 文档里带着情绪的措词十分逗笑,可以洞悉那时的心情. ——如今5年过去,却久未闻硝烟,怀念ing~ 目录: ZCOR0015的优化全过程记录文档... 1 内容说明:1 1.寻找问题点,切入分析... 2 2.再次碰到问题,转折点.. 6

Web前端性能优化之反向代理

前面我们介绍过怎么通过减少Http请求和CDN的方式来优化Web前端性能,今天我们就来简单的介绍一下通过反向代理来优化Web前端性能. 首先我们来了解一下什么叫反向代理? 1.正向代理与反向代理? 正向代理是位于客户端和原始服务器之间的服务器,为了能够从原始服务器获取请求的内容,客户端需要将请求发送给代理服务器,然后再由代理服务器将请求转发给原始服务器,原始服务器接受到代理服务器的请求并处理,然后将处理好的数据转发给代理服务器,之后再由代理服务器转发发给客户端,完成整个请求过程. 正向代理的典型

DB2数据库性能监控和调优实践

1.性能调优概述 性能问题的症状 响应时间慢 吞吐量低 资源占用高(CPU.Memory.I/0等) 数据库角度 数据库逻辑设计 数据库物理设计(存储规划) SQL语句 数据库调优关键 I/O最关键 减少I/O 最大化I/O效率 存储规律,物理设计 CPU两个杀手 表扫描 排序 Memory命中率可能会骗人 SQL是一切问题的根源 2.性能调优步骤 明确问题->收集数据->分析数据->细化.定位问题->优化 3.DB2数据库监控工具-db2pd 3.1.监控工具总结 即时监控工具

db2 内存总结

理解 DB2 如何使用内存,可以防止过度分配内存,并有助于对内存的使用进行调优,从而获得更好的性能. 本文将向您传授 DB2 内存使用的基础,以及共享内存和私有内存的概念.这些内容同时适用于 32 位和 64 位的系统.虽然对于 64 位系统有一些限制,但是在未来的一段时间内还不大可能触及这些限制.因此,我们将焦点放在影响 32 位系统的内存限制,并对之进行详细的讨论. 我们首先讨论一般情况下 DB2 如何使用内存,接着讨论内存管理如何随着平台(AIX.Sun.HP.Linux 和 Window

[精彩] 关于DB2的内存分配

这两天在看DB2的内存管理的内容,看的很是模糊,有以下问题不明白,请教 是不是数据库管理器的共享内存就是DB2能够使用的最大内容呢,然后数据库全局内存从管理器内存那里获得分配的内存,然后应用程序全局内存又从数据库全局内存那里获得分配内存的,也就是说他们是一层一层的包含关系.还是我理解有问题,是并列关系的呢? PS 现在DB2好的教材比较少,找了几本书上写的都不是很清楚,谁要要好的资料共享下,先谢了  nic518 回复于:2006-12-31 12:45:01 [导读]本文将向您讲解 DB2 内