Veritas-bu

[Veritas-bu] Restoring a 1TB filesystem with 7million

2006-10-03 13:52:59
Subject: [Veritas-bu] Restoring a 1TB filesystem with 7million
From: bob944 at attglobal.net (bob944)
Date: Tue, 3 Oct 2006 13:52:59 -0400
Jeff Lightner [mailto:jlightner at water.com] wrote

> Uh - the limitation isn't HP-UX but the amount of memory 32
> bits allow for.  You see similar limitations in Linux for 32
> bit.  There are schemes (hugemem etc...) for getting around
> this in Linux just as there is shared memory and memory window
> magic for getting around it in HP-UX.

Actually, Jeff, the limitation _is_ HP-UX.

I've been calculating 2^32 - 1 for a long time :-) ; we're not talking
about a 4GB limit.  As I said, the limitation is HP's quadrant system
imposed on 32-bit apps which divides the 4GB address space into
dedicated-use 1GB quads for text, data, shlib and shmem.  Mr Caparroso's
problem was bprd running out of memory in a quadrant; status 89s are the
same thing:  only the third and fourth 1GB quads can be used for shared
objects--less 0.25GB reserved for system I/O--which gives you 1.75GB for
buffers and a status 89 when you exceed that.  32-bit Oracle and DB2
have the same problem on HP-UX:  1.5-1.7GB max SGA for Oracle and
0.7-1GB max database shared memory for DB2.  

When I had HP systems, it didn't bother me one bit that HP-UX works this
way.  (Hey, it's a design choice HP made long ago which might have some
advantages; these are the disadvantages that other Unices don't have.)
We discuss it here because there are demonstrably HP-UX NetBackup users
on this list who don't have your expertise in that OS--I certainly
don't--and need to know what to look out for and how to fix it, like
with Caparosso's follow-up.

For any 32-bit app on HP-UX, HP's 1.75GB limit for all 32-bit apps on a
system and the patch/chattr/MAGIC_flags/recompilation workarounds are
explained in their white paper:

  http://devresource.hp.com/drc/STK/docs/archive/memwindow.pdf

For NetBackup users with PA-RISC, unless/until Veritas provides a 64-bit
PA-RISC port, it's do-it-yourself or avoid the extreme situations where
1GB segments might be a problem.  For status 89s, either set up shared
memory correctly or use common sense and tuning for buffers.

> [...]
> 
> -----Original Message-----
> From: bob944 [mailto:bob944 at attglobal.net] 
> Sent: Tuesday, October 03, 2006 12:21 AM
> To: veritas-bu at mailman.eng.auburn.edu; Jeff Lightner
> Subject: RE: [Veritas-bu] Restoring a 1TB filesystem with 7million
> 
> > My bad.  If I'd been paying attention I might have mentioned chatr.
> > 
> > FYI:  Its not necessary on 64 bit HP-UX.  What class of 
> server are you
> > running the 32 bit on?  Most servers since the HP 9000 K400 
> > have PA-RISC
> > 2.x processors.  PA-RISC 2.x are all capable of running the 64 bit
> > version of 11.11.
> 
> I believe the original poster _is_ running 64-bit HP-UX--it's 
> the 32-bit
> NetBackup that is the problem.
> 
> Actually, the problem really is HP's whacked memory scheme for 32-bit
> apps running on 64-bit HP-UX.  There's an old HP white paper available
> that describes the 1.75GB memory limit that 64-bit HP-UX 
> imposes on any
> 32-bit app, how to use chattr (or recompile with magic flags) to raise
> the limit to 2.75GB, or how to build the app to be able to 
> use 3.75 (as
> I remember) gig.  The usual symptom is running out of shared memory by
> using huge buffer settings and getting status 89.  As far as 
> I know, no
> other Unix variant imposes this sort of 1.75GB straightjacket.
> 
> The only 64-bit HP-UX NetBackup version Veritas offers is 6.x for
> Itanium.  No 64-bit 5.x and no 64-bit PA-RISC.



<Prev in Thread] Current Thread [Next in Thread>