shared memory parameters

Having trouble with share memory parameters. I am trying to locate each piece of the memory size number reported by "onstat -". So far I have been able to correlate changes in onconfig with changes in that onstat number. However, I haven't been able to get it all and can't seem to find out who knows this. When oninit -v starts up the engine, I see the resident memory pool number reported there but cannot find the details in that number. It's killing me. You might ask why I'm doing this. Well, we had an assertion failure that we can't account for and when we killed all memory segments (with IBM's help) and rebooted the RHEL 4 AS box, IDS 10.00 FC4 could not attach to the SHMVIRTSIZE memory cited in the onconfig file. IBM suggested we take that 20gb figure and reduce it. We did and IDS attached and we went with it. We still don't know why we can't start the engine with the same 20gb SHMVIRTSIZE we have had for years. One thing leads to another. We swopped identically memory from our test box to see if we could isolate the problem. No change was noted. Now I'm trying to get very specific about the shared memory parameters on our test box so that I can define and hopefully understand what is going on with our production box. Of course both boxes are the same except for memory (prod has more). In fact, test has 24gb of ram with 6gb being used for raid5. The prod box has 32gb of ram with 8gb being used for raid5. Strangely, I can push SHMVIRTSIZE to 21gb on test but can only push prod to about 18.5gb. So now I'm in the middle of it. Seems to me something is going on with hardware or the OS but what? Why does IDS initialize with more virtual shared memory than there is memory on the box? Why can't the prod instance initialize using the same onconfig paramaters that it has for years? On the other hand, here's an easy question: Where can I find the size of the resident pool, other than in the output from oninit -v ? Thanks to all!

