Re: help with hp loader errors

Hi, the implementation of the memory map information is platform dependent. As I do not know, which platform you are on (at least I didn't see it), I wrote that part basically as an example for Linux. On a different platform you may have to use a system utility to view the info. Or maybe the file itself is a utility that you can simply execute and it produces the info as output ... Of course the file (and thus the info) usually is only available as long as the corresponding process lives. Once the process does not exist anymore, the info is gone. I forgot to add that for clarity. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Andreas Kerstan Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 informix-list-bounces@iiug.org wrote on 12.04.2007 12:50:41: > Thanks for the explanation Martin. It does make sense. > I looked into the /procs directory, and didn't see any memory > map file that I am able to read. ( non-ascii stuff ). > > So I will just have to try and find a value to use for either > IFX_XFER_SHMBASE or PLOAD_SHMBASE. > > ok. > > > ======================== > -<<Floyd Wellershaus>>- > Database Administrator > Unix Administrator > > > email: fwellers@yahoo.com > > Home: 703-430-0805 > > Cell: 703-477-6045 > ======================== > > http://www.one.org/ > > ----- Original Message ---- > From: Martin Fuerderer <MARTINFU@de.ibm.com> > To: Floyd Wellershaus <fwellers@yahoo.com> > Cc: informix-list@iiug.org; informix-list-bounces@iiug.org > Sent: Thursday, April 12, 2007 5:30:47 AM > Subject: Re: help with hp loader errors > Hi, > > when a process attaches to shared memory (SHM), then the SHM > segment gets mapped into the processes memory space at some > address. Our processes (oninit, onpload, etc.) usually want to have > SHM segments mapped to their memory space so that several SHM > segments form a contiguous area in the processes memory space. > > If some memory area in a processes memory space is already in > use by some other memory object (other SHM segment, shared > libraries, memory heap, memory stack, ...), then the mapping to > the desired address fails, i.e. the system call to do the attach and > mapping fails. This is what happens when a message is given like > "... could not attach ... shared memory segment ...". > > onpload processes (created by HPL) are a bit complicated, > because they not only attach to SHM from the server, but they > also have their own SHM segments. Apart from that they may use > some extra memory in the heap and stack memory structures, > especially when run with some (externally implemented) conversion > routines. > > By default onpload will try to map the servers SHM segments to > the servers SHMBASE address (as defined in the onconfig file). > Also, by default the onpload will want to map its own SHM segments > to some other address (that I don't know now - it is platform > dependent anyway). > > If there is a problem like you see, then you can try to use the > IFX_XFER_SHMBASE environment variable for onpload to > define a different address where onpload will want to map the > servers SHM segments (instead of using the onconfig's SHMBASE). > > Also, PLOAD_SHMBASE can be used to define a different address > for onpload where to map its own SHM segments. I think this was > added in some newer version (9.4 or 10.0?: I'm not sure) and I think > it also is an environment variable. > > Using these parameters you can avoid that the mapping of SHM > segments into onploads memory space clashes with other > SHM segments or other memory objects already there. It can be > a bit tricky and may require some attempts to figure out useful > values. I guess from your info that you are on a 64-bit platform, > so memory space of processes should be big enough to find > some unused area. :) > > You can try to figure out the memory space layout of a running > process. On Linux this is in a pseudo file (for each process) > named /proc/<pid>/maps (where <pid> is the process ID. User > root can look into this file and thus see the memory layout to > figure out where used and unused areas exist in the memory > space of this process. > > I do not recommend changing the SHMBASE onconfig file > parameter. This is used by the server (for mapping the servers > own SHM segments into its own memory space). As long as the > server (i.e. the oninit processes) runs fine with a particular > setting of this parameter (and usually this is the value from > the onconfig.std file), I would not change this. (Only when > the server runs into trouble is the time to start fiddling > around with this parameter.) > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management > > IBM Deutschland GmbH > Chairman of the Supervisory Board: Hans Ulrich Märki > Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian > Diedrich, Christoph Grandpierre, Matthias Hartmann, Andreas Kerstan > Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, > HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 > > informix-list-bounces@iiug.org wrote on 11.04.2007 15:12:12: > > > Hi, > > I've been testing out doing loads and unloads with the hp loader and > named pipes. > > We have 6 cpus, so I orginally named 6 pipes and ran it that way. > > The unload works great, the load however gave me load of the following > error: > > > > Client could not attach server shared memory segment, use > IFX_XFER_SHMBASE. > > > > So I figured I'd try it with a less demanding job and only set up 3 > pipes for the load and unload jobs. > > Again, the unload ran fine, but the load now continuously spews the > following: > > > > 09:03:58 Dynamically allocated new virtual shared memory segment (size > 4096KB) > > 09:03:58 Contiguous shared memory segment allocation failed at> 0x700000040000000. > > Allocation successful at 0x700000610000000. > > Check SHMBASE is consistent with the value in > $INFORMIXDIR/etc/onconfig.std. > > If you are using the correct SHMBASE value in your ONCONFIG file, then > > consider this message informational only. > > > > Is this a bug, or is my SHMBASE somehow configured wrong or what ? > > > > Thank you, > > floyd > > > > ======================== > > -<<Floyd Wellershaus>>- > > Database Administrator > > Unix Administrator > > > > email: fwellers@yahoo.com > > Home: 703-430-0805 > > Cell: 703-477-6045 > > ======================== > > http://www.one.org/_______________________________________________ > > Informix-list mailing list > > Informix-list@iiug.org > > http://www.iiug