db2mtrk and instance crash

[Jean-Marc Blaise]

Hi,

I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
The test case:

db2set DB2_FMP_COMM_HE APSZ = 0
db2stop
db2start
db2mtrk -i -d -p -v ==> Instance is crashed.

Btw, we can say that the db2mtrk cannot be totally trusted, because this 20
Mb shared memory used by DB2 is not tracked by the tool.

Regards,

Jean-Marc

[Sean McKeough]

Re: db2mtrk and instance crash

I've passed this along to the developers...wi ll let you know what I find
out.

Jean-Marc Blaise wrote:[color=blue]
> Hi,
>
> I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
> The test case:
>
> db2set DB2_FMP_COMM_HE APSZ = 0
> db2stop
> db2start
> db2mtrk -i -d -p -v ==> Instance is crashed.
>
> Btw, we can say that the db2mtrk cannot be totally trusted, because this 20
> Mb shared memory used by DB2 is not tracked by the tool.
>
> Regards,
>
> Jean-Marc
>
>[/color]

[PM \(pm3iinc-nospam\)]

Re: db2mtrk and instance crash

del db2trc1.*
db2trc db2 on
db2mtrk -i
db2trc dmp db2trc1.dmp
db2trc off
db2trc fmt db2trc1.dmp db2trc1.fmt




I:\DB2USR>del db2trc1.*

I:\DB2USR>db2tr c db2 on
Trace is turned on

I:\DB2USR>db2mt rk -i
Tracking Memory on: 2003/12/11 at 10:01:30

Memory for instance

appctlh appctlh appctlh appctlh appctlh utilh pckcacheh
16.0K 16.0K 16.0K 16.0K 80.0K 16.0K 480.0K

catcacheh bph bph bph bph bph bph
160.0K 7.9M 1.1M 592.0K 336.0K 208.0K 144.0K

lockh dbh monh other fcmbp
272.0K 3.2M 176.0K 52.4M 16.6M


I:\DB2USR>db2tr c dmp db2trc1.dmp
Trace has been dumped to file "db2trc1.dm p"

I:\DB2USR>db2tr c off
Trace is turned off

I:\DB2USR>db2tr c fmt db2trc1.dmp db2trc1.fmt
Trace truncated : NO
Trace wrapped : NO
Total number of trace records : 9393
Number of trace records formatted : 9393

I:\DB2USR>finds tr /i "fenced" db2trc1.fmt

I:\DB2USR>find /i "fenced" db2trc1.fmt

---------- DB2TRC1.FMT

I:\DB2USR>find /i "fmp" db2trc1.fmt

---------- DB2TRC1.FMT

I:\DB2USR>find /i "snap" db2trc1.fmt

---------- DB2TRC1.FMT
215 entry DB2 oper system services GetSnapshotBuff er fnc (1.3.15.25.0)
2430 exit DB2 oper system services GetSnapshotBuff er fnc (2.3.15.25.0)
2431 entry DB2 oper system services GetSnapshot fnc (1.3.15.24.0)
2440 entry DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
(1.3.13.122.0)
5150 exit DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
(2.3.13.122.0)
5155 exit DB2 oper system services GetSnapshot fnc (2.3.15.24.0)
5159 entry DB2 oper system services GetSnapshotBuff er fnc (1.3.15.25.0)
5849 exit DB2 oper system services GetSnapshotBuff er fnc (2.3.15.25.0)
5850 entry DB2 oper system services GetSnapshot fnc (1.3.15.24.0)
5859 entry DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
(1.3.13.122.0)
8657 exit DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
(2.3.13.122.0)
8662 exit DB2 oper system services GetSnapshot fnc (2.3.15.24.0)


DB2 SELECT ROUTINENAME FROM SYSCAT.ROUTINES WHERE FENCED='Y'

I see snapshots in fenced='y'.
Not sure if it's the db2mtrk or health monitor or something else that calls
them. (see in trace)
You can x-ref db2trc/routines with db2diag.log to see what happened.