You wrote--------------------------------------------------- Having trouble with share memory parameters. I am trying to locate each piece of the memory size number reported by "onstat -". So far I have been able to correlate changes in onconfig with changes in that onstat number. However, I haven't been able to get it all and can't seem to find out who knows this. When oninit -v starts up the engine, I see the resident memory pool number reported there but cannot find the details in that number. It's killing me. You might ask why I'm doing this. Well, we had an assertion failure that we can't account for and when we killed all memory segments (with IBM's help) and rebooted the RHEL 4 AS box, IDS 10.00 FC4 could not attach to the SHMVIRTSIZE memory cited in the onconfig file. IBM suggested we take that 20gb figure and reduce it. We did and IDS attached and we went with it. We still don't know why we can't start the engine with the same 20gb SHMVIRTSIZE we have had for years. One thing leads to another. We swopped identically memory from our test box to see if we could isolate the problem. No change was noted. Now I'm trying to get very specific about the shared memory parameters on our test box so that I can define and hopefully understand what is going on with our production box. Of course both boxes are the same except for memory (prod has more). In fact, test has 24gb of ram with 6gb being used for raid5. The prod box has 32gb of ram with 8gb being used for raid5. Strangely, I can push SHMVIRTSIZE to 21gb on test but can only push prod to about 18.5gb. So now I'm in the middle of it. Seems to me something is going on with hardware or the OS but what? Why does IDS initialize with more virtual shared memory than there is memory on the box? Why can't the prod instance initialize using the same onconfig paramaters that it has for years? On the other hand, here's an easy question: Where can I find the size of the resident pool, other than in the output from oninit -v ? Thanks to all! -------------------------------------------------------------------------------- Response You can see the size of the resident segment via onstat -g seg. I think there is some formula you can use to calculate the size of the resident pool (possibly in the admin guide) and it depends on a lot of different parameters (probably the largest being the BUFFERPOOL definition then probably LOCKS). IDS can initialize with more shared memory then real memory on the box if you have a big enough swap space. The amount of shared memory you can create and use on a machine is more dependent on OS kernel parameters then physical memory (provided you have enough swap space defined). Do you know if there was any kernel parameter modifications on the prod server? Or any swap changes? Can you post the exact error you get when you try to bring the server online (from either the MSGPATH file or terminal. The exact error you were getting would probably give some clue as to the limiting resource. Sometimes it's not a resource limit, but a process address space issue in the sense that a shared memory segment will colide with something else in the address space (like a shared library). You might take a look at pmap output and see if any shared memory segments are getting near anything else in the address space (as the engine generally requires that our shared memory be contiguous). That can be worked around with SHMBASE or I believe commands to modify the shared library to tell it where in the address space to load. Jacques Renaut IBM Informix Advanced Support APD Team

http://linux.about.com/library/cmd/blcmdl8_ipcs.htm will give you more information on the shared memory running. When an instance dies you may have to run http://linux.about.com/library/cmd/blcmdl8_ipcrm.htm to remove the segments that may be hanging out there preventing you from restarting. Lennie On Tue, Feb 9, 2010 at 2:54 PM, DOUGLAS MERRILL <dmerrill@lakecountyil.gov>wrote: > Having trouble with share memory parameters. > I am trying to locate each piece of the memory size number reported by > "onstat > -". So far I have been able to correlate changes in onconfig with changes > in > that onstat number. However, I haven't been able to get it all and can't > seem > to find out who knows this. > > When oninit -v starts up the engine, I see the resident memory pool number > reported there but cannot find the details in that number. It's killing me. > > You might ask why I'm doing this. Well, we had an assertion failure that we > can't account for and when we killed all memory segments (with IBM's help) > and > rebooted the RHEL 4 AS box, IDS 10.00 FC4 could not attach to the > SHMVIRTSIZE> memory cited in the onconfig file. IBM suggested we take that 20gb figure > and > reduce it. We did and IDS attached and we went with it. We still don't know > why we can't start the engine with the same 20gb SHMVIRTSIZE we have had > for > years. > > One thing leads to another. We swopped identically memory from our test box > to > see if we could isolate the problem. No change was noted. Now I'm trying to > get very specific about the shared memory parameters on our test box so > that I > can define and hopefully understand what is going on with our production > box. > > Of course both boxes are the same except for memory (prod has more). In > fact, > test has 24gb of ram with 6gb being used for raid5. The prod box has 32gb > of > ram with 8gb being used for raid5. Strangely, I can push SHMVIRTSIZE to > 21gb > on test but can only push prod to about 18.5gb. So now I'm in the middle of > it. Seems to me something is going on with hardware or the OS but what? Why > does IDS initialize with more virtual shared memory than there is memory on > the box? Why can't the prod instance initialize using the same onconfig > paramaters that it has for years? > > On the other hand, here's an easy question: Where can I find the size of > the > resident pool, other than in the output from oninit -v ? > > Thanks to all! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --0015175884ca6339a4047f32b035

Hi, maybe your OS kernel settings have changed or got resetted by the reboot (most interesting ones: shmall, shmsize). Check the values with ipcs -l (shared memory limits) or sysctl -a | grep shm For more explanations you can have a look at http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2. udb.uprun.doc/doc/t0008238.htm Best Regards Andreas > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 84923 Fax: Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > DOUGLAS MERRILL > Gesendet: Dienstag, 9. Februar 2010 21:54 > An: ids@iiug.org > Betreff: shared memory parameters [18966] > > Having trouble with share memory parameters. > I am trying to locate each piece of the memory size number reported by > "onstat > -". So far I have been able to correlate changes in onconfig with changes > in > that onstat number. However, I haven't been able to get it all and can't > seem > to find out who knows this. > > When oninit -v starts up the engine, I see the resident memory pool number > reported there but cannot find the details in that number. It's killing > me. > > You might ask why I'm doing this. Well, we had an assertion failure that > we > can't account for and when we killed all memory segments (with IBM's help) > and > rebooted the RHEL 4 AS box, IDS 10.00 FC4 could not attach to the > SHMVIRTSIZE> memory cited in the onconfig file. IBM suggested we take that 20gb figure > and > reduce it. We did and IDS attached and we went with it. We still don't > know > why we can't start the engine with the same 20gb SHMVIRTSIZE we have had > for > years. > > One thing leads to another. We swopped identically memory from our test > box to > see if we could isolate the problem. No change was noted. Now I'm trying > to > get very specific about the shared memory parameters on our test box so > that I > can define and hopefully understand what is going on with our production > box. > > Of course both boxes are the same except for memory (prod has more). In > fact, > test has 24gb of ram with 6gb being used for raid5. The prod box has 32gb > of > ram with 8gb being used for raid5. Strangely, I can push SHMVIRTSIZE to > 21gb > on test but can only push prod to about 18.5gb. So now I'm in the middle > of > it. Seems to me something is going on with hardware or the OS but what? > Why > does IDS initialize with more virtual shared memory than there is memory > on > the box? Why can't the prod instance initialize using the same onconfig > paramaters that it has for years? > > On the other hand, here's an easy question: Where can I find the size of > the > resident pool, other than in the output from oninit -v ? > > Thanks to all! > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum.

