RFE request for session details during virtual shm
Alexandre asked people to vote for an RFE that would log which session triggered allocation of a new virtual shared memory segment, so he could track down sessions causing abnormal memory growth on a busy OLTP box. Fernando objected that the triggering session isn't necessarily the memory hog (and some allocations are proactive, with no SID), suggesting instead a quick way to list top memory-consuming sessions, called from ALARMPROGRAM. Art wanted an alarm event on segment allocation; Jacques noted ALRM_ALL_EVENTS=1 plus SHMVIRT_ALLOCSEG (class 24, event 24003) appears to raise an alarm, and offered to look for a script. Paul uses Nagios polling, acknowledging it's too coarse, and mentioned onmode -I 22/28 as a (risky) option. No definitive solution or RFE outcome is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hello. I think this might be a very useful RFE, in order to help us to identify abnormal memory session usage, in OLTP systems of high ammount of concurrent sessions (ad-hoc applications). If anyone like, please vote it... https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730 Regards. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10 IBM Information Management Informix Technical Professional IBM Certified Developer - Informix Genero BRIUG website administrator Informix independent consultant
I'm not sure if I completely understand the request. But apparently you
want the SID of the session that caused the new memory segment to be added.
But this does not necessarily means that that session is the one consuming
more memory. Specially in an high activity system. Let's assume SID= y is
doing something nasty and it consumes a lot of memory. At time T0 it
allocates a large chunk of memory for a sort or whatever. Between T0 and T1
a lot of other sessions allocate small ammounts of blocks. At T1 a
different session (SID=y) needs some memory that isn't available, and that
triggers a new segment allocation. You'd get SID=y and not SID=x in the
messge.
Beside that, systems can now allocate memory in pro-active mode (meaning no
SID is associated with it).
What I think you need is an expedite way of showing which sessions are
consuming more memory at a specific time (onstat -u is limmited for that,
and I do agree some other option would be interesting). Once you have a way
to do that (and we can create a script to do what you mention) you just
have to call it in the ALARMPROGRAM script when the event is the one you're
looking for...
Regards
On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
wrote:
> Hello.
> I think this might be a very useful RFE, in order to help us to identify
> abnormal memory session usage, in OLTP systems of high ammount of
> concurrent
> sessions (ad-hoc applications).
>
> If anyone like, please vote it...
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730
>
> Regards.
>
> Alexandre Marini
> IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
>
> IBM Information Management Informix Technical Professional
>
> IBM Certified Developer - Informix Genero
> BRIUG website administrator
> Informix independent consultant
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--001a113fd708c081b205092beeb0
Fernando:
A useful way to handle this would be to add an alert/alarm event for shared
memory allocation then we could trap is if needed and do whatever makes
sense for the particular installation. Currently we can only catch
out-of-memory conditions when it is too late.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Mon, Dec 1, 2014 at 1:40 PM, Fernando Nunes <domusonline@gmail.com>
wrote:
> I'm not sure if I completely understand the request. But apparently you
> want the SID of the session that caused the new memory segment to be added.
> But this does not necessarily means that that session is the one consuming
> more memory. Specially in an high activity system. Let's assume SID= y is
> doing something nasty and it consumes a lot of memory. At time T0 it
> allocates a large chunk of memory for a sort or whatever. Between T0 and T1
> a lot of other sessions allocate small ammounts of blocks. At T1 a
> different session (SID=y) needs some memory that isn't available, and that
> triggers a new segment allocation. You'd get SID=y and not SID=x in the
> messge.
>
> Beside that, systems can now allocate memory in pro-active mode (meaning no
> SID is associated with it).
>
> What I think you need is an expedite way of showing which sessions are
> consuming more memory at a specific time (onstat -u is limmited for that,
> and I do agree some other option would be interesting). Once you have a way
> to do that (and we can create a script to do what you mention) you just
> have to call it in the ALARMPROGRAM script when the event is the one you're
> looking for...
>
> Regards
>
> On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
> wrote:
>
> > Hello.
> > I think this might be a very useful RFE, in order to help us to identify
> > abnormal memory session usage, in OLTP systems of high ammount of
> > concurrent
> > sessions (ad-hoc applications).
> >
> > If anyone like, please vote it...
> >
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730
> >
> > Regards.
> >
> > Alexandre Marini
> > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> >
> > IBM Information Management Informix Technical Professional
> >
> > IBM Certified Developer - Informix Genero
> > BRIUG website administrator
> > Informix independent consultant
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --001a113fd708c081b205092beeb0
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--089e01419d862a606505092cf5fc
I'll have to check. I have customers where I have implemented an alert
whenever a shared memory segment is allocated. But I'm not sure if I did
this using the alert mechanism or a script that monitors the online.log
On Mon, Dec 1, 2014 at 7:53 PM, Art Kagel <art.kagel@gmail.com> wrote:
> Fernando:
>
> A useful way to handle this would be to add an alert/alarm event for shared
> memory allocation then we could trap is if needed and do whatever makes
> sense for the particular installation. Currently we can only catch
> out-of-memory conditions when it is too late.
>
> Art
>
> Art S. Kagel, President and Principal Consultant
> ASK Database Management
> www.askdbmgt.com
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on the IIUG, nor any other organization with which I am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Mon, Dec 1, 2014 at 1:40 PM, Fernando Nunes <domusonline@gmail.com>
> wrote:
>
> > I'm not sure if I completely understand the request. But apparently you
> > want the SID of the session that caused the new memory segment to be
> added.
> > But this does not necessarily means that that session is the one
> consuming
> > more memory. Specially in an high activity system. Let's assume SID= y is
> > doing something nasty and it consumes a lot of memory. At time T0 it
> > allocates a large chunk of memory for a sort or whatever. Between T0 and
> T1
> > a lot of other sessions allocate small ammounts of blocks. At T1 a
> > different session (SID=y) needs some memory that isn't available, and
> that
> > triggers a new segment allocation. You'd get SID=y and not SID=x in the
> > messge.
> >
> > Beside that, systems can now allocate memory in pro-active mode (meaning
> no
> > SID is associated with it).
> >
> > What I think you need is an expedite way of showing which sessions are
> > consuming more memory at a specific time (onstat -u is limmited for that,
> > and I do agree some other option would be interesting). Once you have a
> way
> > to do that (and we can create a script to do what you mention) you just
> > have to call it in the ALARMPROGRAM script when the event is the one
> you're
> > looking for...
> >
> > Regards
> >
> > On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
> > wrote:
> >
> > > Hello.
> > > I think this might be a very useful RFE, in order to help us to
> identify
> > > abnormal memory session usage, in OLTP systems of high ammount of
> > > concurrent
> > > sessions (ad-hoc applications).
> > >
> > > If anyone like, please vote it...
> > >
> >
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730
> > >
> > > Regards.
> > >
> > > Alexandre Marini
> > > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> > >
> > > IBM Information Management Informix Technical Professional
> > >
> > > IBM Certified Developer - Informix Genero
> > > BRIUG website administrator
> > > Informix independent consultant
> > >
> > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --
> > Fernando Nunes
> > Portugal
> >
> > http://informix-technology.blogspot.com
> > My email works... but I don't check it frequently...
> >
> > --001a113fd708c081b205092beeb0
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --089e01419d862a606505092cf5fc
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--001a1140f88eb070e005092ecde4
Hello, Art and Fernando.
Fernando we are aware of this situation, but as Art said, it's exactly what we
want to know. Some detail about which session demanded an additional virtual
shm segment allocation would be a very nice starting point to investigate
further a specific session/program, from the specific time it happened. In
most cases this is happening when we are out of work hours, and it is not some
cron job, so it became a very annoying situation to debug. Even sqltrace would
be hard for us to use, since it is a production box, and we cannot let it
running for so long (limited resources, GE version, etc).
If you can find some utils for us, or some event code for alarmprogram
customization logging this (even in a separate file), it would be very nice.
Thanks, anyway.
Regards.
Alexandre Marini
IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
IBM Information Management Informix Technical Professional
IBM Certified Developer - Informix Genero
BRIUG website administrator
Informix independent consultant
> To: ids@iiug.org
> From: domusonline@gmail.com
> Subject: Re: RFE request for session details during vir.... [34244]
> Date: Mon, 1 Dec 2014 17:05:15 -0500
>
> I'll have to check. I have customers where I have implemented an alert
> whenever a shared memory segment is allocated. But I'm not sure if I did
> this using the alert mechanism or a script that monitors the online.log
>
> On Mon, Dec 1, 2014 at 7:53 PM, Art Kagel <art.kagel@gmail.com> wrote:
>
> > Fernando:
> >
> > A useful way to handle this would be to add an alert/alarm event for shared
> > memory allocation then we could trap is if needed and do whatever makes
> > sense for the particular installation. Currently we can only catch
> > out-of-memory conditions when it is too late.
> >
> > Art
> >
> > Art S. Kagel, President and Principal Consultant
> > ASK Database Management
> > www.askdbmgt.com
> >
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and do not reflect on the IIUG, nor any other organization with which I am
> > associated either explicitly, implicitly, or by inference. Neither do
> > those opinions reflect those of other individuals affiliated with any
> > entity with which I am affiliated nor those of the entities themselves.
> >
> > On Mon, Dec 1, 2014 at 1:40 PM, Fernando Nunes <domusonline@gmail.com>
> > wrote:
> >
> > > I'm not sure if I completely understand the request. But apparently you
> > > want the SID of the session that caused the new memory segment to be
> > added.
> > > But this does not necessarily means that that session is the one
> > consuming
> > > more memory. Specially in an high activity system. Let's assume SID= y is
> > > doing something nasty and it consumes a lot of memory. At time T0 it
> > > allocates a large chunk of memory for a sort or whatever. Between T0 and
> > T1
> > > a lot of other sessions allocate small ammounts of blocks. At T1 a
> > > different session (SID=y) needs some memory that isn't available, and
> > that
> > > triggers a new segment allocation. You'd get SID=y and not SID=x in the
> > > messge.
> > >
> > > Beside that, systems can now allocate memory in pro-active mode (meaning
> > no
> > > SID is associated with it).
> > >
> > > What I think you need is an expedite way of showing which sessions are
> > > consuming more memory at a specific time (onstat -u is limmited for that,
> > > and I do agree some other option would be interesting). Once you have a
> > way
> > > to do that (and we can create a script to do what you mention) you just
> > > have to call it in the ALARMPROGRAM script when the event is the one
> > you're
> > > looking for...
> > >
> > > Regards
> > >
> > > On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
> > > wrote:
> > >
> > > > Hello.
> > > > I think this might be a very useful RFE, in order to help us to
> > identify
> > > > abnormal memory session usage, in OLTP systems of high ammount of
> > > > concurrent
> > > > sessions (ad-hoc applications).
> > > >
> > > > If anyone like, please vote it...
> > > >
> > >
> > https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730
> > > >
> > > > Regards.
> > > >
> > > > Alexandre Marini
> > > > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> > > >
> > > > IBM Information Management Informix Technical Professional
> > > >
> > > > IBM Certified Developer - Informix Genero
> > > > BRIUG website administrator
> > > > Informix independent consultant
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
*******************************************************************************
> > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > >
> > > >
> > >
> > > --
> > > Fernando Nunes
> > > Portugal
> > >
> > > http://informix-technology.blogspot.com
> > > My email works... but I don't check it frequently...
> > >
> > > --001a113fd708c081b205092beeb0
> > >
> > >
> > >
> > >
> >
> >
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --089e01419d862a606505092cf5fc
> >
> >
> >
> >
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --001a1140f88eb070e005092ecde4
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Original Post:
I'm not sure if I completely understand the request. But apparently you
want the SID of the session that caused the new memory segment to be added.
But this does not necessarily means that that session is the one consuming
more memory. Specially in an high activity system. Let's assume SID= y is
doing something nasty and it consumes a lot of memory. At time T0 it
allocates a large chunk of memory for a sort or whatever. Between T0 and T1
a lot of other sessions allocate small ammounts of blocks. At T1 a
different session (SID=y) needs some memory that isn't available, and that
triggers a new segment allocation. You'd get SID=y and not SID=x in the
messge.
Beside that, systems can now allocate memory in pro-active mode (meaning no
SID is associated with it).
What I think you need is an expedite way of showing which sessions are
consuming more memory at a specific time (onstat -u is limmited for that,
and I do agree some other option would be interesting). Once you have a way
to do that (and we can create a script to do what you mention) you just
have to call it in the ALARMPROGRAM script when the event is the one you're
looking for...
Regards
On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
wrote:
> Hello.
> I think this might be a very useful RFE, in order to help us to identify
> abnormal memory session usage, in OLTP systems of high ammount of
> concurrent
> sessions (ad-hoc applications).
>
> If anyone like, please vote it...
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730
>
> Regards.
>
> Alexandre Marini
> IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
>
> IBM Information Management Informix Technical Professional
>
> IBM Certified Developer - Informix Genero
> BRIUG website administrator
> Informix independent consultant
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
Reply:
If I'm reading code correctly, it looks like if you have ALRM_ALL_EVENTS set
to 1 in your $ONCONFIG then adding a segment would generate an alarm. I missed
noticing the alarm number/type/severity etc...but it did look like it called
invoke_alarm() so something would be generated which could do something
specific in the alarm program. Otherwise, it's not too hard to write a script
which detects when segments are added and then could kick off onstats. I think
I might have one of these already, I'll see if I can't find it.
Jacques Renaut
IBM Informix Advanced Support
APD Team
We use Nagios to track when a number segment is added and spawn a script to
capture stuff. It's not ideal as Nagios runs every xx mins so it doesn't
capture the 'all hell breaking loose' memory requrements but ...
Cheers
Paul
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Fernando Nunes
> Sent: Monday, December 01, 2014 12:40 PM
> To: ids@iiug.org
> Subject: Re: RFE request for session details during vir.... [34242]
>
> I'm not sure if I completely understand the request. But apparently you
> want the SID of the session that caused the new memory segment to be
> added.
> But this does not necessarily means that that session is the one consuming
> more memory. Specially in an high activity system. Let's assume SID= y is
> doing something nasty and it consumes a lot of memory. At time T0 it
> allocates a large chunk of memory for a sort or whatever. Between T0 and
T1
> a lot of other sessions allocate small ammounts of blocks. At T1 a
> different session (SID=y) needs some memory that isn't available, and that
> triggers a new segment allocation. You'd get SID=y and not SID=x in the
> messge.
>
> Beside that, systems can now allocate memory in pro-active mode (meaning
> no
> SID is associated with it).
>
> What I think you need is an expedite way of showing which sessions are
> consuming more memory at a specific time (onstat -u is limmited for that,
> and I do agree some other option would be interesting). Once you have a
> way
> to do that (and we can create a script to do what you mention) you just
> have to call it in the ALARMPROGRAM script when the event is the one
> you're
> looking for...
>
> Regards
>
> On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
> wrote:
>
> > Hello.
> > I think this might be a very useful RFE, in order to help us to identify
> > abnormal memory session usage, in OLTP systems of high ammount of
> > concurrent
> > sessions (ad-hoc applications).
> >
> > If anyone like, please vote it...
> >
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&C
> R_ID=62730
> >
> > Regards.
> >
> > Alexandre Marini
> > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> >
> > IBM Information Management Informix Technical Professional
> >
> > IBM Certified Developer - Informix Genero
> > BRIUG website administrator
> > Informix independent consultant
> >
> >
> >
> >
> **********************************************************
> *********************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --001a113fd708c081b205092beeb0
>
>
> **********************************************************
> *********************
> Forum Note: Use "Reply" to post a response in the discussion forum.
Thanks a lot, Jacques.
From the manual page, SHMVIRT_ALLOCSEG it says that:
alarm_level: Optional. An integer value
from 1 to 5 that specifies the level of the event alarm to raise:
1 = Not noteworthy, 2 = Information, 3 = Attention (Default), 4 =
Emergency, 5 = Fatal. The event alarm has a class ID of
24 and an event ID of 24003.
Mentioned parameters are both in defaults values, from
onconfig:SHMVIRT_ALLOCSEG 0,3
ALRM_ALL_EVENTS 0
What we really need would be the session that demanded an extra ammount of
memory to the engine, and caused it to allocate an additional virtual shm
segment. That would be perfect for us to identify which session is causing
extra memory demands in this box.
We are also trying to lower SHMTOTAL, but that could also not tell us (and
most probably won't), which session was
requesting a big amount of mem (when the engine will stop accepting new
connections, it will be too late to identify the big memory allocation
session).
Thanks anyway, Jacques, if you can find something, please advice.
Regards.
Alexandre Marini
IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
IBM Information Management Informix Technical Professional
IBM Certified Developer - Informix Genero
BRIUG website administrator
Informix independent consultant
> To: ids@iiug.org
> From: jrenaut@us.ibm.com
> Subject: Re: RFE request for session details during virtual [34251]
> Date: Tue, 2 Dec 2014 09:40:38 -0500
>
> Original Post:
>
> I'm not sure if I completely understand the request. But apparently you
> want the SID of the session that caused the new memory segment to be added.
> But this does not necessarily means that that session is the one consuming
> more memory. Specially in an high activity system. Let's assume SID= y is
> doing something nasty and it consumes a lot of memory. At time T0 it
> allocates a large chunk of memory for a sort or whatever. Between T0 and T1
> a lot of other sessions allocate small ammounts of blocks. At T1 a
> different session (SID=y) needs some memory that isn't available, and that
> triggers a new segment allocation. You'd get SID=y and not SID=x in the
> messge.
>
> Beside that, systems can now allocate memory in pro-active mode (meaning no
> SID is associated with it).
>
> What I think you need is an expedite way of showing which sessions are
> consuming more memory at a specific time (onstat -u is limmited for that,
> and I do agree some other option would be interesting). Once you have a way
> to do that (and we can create a script to do what you mention) you just
> have to call it in the ALARMPROGRAM script when the event is the one you're
> looking for...
>
> Regards
>
> On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
> wrote:
>
> > Hello.
> > I think this might be a very useful RFE, in order to help us to identify
> > abnormal memory session usage, in OLTP systems of high ammount of
> > concurrent
> > sessions (ad-hoc applications).
> >
> > If anyone like, please vote it...
> > https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62730
> >
> > Regards.
> >
> > Alexandre Marini
> > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> >
> > IBM Information Management Informix Technical Professional
> >
> > IBM Certified Developer - Informix Genero
> > BRIUG website administrator
> > Informix independent consultant
> >
> >
> >
> >
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> Reply:
>
> If I'm reading code correctly, it looks like if you have ALRM_ALL_EVENTS set
> to 1 in your $ONCONFIG then adding a segment would generate an alarm. I
missed
> noticing the alarm number/type/severity etc...but it did look like it called
> invoke_alarm() so something would be generated which could do something
> specific in the alarm program. Otherwise, it's not too hard to write a script
> which detects when segments are added and then could kick off onstats. I
think
> I might have one of these already, I'll see if I can't find it.
>
> Jacques Renaut
> IBM Informix Advanced Support
> APD Team
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Yes, Paul, indeed. The issue is to catch things as soon as they happen.
Any monitor tool (including an online.log parser), would not do this trick.
Let's see if Fernando or Jacques can find something that could help us on
this....
Thanks for the tips.
Regards.
Alexandre Marini
IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
IBM Information Management Informix Technical Professional
IBM Certified Developer - Informix Genero
BRIUG website administrator
Informix independent consultant
> To: ids@iiug.org
> From: paul@oninit.com
> Subject: RE: RFE request for session details during vir.... [34252]
> Date: Tue, 2 Dec 2014 09:49:47 -0500
>
> We use Nagios to track when a number segment is added and spawn a script to
> capture stuff. It's not ideal as Nagios runs every xx mins so it doesn't
> capture the 'all hell breaking loose' memory requrements but ...
>
> Cheers
> Paul
>
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Fernando Nunes
> > Sent: Monday, December 01, 2014 12:40 PM
> > To: ids@iiug.org
> > Subject: Re: RFE request for session details during vir.... [34242]
> >
> > I'm not sure if I completely understand the request. But apparently you
> > want the SID of the session that caused the new memory segment to be
> > added.
> > But this does not necessarily means that that session is the one consuming
> > more memory. Specially in an high activity system. Let's assume SID= y is
> > doing something nasty and it consumes a lot of memory. At time T0 it
> > allocates a large chunk of memory for a sort or whatever. Between T0 and
> T1
> > a lot of other sessions allocate small ammounts of blocks. At T1 a
> > different session (SID=y) needs some memory that isn't available, and that
> > triggers a new segment allocation. You'd get SID=y and not SID=x in the
> > messge.
> >
> > Beside that, systems can now allocate memory in pro-active mode (meaning
> > no
> > SID is associated with it).
> >
> > What I think you need is an expedite way of showing which sessions are
> > consuming more memory at a specific time (onstat -u is limmited for that,
> > and I do agree some other option would be interesting). Once you have a
> > way
> > to do that (and we can create a script to do what you mention) you just
> > have to call it in the ALARMPROGRAM script when the event is the one
> > you're
> > looking for...
> >
> > Regards
> >
> > On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini <alexandre@briug.org>
> > wrote:
> >
> > > Hello.
> > > I think this might be a very useful RFE, in order to help us to identify
> > > abnormal memory session usage, in OLTP systems of high ammount of
> > > concurrent
> > > sessions (ad-hoc applications).
> > >
> > > If anyone like, please vote it...
> > >
> > https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&C
> > R_ID=62730
> > >
> > > Regards.
> > >
> > > Alexandre Marini
> > > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> > >
> > > IBM Information Management Informix Technical Professional
> > >
> > > IBM Certified Developer - Informix Genero
> > > BRIUG website administrator
> > > Informix independent consultant
> > >
> > >
> > >
> > >
> > **********************************************************
> > *********************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --
> > Fernando Nunes
> > Portugal
> >
> > http://informix-technology.blogspot.com
> > My email works... but I don't check it frequently...
> >
> > --001a113fd708c081b205092beeb0
> >
> >
> > **********************************************************
> > *********************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
You could run an onmode -I 22/28 but I don't think I would run that in
production :-) But again only helping when it is too late
Cheers
Paul
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Alexandre Marini
> Sent: Tuesday, December 02, 2014 9:27 AM
> To: ids@iiug.org
> Subject: RE: RFE request for session details during vir.... [34254]
>
> Yes, Paul, indeed. The issue is to catch things as soon as they happen.
> Any monitor tool (including an online.log parser), would not do this
trick.
>
> Let's see if Fernando or Jacques can find something that could help us on
> this....
> Thanks for the tips.
> Regards.
>
> Alexandre Marini
> IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
>
> IBM Information Management Informix Technical Professional
>
> IBM Certified Developer - Informix Genero
> BRIUG website administrator
> Informix independent consultant
>
> > To: ids@iiug.org
> > From: paul@oninit.com
> > Subject: RE: RFE request for session details during vir.... [34252]
> > Date: Tue, 2 Dec 2014 09:49:47 -0500
> >
> > We use Nagios to track when a number segment is added and spawn a
> script to
> > capture stuff. It's not ideal as Nagios runs every xx mins so it doesn't
> > capture the 'all hell breaking loose' memory requrements but ...
> >
> > Cheers
> > Paul
> >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > > Fernando Nunes
> > > Sent: Monday, December 01, 2014 12:40 PM
> > > To: ids@iiug.org
> > > Subject: Re: RFE request for session details during vir.... [34242]
> > >
> > > I'm not sure if I completely understand the request. But apparently
you
> > > want the SID of the session that caused the new memory segment to be
> > > added.
> > > But this does not necessarily means that that session is the one
> consuming
> > > more memory. Specially in an high activity system. Let's assume SID= y
is
> > > doing something nasty and it consumes a lot of memory. At time T0 it
> > > allocates a large chunk of memory for a sort or whatever. Between T0
> and
> > T1
> > > a lot of other sessions allocate small ammounts of blocks. At T1 a
> > > different session (SID=y) needs some memory that isn't available, and
> that
> > > triggers a new segment allocation. You'd get SID=y and not SID=x in
the
> > > messge.
> > >
> > > Beside that, systems can now allocate memory in pro-active mode
> (meaning
> > > no
> > > SID is associated with it).
> > >
> > > What I think you need is an expedite way of showing which sessions are
> > > consuming more memory at a specific time (onstat -u is limmited for
that,
> > > and I do agree some other option would be interesting). Once you have
a
> > > way
> > > to do that (and we can create a script to do what you mention) you
just
> > > have to call it in the ALARMPROGRAM script when the event is the one
> > > you're
> > > looking for...
> > >
> > > Regards
> > >
> > > On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini
> <alexandre@briug.org>
> > > wrote:
> > >
> > > > Hello.
> > > > I think this might be a very useful RFE, in order to help us to
identify
> > > > abnormal memory session usage, in OLTP systems of high ammount of
> > > > concurrent
> > > > sessions (ad-hoc applications).
> > > >
> > > > If anyone like, please vote it...
> > > >
> > >
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&C
> > > R_ID=62730
> > > >
> > > > Regards.
> > > >
> > > > Alexandre Marini
> > > > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> > > >
> > > > IBM Information Management Informix Technical Professional
> > > >
> > > > IBM Certified Developer - Informix Genero
> > > > BRIUG website administrator
> > > > Informix independent consultant
> > > >
> > > >
> > > >
> > > >
> > >
> **********************************************************
> > > *********************
> > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > >
> > > >
> > >
> > > --
> > > Fernando Nunes
> > > Portugal
> > >
> > > http://informix-technology.blogspot.com
> > > My email works... but I don't check it frequently...
> > >
> > > --001a113fd708c081b205092beeb0
> > >
> > >
> > >
> **********************************************************
> > > *********************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> **********************************************************
> *********************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
>
>
> **********************************************************
> *********************
> Forum Note: Use "Reply" to post a response in the discussion forum.
Yes, Paul, but even if it would, that would generate an AF file, together with
a shm dump, and I could not risk filling up any filesystem, since I don't know
how many times it would happen, it is a risk I don't want to deal with. We
would rather let shm dumps available only in case, for support critical issues.
But I appreciate your best intentions to help, anyway.
Thanks
Alexandre Marini
IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
IBM Information Management Informix Technical Professional
IBM Certified Developer - Informix Genero
BRIUG website administrator
Informix independent consultant
> To: ids@iiug.org
> From: paul@oninit.com
> Subject: RE: RFE request for session details during vir.... [34255]
> Date: Tue, 2 Dec 2014 10:32:35 -0500
>
> You could run an onmode -I 22/28 but I don't think I would run that in
> production :-) But again only helping when it is too late
>
> Cheers
> Paul
>
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Alexandre Marini
> > Sent: Tuesday, December 02, 2014 9:27 AM
> > To: ids@iiug.org
> > Subject: RE: RFE request for session details during vir.... [34254]
> >
> > Yes, Paul, indeed. The issue is to catch things as soon as they happen.
> > Any monitor tool (including an online.log parser), would not do this
> trick.
> >
> > Let's see if Fernando or Jacques can find something that could help us on
> > this....
> > Thanks for the tips.
> > Regards.
> >
> > Alexandre Marini
> > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> >
> > IBM Information Management Informix Technical Professional
> >
> > IBM Certified Developer - Informix Genero
> > BRIUG website administrator
> > Informix independent consultant
> >
> > > To: ids@iiug.org
> > > From: paul@oninit.com
> > > Subject: RE: RFE request for session details during vir.... [34252]
> > > Date: Tue, 2 Dec 2014 09:49:47 -0500
> > >
> > > We use Nagios to track when a number segment is added and spawn a
> > script to
> > > capture stuff. It's not ideal as Nagios runs every xx mins so it doesn't
> > > capture the 'all hell breaking loose' memory requrements but ...
> > >
> > > Cheers
> > > Paul
> > >
> > > > -----Original Message-----
> > > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > > > Fernando Nunes
> > > > Sent: Monday, December 01, 2014 12:40 PM
> > > > To: ids@iiug.org
> > > > Subject: Re: RFE request for session details during vir.... [34242]
> > > >
> > > > I'm not sure if I completely understand the request. But apparently
> you
> > > > want the SID of the session that caused the new memory segment to be
> > > > added.
> > > > But this does not necessarily means that that session is the one
> > consuming
> > > > more memory. Specially in an high activity system. Let's assume SID= y
> is
> > > > doing something nasty and it consumes a lot of memory. At time T0 it
> > > > allocates a large chunk of memory for a sort or whatever. Between T0
> > and
> > > T1
> > > > a lot of other sessions allocate small ammounts of blocks. At T1 a
> > > > different session (SID=y) needs some memory that isn't available, and
> > that
> > > > triggers a new segment allocation. You'd get SID=y and not SID=x in
> the
> > > > messge.
> > > >
> > > > Beside that, systems can now allocate memory in pro-active mode
> > (meaning
> > > > no
> > > > SID is associated with it).
> > > >
> > > > What I think you need is an expedite way of showing which sessions are
> > > > consuming more memory at a specific time (onstat -u is limmited for
> that,
> > > > and I do agree some other option would be interesting). Once you have
> a
> > > > way
> > > > to do that (and we can create a script to do what you mention) you
> just
> > > > have to call it in the ALARMPROGRAM script when the event is the one
> > > > you're
> > > > looking for...
> > > >
> > > > Regards
> > > >
> > > > On Mon, Dec 1, 2014 at 5:32 PM, Alexandre Marini
> > <alexandre@briug.org>
> > > > wrote:
> > > >
> > > > > Hello.
> > > > > I think this might be a very useful RFE, in order to help us to
> identify
> > > > > abnormal memory session usage, in OLTP systems of high ammount of
> > > > > concurrent
> > > > > sessions (ad-hoc applications).
> > > > >
> > > > > If anyone like, please vote it...
> > > > >
> > > >
> > https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&C
> > > > R_ID=62730
> > > > >
> > > > > Regards.
> > > > >
> > > > > Alexandre Marini
> > > > > IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10
> > > > >
> > > > > IBM Information Management Informix Technical Professional
> > > > >
> > > > > IBM Certified Developer - Informix Genero
> > > > > BRIUG website administrator
> > > > > Informix independent consultant
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > **********************************************************
> > > > *********************
> > > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > > >
> > > > >
> > > >
> > > > --
> > > > Fernando Nunes
> > > > Portugal
> > > >
> > > > http://informix-technology.blogspot.com
> > > > My email works... but I don't check it frequently...
> > > >
> > > > --001a113fd708c081b205092beeb0
> > > >
> > > >
> > > >
> > **********************************************************
> > > > *********************
> > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> > >
> > **********************************************************
> > *********************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> >
> >
> > **********************************************************
> > *********************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>