The db2diag.log entry logged at db2start time may report
incorrect resource limit.
Here is an example on AIX, which reports "Cur core size (bytes)"
as 0xFFFFFFFF even though the actual core limit is larger than
4GB:
2010-03-16-14.07.28.539323+540 E635748821A1311 LEVEL: Event
PID : 213484 TID : 258 PROC : db2sysc
INSTANCE: db2inst1 NODE : 000
EDUID : 258
FUNCTION: DB2 UDB, base sys utilities, DB2main, probe:1
START : DB2 DBM
...(snip)...
Cur cpu time limit (seconds) = 0x7FFFFFFFFFFFFFFF
Cur file size limit (bytes) = 0x7FFFFFFFFFFFFFFF
Cur data size (bytes) = 0x7FFFFFFFFFFFFFFF
Cur stack size (bytes) = 0x7FFFFFFFFFFFFFFF
Cur core size (bytes) = 0x00000000FFFFFFFF
Cur memory size (bytes) = 0x7FFFFFFFFFFFFFFF
nofiles (descriptors) = 0x7FFFFFFFFFFFFFFF
Here is another example on Linux, which reports the limit value
with 8-byte width:
$ ulimit -d 4194305 # 4GB + 1KB
$ ulimit -a | grep data
data seg size (kbytes, -d) 4194305
2010-12-15-18.36.38.364001+540 E69107E1400 LEVEL: Event
PID : 19055 TID : 183106529632 PROC :
db2syscr
INSTANCE: v95fp5 NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2main, probe:1
START : DB2 DBM
DATA #1 : Build Level, 152 bytes
Instance "v95fp5" uses "64" bits and DB2 code release "SQL09055"
with level identifier "06060107".
Informational tokens are "DB2 v9.5.0.5", "s091123", "MI00316",
Fix Pack "5".
...(snip)...
Cur cpu time limit (seconds) = 0xFFFFFFFF
Cur file size limit (bytes) = 0xFFFFFFFF
Cur data size (bytes) = 0x00000400
Cur stack size (bytes) = 0xFFFFFFFF
Cur core size (bytes) = 0xFFFFFFFF
Cur memory size (bytes) = 0xFFFFFFFF
nofiles (descriptors) = 0x00000800
On Solaris platform, the resource limits may not be written out.
These are just display problem and do not affect the actual
resource limit. |