If you are running version 11 you can use onstat -g osi (for operating system information) toget many of the interesting kernel and system information settings. This command works when the database is online or offline (like onstat -m). John F. Miller III STSM, Support Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 02/10/2010 12:34:43 AM: > Hi, > > maybe your OS kernel settings have changed or got resetted by the > reboot (most > interesting ones: shmall, shmsize). Check the values with > ipcs -l (shared memory limits) or sysctl -a | grep shm > > For more explanations you can have a look at > > http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=3D= / > com.ibm.db2.udb.uprun.doc/doc/t0008238.htm > > Best Regards > Andreas > > > > ------------------------------------------- > SPAR =D6sterreichische Warenhandels-AG > Hauptzentrale > A - 5015 Salzburg, Europastrasse 3 > FN 34170 a > > Tel: +43 662 4470 84923 > Fax: > Mobile: +43 664 6259575 > E-Mail: Andreas.KUTSCHE@spar.at > Internet: http://www.spar.at > > Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich > gesch=FCtzte Informationen, insbesondere Betriebs- oder Gesch=E4ftsgeheimnisse, > enthalten, zu deren Geheimhaltung der Empf=E4nger verpflichtet ist. D= ie > Informationen in dieser E-Mail sind ausschlie=DFlich f=FCr den Adress= aten > bestimmt. Sollten Sie die E-Mail irrt=FCmlich erhalten haben so ersuc= hen wir > Sie, die Nachricht von Ihrem System zu l=F6schen und sich mit uns in Verbindung > zu setzen. > =DCber das Internet versandte E-Mails k=F6nnen leicht manipuliert ode= r unter > fremdem Namen erstellt werden. Daher schlie=DFen wir die rechtliche > Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus= . Der > Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftl= ich > best=E4tigt und gezeichnet wird. > Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch dieZusendung > von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht f=FC= r evtl. > hieraus entstehende Sch=E4den. > Wir danken f=FCr Ihr Verst=E4ndnis. > > Important notice: The contents of this e-mail may contain confidentia= l and > legally protected information that is in particular related to > operational and > trade secrets, which the recipient is obliged to treat as confidentia= l. The > information in this e-mail is made available exclusively for use by t= he > addressee. In the event that the e-mail may have been sent to you inerror, we > would ask you to kindly delete this communication from your system an= d to > contact us. > E-mails sent via the Internet can be easily manipulated or sent out u= nder > someone else's name. We therefore do not accept legal liability for t= he > information contained in this communication. The contents of the e-ma= il are > only legally binding if they have been confirmed and signed by us inwriting. > If, in spite of our using Antivirus protection software, a virus may = have > penetrated your system through the sending of this e-mail, we do not accept > liability for any damage that may possibly arise as a result of this.= > We trust that you appreciate our position. > > ------------------------------------------- > -----Urspr=FCngliche Nachricht----- > > > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag = von > > DOUGLAS MERRILL > > Gesendet: Dienstag, 9. Februar 2010 21:54 > > An: ids@iiug.org > > Betreff: shared memory parameters [18966] > > > > Having trouble with share memory parameters. > > I am trying to locate each piece of the memory size number reported= by > > "onstat > > -". So far I have been able to correlate changes in onconfig with changes > > in > > that onstat number. However, I haven't been able to get it all and can't > > seem > > to find out who knows this. > > > > When oninit -v starts up the engine, I see the resident memory pool= number > > reported there but cannot find the details in that number. It's kil= ling > > me. > > > > You might ask why I'm doing this. Well, we had an assertion failure= that > > we > > can't account for and when we killed all memory segments (with IBM'= s help) > > and > > rebooted the RHEL 4 AS box, IDS 10.00 FC4 could not attach to the > > SHMVIRTSIZE> > memory cited in the onconfig file. IBM suggested we take that 20gb figure > > and > > reduce it. We did and IDS attached and we went with it. We still do= n't > > know > > why we can't start the engine with the same 20gb SHMVIRTSIZE we hav= e had > > for > > years. > > > > One thing leads to another. We swopped identically memory from our = test > > box to > > see if we could isolate the problem. No change was noted. Now I'm trying > > to > > get very specific about the shared memory parameters on our test bo= x so > > that I > > can define and hopefully understand what is going on with our production > > box. > > > > Of course both boxes are the same except for memory (prod has more)= . In > > fact, > > test has 24gb of ram with 6gb being used for raid5. The prod box ha= s 32gb > > of > > ram with 8gb being used for raid5. Strangely, I can push SHMVIRTSIZ= E to > > 21gb > > on test but can only push prod to about 18.5gb. So now I'm in the middle > > of > > it. Seems to me something is going on with hardware or the OS but w= hat? > > Why > > does IDS initialize with more virtual shared memory than there is memory > > on > > the box? Why can't the prod instance initialize using the same onco= nfig > > paramaters that it has for years? > > > > On the other hand, here's an easy question: Where can I find the si= ze of > > the > > resident pool, other than in the output from oninit -v ? > > > > Thanks to all! > > > > > > ***********************************************************************= *** > > ***** > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > ***********************************************************************= ******** > Forum Note: Use "Reply" to post a response in the discussion forum.= >=

