Re: IDS 11.10.xC2 on Solaris 10

On 14 Apr, 18:17, jpren...@yahoo.com wrote: > On Apr 8, 5:56 am, "Lello, Nick" <Nick.Le...@nielsen.com> wrote: > > > > > > > I'm looking for any ideas here as we seem to be getting the usual > > round-around from both Informix and Sun... > > > We have an multi-database installation of IDS 10.0.UC4 on Solaris 9 (Sun > > fire v480) which we are replacing with a reloaded engine IDS 11.10.FC2 > > on Solaris 10 (Sun fire v490). > > > The Solaris 10 + IDS 11 system runs really well (50%+ speed improvement) > > until after a couple of days we start seeing:- > > >    05:49:39  listener-thread: err = -25575: oserr = 12: errstr = : > > Network driver cannot allocate the call structure.  System error = 12. > > > The operating system has been configured in accordance with the Machine > > Notes for the IDS 11.10.FC2 distribution - curiously there is no mention > > of tuning the TCP stack through ndd. > > > Unfortunately the IBM (Informix) response has been a flat 'its an os > > error - speak to Sun' which is correct, but they wont help with any > > clues on what the call that is failing possibly is.... Sun are asking > > for source code and/or a truss of the failing process. > > > I have tried setting the following prior to IDS startup:- > > >         ndd -set /dev/tcp tcp_time_wait_interval 15000 > >         ndd -set /dev/tcp tcp_conn_req_max_q 4096 > >         ndd -set /dev/tcp tcp_conn_req_max_q0 16384 > >         ndd -set /dev/tcp tcp_max_buf 655350 > >         ndd -set /dev/tcp tcp_cwnd_max 655350 > > > Following my gut instinct for dealing with networking issues that > > *appear* to be with the queue depth > > > However, I'd love to hear from someone who has any solid ideas or > > experience with this version mix.... > > > Regards, > > Nick > > I'm posting this as general information for other people that might > show up here with the same problem.  I was working with the engineer > at IBM who was working on your PMR and we discovered that it looks > like the cause of your ENOMEM errors was the default address for > SHMBASE from the onconfig.std and even from the release notes for > 11.10.FCx appears to be far too close to the address that Solaris > wants to use for the starting heap address.  So the process does not > have much space for it's private heap before it runs into SHMBASE > which will then prohibit private heap growth.  The solution appears to > be to just use a larger address for SHMBASE to give more space between > the private memory heap and the IDS shared memory segments.   You can > use the pmap tool so show the addresses for where things are being > mapped out in your oninit proccesses address space, then find a good > empty spot to change your SHMBASE too and that should resolve the > issue. > > Example of the problem, pmap output for 11.10.FC1 > > 10754:  oninit > 0000000100000000      14320K r-x--  /spare1/product/1110FC1/bin/oninit > 0000000100EFA000       2480K rwx--  /spare1/product/1110FC1/bin/oninit > 0000000101166000       1000K rwx--    [ heap ] > 000000010A000000      16384K rwxs-    [ shmid=0x330 ] > 000000010B000000       8192K rwxs-    [ shmid=0x331 ] > 000000010B800000       9216K rwxs-    [ shmid=0x76 ] > > So from this output you can see the Solaris private heap starts at > 0x101166000 and SHMBASE from the onconfig file would appear to be set > to 0x10A000000, and those addresses are just far too close together to > allow sufficient private memory heap growth. > > Jacques- Hide quoted text - > > - Show quoted text - Planning to update the machine notes for this then?

> > > I'm posting this as general information for other people that might > > show up here with the same problem. I was working with the engineer > > at IBM who was working on your PMR and we discovered that it looks > > like the cause of your ENOMEM errors was the default address for > > SHMBASE from the onconfig.std and even from the release notes for > > 11.10.FCx appears to be far too close to the address that Solaris > > wants to use for the starting heap address. So the process does not > > have much space for it's private heap before it runs into SHMBASE > > which will then prohibit private heap growth. The solution appears to > > be to just use a larger address for SHMBASE to give more space between > > the private memory heap and the IDS shared memory segments. You can > > use the pmap tool so show the addresses for where things are being > > mapped out in your oninit proccesses address space, then find a good > > empty spot to change your SHMBASE too and that should resolve the > > issue. > > > Example of the problem, pmap output for 11.10.FC1 > > > 10754: oninit > > 0000000100000000 14320K r-x-- /spare1/product/1110FC1/bin/oninit > > 0000000100EFA000 2480K rwx-- /spare1/product/1110FC1/bin/oninit > > 0000000101166000 1000K rwx-- [ heap ] > > 000000010A000000 16384K rwxs- [ shmid=0x330 ] > > 000000010B000000 8192K rwxs- [ shmid=0x331 ] > > 000000010B800000 9216K rwxs- [ shmid=0x76 ] > > > So from this output you can see the Solaris private heap starts at > > 0x101166000 and SHMBASE from the onconfig file would appear to be set > > to 0x10A000000, and those addresses are just far too close together to > > allow sufficient private memory heap growth. > > > Jacques- Hide quoted text - > > > - Show quoted text - > > Planning to update the machine notes for this then? I spoke to the engineer and a defect is going to be entered, at this point I'm not sure if it will just be a modification to machine notes, release notes, or a change to the SHMBASE in the onconfig.std itself. But something will get changed/added for this. Jacques.