I agree with you that an instance crash is not what one would expect.

btw, do you have (HEALTH_MON) = ON ?

PM


"Jean-Marc Blaise" <nobody@nowhere .com> a écrit dans le message de
news:br95q5$ql1 $1@news-reader3.wanadoo .fr...[color=blue]
> Hi,
>
> I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
> The test case:
>
> db2set DB2_FMP_COMM_HE APSZ = 0
> db2stop
> db2start
> db2mtrk -i -d -p -v ==> Instance is crashed.
>
> Btw, we can say that the db2mtrk cannot be totally trusted, because this[/color]
20[color=blue]
> Mb shared memory used by DB2 is not tracked by the tool.
>
> Regards,
>
> Jean-Marc
>
>[/color]

[Jean-Marc Blaise]

Re: db2mtrk and instance crash

PM, in my case, the db is not active. HEALTH_MON is OFF.
Cheers,

Jean-Marc

"PM (pm3iinc-nospam)" <PM(pm3iinc-nospam)@sympati co.ca> a écrit dans le
message de news:Uy%Bb.6787 $aF2.847196@new s20.bellglobal. com...[color=blue]
> del db2trc1.*
> db2trc db2 on
> db2mtrk -i
> db2trc dmp db2trc1.dmp
> db2trc off
> db2trc fmt db2trc1.dmp db2trc1.fmt
>
>
>
>
> I:\DB2USR>del db2trc1.*
>
> I:\DB2USR>db2tr c db2 on
> Trace is turned on
>
> I:\DB2USR>db2mt rk -i
> Tracking Memory on: 2003/12/11 at 10:01:30
>
> Memory for instance
>
> appctlh appctlh appctlh appctlh appctlh utilh pckcacheh
> 16.0K 16.0K 16.0K 16.0K 80.0K 16.0K 480.0K
>
> catcacheh bph bph bph bph bph bph
> 160.0K 7.9M 1.1M 592.0K 336.0K 208.0K 144.0K
>
> lockh dbh monh other fcmbp
> 272.0K 3.2M 176.0K 52.4M 16.6M
>
>
> I:\DB2USR>db2tr c dmp db2trc1.dmp
> Trace has been dumped to file "db2trc1.dm p"
>
> I:\DB2USR>db2tr c off
> Trace is turned off
>
> I:\DB2USR>db2tr c fmt db2trc1.dmp db2trc1.fmt
> Trace truncated : NO
> Trace wrapped : NO
> Total number of trace records : 9393
> Number of trace records formatted : 9393
>
> I:\DB2USR>finds tr /i "fenced" db2trc1.fmt
>
> I:\DB2USR>find /i "fenced" db2trc1.fmt
>
> ---------- DB2TRC1.FMT
>
> I:\DB2USR>find /i "fmp" db2trc1.fmt
>
> ---------- DB2TRC1.FMT
>
> I:\DB2USR>find /i "snap" db2trc1.fmt
>
> ---------- DB2TRC1.FMT
> 215 entry DB2 oper system services GetSnapshotBuff er fnc (1.3.15.25.0)
> 2430 exit DB2 oper system services GetSnapshotBuff er fnc (2.3.15.25.0)
> 2431 entry DB2 oper system services GetSnapshot fnc (1.3.15.24.0)
> 2440 entry DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
> (1.3.13.122.0)
> 5150 exit DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
> (2.3.13.122.0)
> 5155 exit DB2 oper system services GetSnapshot fnc (2.3.15.24.0)
> 5159 entry DB2 oper system services GetSnapshotBuff er fnc (1.3.15.25.0)
> 5849 exit DB2 oper system services GetSnapshotBuff er fnc (2.3.15.25.0)
> 5850 entry DB2 oper system services GetSnapshot fnc (1.3.15.24.0)
> 5859 entry DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
> (1.3.13.122.0)
> 8657 exit DB2 database monitor sqm___sqlm_send _snapshot_db2ra fnc
> (2.3.13.122.0)
> 8662 exit DB2 oper system services GetSnapshot fnc (2.3.15.24.0)
>
>
> DB2 SELECT ROUTINENAME FROM SYSCAT.ROUTINES WHERE FENCED='Y'
>
> I see snapshots in fenced='y'.
> Not sure if it's the db2mtrk or health monitor or something else that[/color]
calls[color=blue]
> them. (see in trace)
> You can x-ref db2trc/routines with db2diag.log to see what happened.
>
> I agree with you that an instance crash is not what one would expect.
>
> btw, do you have (HEALTH_MON) = ON ?
>
> PM
>
>
> "Jean-Marc Blaise" <nobody@nowhere .com> a écrit dans le message de
> news:br95q5$ql1 $1@news-reader3.wanadoo .fr...[color=green]
> > Hi,
> >
> > I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
> > The test case:
> >
> > db2set DB2_FMP_COMM_HE APSZ = 0
> > db2stop
> > db2start
> > db2mtrk -i -d -p -v ==> Instance is crashed.
> >
> > Btw, we can say that the db2mtrk cannot be totally trusted, because this[/color]
> 20[color=green]
> > Mb shared memory used by DB2 is not tracked by the tool.
> >
> > Regards,
> >
> > Jean-Marc
> >
> >[/color]
>
>[/color]