This article refers to DB2, but I'm guessing the same values apply to IDS? Jonathon Wyza Programmer/Analyst Administrative Computing Bethel College (574)-257-3381 AIM: Iamwyza jonathon.wyza@bethelcollege.edu ========================== SLES 10 SP2 & IDS 10.0 HC9 " I would love to change the world, but they won't give me the source code." -- Unknown -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Andreas.KUTSCHE@spar.at Sent: Wednesday, February 10, 2010 3:35 AM To: ids@iiug.org Subject: AW: shared memory parameters [18973] Hi, maybe your OS kernel settings have changed or got resetted by the reboot (most interesting ones: shmall, shmsize). Check the values with ipcs -l (shared memory limits) or sysctl -a | grep shm For more explanations you can have a look at http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2. udb.uprun.doc/doc/t0008238.htm Best Regards Andreas > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 84923 Fax: Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > DOUGLAS MERRILL > Gesendet: Dienstag, 9. Februar 2010 21:54 > An: ids@iiug.org > Betreff: shared memory parameters [18966] > > Having trouble with share memory parameters. > I am trying to locate each piece of the memory size number reported by > "onstat > -". So far I have been able to correlate changes in onconfig with changes > in > that onstat number. However, I haven't been able to get it all and can't > seem > to find out who knows this. > > When oninit -v starts up the engine, I see the resident memory pool number > reported there but cannot find the details in that number. It's killing > me. > > You might ask why I'm doing this. Well, we had an assertion failure that > we > can't account for and when we killed all memory segments (with IBM's help) > and > rebooted the RHEL 4 AS box, IDS 10.00 FC4 could not attach to the > SHMVIRTSIZE> memory cited in the onconfig file. IBM suggested we take that 20gb figure > and > reduce it. We did and IDS attached and we went with it. We still don't > know > why we can't start the engine with the same 20gb SHMVIRTSIZE we have had > for > years. > > One thing leads to another. We swopped identically memory from our test > box to > see if we could isolate the problem. No change was noted. Now I'm trying > to > get very specific about the shared memory parameters on our test box so > that I > can define and hopefully understand what is going on with our production > box. > > Of course both boxes are the same except for memory (prod has more). In > fact, > test has 24gb of ram with 6gb being used for raid5. The prod box has 32gb > of > ram with 8gb being used for raid5. Strangely, I can push SHMVIRTSIZE to > 21gb > on test but can only push prod to about 18.5gb. So now I'm in the middle > of > it. Seems to me something is going on with hardware or the OS but what? > Why > does IDS initialize with more virtual shared memory than there is memory > on > the box? Why can't the prod instance initialize using the same onconfig > paramaters that it has for years? > > On the other hand, here's an easy question: Where can I find the size of > the > resident pool, other than in the output from oninit -v ? > > Thanks to all! > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.