From: Andrews, Paul (Paul.Andrews@staples.com)
Date: Thu May 01 2003 - 13:34:47 EDT
Thanks to all Replies which were basically all telling me ya have to make
sure all processes are in the same memory window. Once we did that, progress
is up and running.!
Also Lots of Thanks To Bill Hassell who took the time to Teach Me...! I've
included some of Bills responses from me pestering him on how to tell what
space is left for 32Bit Apps. Bill as usual provides lots of Good Tips !!
Thanks too all who responded. Now to Tackle Oracle !
Paul
=======================
i,
> Has anyone tried to run the progress database in a hpux 11.00
> memory window.
> Able to get all progress processes to run in memory window except client
> access from desktop fails to connect. . Apparently clients talk to a
> progress broker.
Memory windows require that *every* process that must share memory be
started
in the same memory window. This means that the clients must connect to a
process that was started in the correct memory window. If the broker is
simply listed in inetd.conf, it will be started in window #0, the default
memory window and cannot see any of the Progress components that were
started
in some other window. You'll need to schedule all Progress components
such that
they all start with the memory window selector. This will require
understanding
all of the possibile components and getting them all to startup in a
specific
window. Daemons will be particularly tricky.
--
Best regards,
Bill Hassell
----------------------------------------------------
Bill Im having real trouble understanding how much 32Bit Global
> Space I even
> have left on a system without memory windows...Hp logged on and
> ran shminfo
> -F and showed me the largest Global 32-bit shared Quadrant 4 had
> like 160 K
> . But what about the 32 Bit Private can I count that..??? Some of my
> processes are in there..??
>
> can you help me understand.....Every time i call HP im more confused..
The 32bit shared memory space starts at 950 megs for standard executables,
then jumps to about 1750 megs for SHARE_MAGIC executables (see chatr man
page) and with additional compile-time options, I believe you can access
almost 3Gb for shared memory.
Now the above *only* applies to the program (and all other programs that
will share the same area). Whether there is enough space left in the
32bit window depends on what is already occupying space in the default
area (memory window zero). Without using memory windows, your processes
must contend with shared libraries, memory mapped files and other shared
memory segments already allocated. Yes, this area can become fragmented
such that the largest contiguous space is only a few dozen megs.
Enter memory windows: by starting a process using the memory windows
command, the process is given a new, completely empty window up to 1750
megs (possibly up to the 3Gb limit with compiler options). This process
is completely isolated as far as shared memory. *EVERY* process that needs
to 'see' this shared memory area must be started with the memory windows
command so that it will not become attached to mem-window zero. Thus, you
need to understand how the PC client connects to the Progress server code.
As I mentioned, if Progress uses a daemon, that daemon must be started
inside the Progress memory window, otherwise it will never see the shared
memory segment(s) used by the database server.
So your problem is to inventory every process Progress might run that will
access the shared area. All of those processes must have a startup method
(perhaps a shell wrapper) that ensures it will start in the correct
window.
All of this is a big kludge to allow 32bit programs to access large
memory.
If I were you, I would complain bitterly to the Progress support people if
there is no 64bit version available. HP-UX has been 64bit capable since
1997
(which is ancient history for computers) and with 64bit executables,
Progress
will have *NO* limitations on shared or local memory (well, terabytes of
RAM).
Oracle solved this with 8i and 9i although a lot of DBAs are reluctant to
use
the 64bit versions, mostly out of inexperience. And of course, all
plugins
nad other middleware will need to understand 64bit values where necessary
in
shared memory areas.
As far as HP support goes, there are some excellent resources inside HP
called
WTEC who can provide the technical expertise to help with memory windows.
A WTEC
engineer wrote the shminfo utility.
----------------------------------------------------------------------------
---
--> Thanks Bill I Think Im getting it...Im just trying to see whats
> left now on
> my systems for 32Bit shared. And your saying I look at memory window 0 to
> see this...
Remember that memory window 0 is for all processes that are not started
in a different memory window. shminfo will show you all the 'holes' and
also the largest single segment that can be requested. If this number is
quite low (say, 100 megs or less) then memwin zero is badly fragmented.
For instance, running fbackup and then killing it using kill -9 (a very
bad option) will leave a large shared memory segment allocated forever
to a non-existant process. ipcs -bmop will show unattached segments and
ipcrm can remove these, but be careful that the segment is truly not
being used.
And tell every sysadmin NEVER to use kill -9 until all other kill signals
have been tried. Fragmented shared memory is a very common result.
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:29 EDT