[Sean McKeough]

Re: db2mtrk and instance crash

FYI, we've reproduced this here, and fix is being put in for 8.2.

Sean McKeough wrote:[color=blue]
> I've passed this along to the developers...wi ll let you know what I find
> out.
>
> Jean-Marc Blaise wrote:
>[color=green]
>> Hi,
>>
>> I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
>> The test case:
>>
>> db2set DB2_FMP_COMM_HE APSZ = 0
>> db2stop
>> db2start
>> db2mtrk -i -d -p -v ==> Instance is crashed.
>>
>> Btw, we can say that the db2mtrk cannot be totally trusted, because
>> this 20
>> Mb shared memory used by DB2 is not tracked by the tool.
>>
>> Regards,
>>
>> Jean-Marc
>>
>>[/color][/color]

[Jean-Marc Blaise]

Re: db2mtrk and instance crash

Thanks Sean.

What about the memory not accounted by db2mtrk ? If DB2_FMP_COMM_HE APSZ is
not set, DB2 UDB will allocate a 20 Mb segment, and the execution of fenced
stored procedure will consume some memory. But the db2mtrk seems not report
increase of memory usage, except at the package cache and dbheap level.

Shouldn't this memory from DB2_FMP_COMM_HE APSZ accounted somewhere, at the
instance level ?

Regards,

Jean-Marc

"Sean McKeough" <mckeough@nospa m.ca.ibm.com> a écrit dans le message de
news:brkks9$718 $1@hanover.toro lab.ibm.com...[color=blue]
> FYI, we've reproduced this here, and fix is being put in for 8.2.
>
> Sean McKeough wrote:[color=green]
> > I've passed this along to the developers...wi ll let you know what I find
> > out.
> >
> > Jean-Marc Blaise wrote:
> >[color=darkred]
> >> Hi,
> >>
> >> I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
> >> The test case:
> >>
> >> db2set DB2_FMP_COMM_HE APSZ = 0
> >> db2stop
> >> db2start
> >> db2mtrk -i -d -p -v ==> Instance is crashed.
> >>
> >> Btw, we can say that the db2mtrk cannot be totally trusted, because
> >> this 20
> >> Mb shared memory used by DB2 is not tracked by the tool.
> >>
> >> Regards,
> >>
> >> Jean-Marc
> >>
> >>[/color][/color][/color]

[Sean McKeough]

Re: db2mtrk and instance crash

Yes, I'm expecting this should be part of the change...I'll confirm with
the developer.

