遭遇db2频繁报内存不足的OS错误勘误解决方法
星期日, 2009-10-11 | Author: Lee | Database, JAVA-and-J2EE | 15,786 views
异常信息,因为有数据库的轮循处理,查询比较频繁,加上有高的并发访问,不到2个小时就挂掉了
希望高手求解!(下面是论坛的求助和解决方案,最终还是sql的实参过多,缓存溢出造成)
2009-09-29-19.48.24.000000+480 I34133163H580 LEVEL: Warning
PID : 2040 TID : 5036 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : XJS2
APPHDL : 0-21489 APPID: 61.172.241.131.57095.0909291332
AUTHID : WAPND
EDUID : 5036 EDUNAME: db2agent (XJS2)
FUNCTION: DB2 UDB, access plan manager, sqlra_find_pkg, probe:700
RETCODE : ZRC=0x8B0F0007=-1961951225=SQLO_NOMEM_PCKCACHEH
“No memory available in ‘Package Cache'”
DIA8300C A memory heap error has occurred.
2009-09-29-19.48.24.000000+480 E34133745H1196 LEVEL: Error (OS)
PID : 2040 TID : 4704 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : XJS2
APPHDL : 0-21500 APPID: 61.172.241.131.59911.0909291332
AUTHID : WAPND
EDUID : 4704 EDUNAME: db2agent (XJS2)
FUNCTION: DB2 UDB, SQO Memory Management, sqloLogMemoryCondition, probe:100
CALLED : OS, -, VirtualAlloc
OSERR : 8 “存储空间不足,无法处理此命令。”
MESSAGE : Private memory and/or virtual address space exhausted
DATA #1 : Requested size, PD_TYPE_MEM_REQUESTED_SIZE, 4 bytes
1048576
DATA #2 : Current set size, PD_TYPE_SET_SIZE, 4 bytes
613154816
CALLSTCK:
[0] 0x6CC2A500 pdLogSysRC + 0x25E
[1] 0x6CBAA700 sqloFreeMemChunks + 0x3C2
[2] 0x6CD5C4C5 sqloGetProfKey + 0x1D775
[3] 0x6E0AA1D1 sqlra_get_inc_bind_sect + 0x48B57
[4] 0x6E0B125B sqlra_get_inc_bind_sect + 0x4FBE1
[5] 0x6E079679 sqlra_get_inc_bind_sect + 0x17FFF
[6] 0x6E063F64 sqlra_get_inc_bind_sect + 0x28EA
[7] 0x6E06395A sqlra_get_inc_bind_sect + 0x22E0
[8] 0x6E07B3A2 sqlra_get_inc_bind_sect + 0x19D28
[9] 0x6E014D0D sqlrr_pn_init + 0x80CBD
2009-09-29-19.48.24.000000+480 E34134943H742 LEVEL: Warning
PID : 2040 TID : 4704 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : XJS2
APPHDL : 0-21500 APPID: 61.172.241.131.59911.0909291332
AUTHID : WAPND
EDUID : 4704 EDUNAME: db2agent (XJS2)
FUNCTION: DB2 UDB, SQO Memory Management, sqloMemLogPoolConditions, probe:30
DATA #1 :
Out of memory failure for Package Cache (PCKCACHESZ).
Requested block size : 511 bytes.
Physical heap size : 215875584 bytes.
Configured heap size : 308346880 bytes.
Unreserved memory used by heap : 0 bytes.
Unreserved memory left in set : 214695936 bytes.
———————————————————————————–
下面是配置情况:
get dbm cfg
数据库管理器配置
节点类型 = 带有本地和远程客户机的数据库服务器
数据库管理器配置发行版级别 = 0x0d00
最大打开文件数 (MAXTOTFILOP) = 16000
CPU 速度(毫秒/指令) (CPUSPEED) = 1.417033e-007
最大并发活动数据库数 (NUMDB) = 8
联合数据库系统支持 (FEDERATED) = NO
事务处理器监视器名 (TP_MON_NAME) =
缺省对方付费帐户 (DFT_ACCOUNT_STR) =
Java Development Kit 安装路径(JDK_PATH) = D:\PROGRA~1\IBM\SQLLIB\java\jdk
诊断错误捕获级别 (DIAGLEVEL) = 3
通知级别 (NOTIFYLEVEL) = 3
诊断数据目录路径 (DIAGPATH) =
轮转 db2diag 和通知日志的大小(MB) (DIAGSIZE) = 0
缺省数据库监视开关
缓冲池 (DFT_MON_BUFPOOL) = OFF
锁定 (DFT_MON_LOCK) = OFF
排序 (DFT_MON_SORT) = OFF
语句 (DFT_MON_STMT) = OFF
表 (DFT_MON_TABLE) = OFF
时间戳记 (DFT_MON_TIMESTAMP) = ON
工作单元 (DFT_MON_UOW) = OFF
监视实例和数据库的运行状况 (HEALTH_MON) = OFF
SYSADM 组名 (SYSADM_GROUP) =
SYSCTRL 组名 (SYSCTRL_GROUP) =
SYSMAINT 组名 (SYSMAINT_GROUP) =
SYSMON 组名 (SYSMON_GROUP) =
客户机用户标识-密码插件 (CLNT_PW_PLUGIN) =
客户机 Kerberos 插件 (CLNT_KRB_PLUGIN) = IBMkrb5
组插件 (GROUP_PLUGIN) =
本地授权的 GSS 插件 (LOCAL_GSSPLUGIN) =
服务器插件方式 (SRV_PLUGIN_MODE) = UNFENCED
GSS 插件的服务器列表 (SRVCON_GSSPLUGIN_LIST) =
服务器用户标识-密码插件 (SRVCON_PW_PLUGIN) =
服务器连接认证 (SRVCON_AUTH) = NOT_SPECIFIED
集群管理器 (CLUSTER_MGR) =
数据库管理器认证 (AUTHENTICATION) = SERVER
备用认证 (ALTERNATE_AUTH_ENC) = NOT_SPECIFIED
没有权限就允许编目 (CATALOG_NOAUTH) = NO
信赖所有客户机 (TRUST_ALLCLNTS) = YES
可信的客户机认证 (TRUST_CLNTAUTH) = CLIENT
绕过联合认证 (FED_NOAUTH) = NO
缺省数据库路径 (DFTDBPATH) = D:
数据库监视器堆大小(4KB) (MON_HEAP_SZ) = AUTOMATIC(333)
“Java 虚拟机”堆大小(4KB) (JAVA_HEAP_SZ) = 2048
审计缓冲区大小(4KB) (AUDIT_BUF_SZ) = 0
实例共享内存(4KB)的大小 (INSTANCE_MEMORY) = 524288
备份缓冲区缺省大小(4KB) (BACKBUFSZ) = 2048
复原缓冲区缺省大小(4KB) (RESTBUFSZ) = 1024
代理程序的堆栈大小 (AGENT_STACK_SZ) = 64
最小已落实专用内存(4KB) (MIN_PRIV_MEM) = 128
专用内存阈值(4KB) (PRIV_MEM_THRESH) = 20000
排序堆阈值(4KB) (SHEAPTHRES) = 0
目录高速缓存支持 (DIR_CACHE) = YES
应用程序支持层堆大小(4KB) (ASLHEAPSZ) = 60
最大请求者 I/O 块大小(以字节计) (RQRIOBLK) = 32767
查询堆大小(4KB) (QUERY_HEAP_SZ) = 1000
已调速实用程序对工作负载的影响 (UTIL_IMPACT_LIM) = 10
代理程序的优先级 (AGENTPRI) = SYSTEM
代理程序池大小 (NUM_POOLAGENTS) = AUTOMATIC(5000)
池中的初始代理程序数 (NUM_INITAGENTS) = 0
最大协调代理程序数 (MAX_COORDAGENTS) = AUTOMATIC(16000)
最大客户机连接数 (MAX_CONNECTIONS) = AUTOMATIC(MAX_COORDAGENTS)
保留受防护的进程 (KEEPFENCED) = YES
合用受防护的进程的数目 (FENCED_POOL) = AUTOMATIC(MAX_COORDAGENTS)
受防护的进程的初始数目 (NUM_INITFENCED) = 0
索引重新创建时间和重做索引构建 (INDEXREC) = RESTART
事务管理器数据库名称 (TM_DATABASE) = 1ST_CONN
事务再同步时间间隔(秒) (RESYNC_INTERVAL) = 180
SPM 名称 (SPM_NAME) = SERV_A1
SPM 日志大小 (SPM_LOG_FILE_SZ) = 256
SPM 再同步代理程序限制 (SPM_MAX_RESYNC) = 20
SPM 日志路径 (SPM_LOG_PATH) =
NetBIOS 工作站名 (NNAME) =
TCP/IP 服务名称 (SVCENAME) = db2c_DB2
发现方式 (DISCOVER) = SEARCH
发现服务器实例 (DISCOVER_INST) = ENABLE
SSL 服务器 keydb 文件 (SSL_SVR_KEYDB) =
SSL 服务器隐藏文件 (SSL_SVR_STASH) =
SSL 服务器证书标签 (SSL_SVR_LABEL) =
SSL 服务名称 (SSL_SVCENAME) =
SSL 密码规范 (SSL_CIPHERSPECS) =
SSL 版本 (SSL_VERSIONS) =
SSL 客户机 keydb 文件 (SSL_CLNT_KEYDB) =
SSL 客户机隐藏文件 (SSL_CLNT_STASH) =
最大查询并行度 (MAX_QUERYDEGREE) = ANY
启用分区内并行性 (INTRA_PARALLEL) = NO
内部通信缓冲区数(4KB) (FCM_NUM_BUFFERS) = AUTOMATIC(1024)
内部通信信道数 (FCM_NUM_CHANNELS) = AUTOMATIC(512)
db2start/db2stop 超时(分钟) (START_STOP_TIME) = 10
最佳答案 ( 回答者: gzOne2Free )
我看你的DBM配置“实例共享内存(4KB)的大小 (INSTANCE_MEMORY) = 524288
”就已经有2个GB的内存了。你的windows服务器总共有多少的内存呢?另外,32位的windows,如果不是企业版的,只支持4G内存,实际只有3.6G左右;而且32位的windows不管认到多少内存,DB2都只能够用4GB,这是32位操作系统的限制。并发量大的数据库一定要有足够的内存和IO性能。
根据你的配置,估计已经达到操作系统的上限了。
另外,估计你的环境的SQL大量使用了实参,导致占用大量的Package Cache。
主题回复
foryuling 2009-9-30 08:291# 引用 get db cfg 发出来看看
start2000 2009-9-30 09:252# 引用 另外db2 get snapshot for db on XJS2看看
Package cache lookups =
Package cache inserts =
Package cache overflows =
huangxl 2009-9-30 15:373# 引用 1. db2 get db cfg | show detail
2. 查看DATABASE_memory 是否为automatic
3.查看你的pckcachesz的值,建议设置为automatic,让stmm来灵活动态的调整管理你的内存;
hongxin571 2009-10-9 13:334# 编辑 引用 节点号 = 0
第一个活动日志的文件号 = 15
最后一个活动日志的文件号 = 14
当前活动日志的文件号 = 16
正被归档的日志的文件号 = 不适用
程序包高速缓存查询 = 9411115
程序包高速缓存插入 = 1273662
程序包高速缓存溢出 = 0
程序包高速缓存高水位标记(以字节计) = 397329035
应用程序节查找 = 28189655
应用程序节插入 = 7778009
目录高速缓存查询 = 3997518
目录高速缓存插入 = 138
目录高速缓存溢出 = 0
目录高速缓存高水位标记 = 1434731
目录高速缓存统计信息大小 = 0
工作空间信息
散列连接数 = 547400
散列循环数 = 11
散列连接溢出数 = 35705
小散列连接溢出数 = 58
后阈值散列连接(共享内存) = 863
活动散列连接 = 0
OLAP 函数的数目 = 0
发生溢出的 OLAP 函数的数目 = 0
处于活动状态的 OLAP 函数的数目 = 0
解决方法: 2009-10-9 13:355# 编辑 引用 DATABASE_memory 是否为automatic 这个是自动的,因达到最大限制就宕掉;了,目前采用的是32位的
2009-10-9 13:466# 编辑 引用 应用程序有个sql进行数据库的间隔0.1秒的扫描程序,里面有以当前系统时间入参的,拼接起来的sql,就是每个sql都不同,就造成了Package Cache 的不断膨胀到溢出
文章作者: Lee
本文地址: https://www.pomelolee.com/491.html
除非注明,Pomelo Lee文章均为原创,转载请以链接形式标明本文地址
一条评论 to 遭遇db2频繁报内存不足的OS错误勘误解决方法
有缓存机制不?
Leave a comment
Search
相关文章
热门文章
最新文章
文章分类
- ajax (10)
- algorithm-learn (3)
- Android (6)
- as (3)
- computer (85)
- Database (30)
- disucz (4)
- enterprise (1)
- erlang (2)
- flash (5)
- golang (3)
- html5 (18)
- ios (4)
- JAVA-and-J2EE (186)
- linux (143)
- mac (10)
- movie-music (11)
- pagemaker (36)
- php (50)
- spring-boot (2)
- Synology群晖 (2)
- Uncategorized (6)
- unity (1)
- webgame (15)
- wordpress (33)
- work-other (2)
- 低代码 (1)
- 体味生活 (40)
- 前端 (21)
- 大数据 (8)
- 游戏开发 (9)
- 爱上海 (19)
- 读书 (4)
- 软件 (3)
2009 年 10 月 11 日