Jean-Marc Blaise wrote:
[color=blue]
> Thanks Sean.
>
> What about the memory not accounted by db2mtrk ? If DB2_FMP_COMM_HE APSZ is
> not set, DB2 UDB will allocate a 20 Mb segment, and the execution of fenced
> stored procedure will consume some memory. But the db2mtrk seems not report
> increase of memory usage, except at the package cache and dbheap level.
>
> Shouldn't this memory from DB2_FMP_COMM_HE APSZ accounted somewhere, at the
> instance level ?
>
> Regards,
>
> Jean-Marc
>
> "Sean McKeough" <mckeough@nospa m.ca.ibm.com> a écrit dans le message de
> news:brkks9$718 $1@hanover.toro lab.ibm.com...
>[color=green]
>>FYI, we've reproduced this here, and fix is being put in for 8.2.
>>
>>Sean McKeough wrote:
>>[color=darkred]
>>>I've passed this along to the developers...wi ll let you know what I find
>>>out.
>>>
>>>Jean-Marc Blaise wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
>>>>The test case:
>>>>
>>>>db2set DB2_FMP_COMM_HE APSZ = 0
>>>>db2stop
>>>>db2start
>>>>db2mtrk -i -d -p -v ==> Instance is crashed.
>>>>
>>>>Btw, we can say that the db2mtrk cannot be totally trusted, because
>>>>this 20
>>>>Mb shared memory used by DB2 is not tracked by the tool.
>>>>
>>>>Regards,
>>>>
>>>>Jean-Marc
>>>>
>>>>[/color][/color]
>
>
>[/color]

[Sean McKeough]

Re: db2mtrk and instance crash

The developer is aware if this missing heap info, and is going to look
at adding it in a subesequent release...I have an internal defect open
to track the requirement with.

Sean McKeough wrote:[color=blue]
> FYI, we've reproduced this here, and fix is being put in for 8.2.
>
> Sean McKeough wrote:
>[color=green]
>> I've passed this along to the developers...wi ll let you know what I
>> find out.
>>
>> Jean-Marc Blaise wrote:
>>[color=darkred]
>>> Hi,
>>>
>>> I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
>>> The test case:
>>>
>>> db2set DB2_FMP_COMM_HE APSZ = 0
>>> db2stop
>>> db2start
>>> db2mtrk -i -d -p -v ==> Instance is crashed.
>>>
>>> Btw, we can say that the db2mtrk cannot be totally trusted, because
>>> this 20
>>> Mb shared memory used by DB2 is not tracked by the tool.
>>>
>>> Regards,
>>>
>>> Jean-Marc
>>>
>>>[/color][/color][/color]

[Jean-Marc Blaise]

Re: db2mtrk and instance crash

Thanks for your feedback, Sean.
JM

"Sean McKeough" <mckeough@nospa m.ca.ibm.com> a écrit dans le message de
news:brpp3e$stv $1@hanover.toro lab.ibm.com...[color=blue]
> The developer is aware if this missing heap info, and is going to look
> at adding it in a subesequent release...I have an internal defect open
> to track the requirement with.
>
> Sean McKeough wrote:[color=green]
> > FYI, we've reproduced this here, and fix is being put in for 8.2.
> >
> > Sean McKeough wrote:
> >[color=darkred]
> >> I've passed this along to the developers...wi ll let you know what I
> >> find out.
> >>
> >> Jean-Marc Blaise wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm on Linux Intel, V8.1 / FP4. I have an instance crash.
> >>> The test case:
> >>>
> >>> db2set DB2_FMP_COMM_HE APSZ = 0
> >>> db2stop
> >>> db2start
> >>> db2mtrk -i -d -p -v ==> Instance is crashed.
> >>>
> >>> Btw, we can say that the db2mtrk cannot be totally trusted, because
> >>> this 20
> >>> Mb shared memory used by DB2 is not tracked by the tool.
> >>>
> >>> Regards,
> >>>
> >>> Jean-Marc
> >>>
> >>>[/color][/color][/color]