Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> (Fwd) Re: TECH: 11i architecture (Forms consuming lot of memo

(Fwd) Re: TECH: 11i architecture (Forms consuming lot of memo

From: Eric D. Pierce <PierceED_at_csus.edu>
Date: Fri, 29 Sep 2000 13:13:16 -0700
Message-Id: <10634.118265@fatcity.com>


(note: see below for info on the Oracle U.K. Dev Team Product Manager who is going to OOW)

Carl put it very well, I'd just add that there is the perennial problem here of working out how much memory an application is using. You can't believe what PS or NT Task manager are telling you. They represent the total size of memory used by a process but this includes shared stuff as well. So even if 5 processes are sharing 1 megs worth of FMX taking the memory figures provided by these utilities would leave you to believe that 5 megs was allocated whereas the true situation is that there are 5 pointers to the *same* 1 meg.

Finally I'm at Openworld next week so any "What do you think Duncan?" notes will be missed because I'll be off the list for a week. Save 'em up, or catch me there....

Regards
Duncan Mills
Enterprise Internet Tools - Product Management ----- Original Message -----
To: "Multiple recipients of list ODTUG-DEV2K-L" <ODTUG-DEV2K-L_at_fatcity.com> Sent: Friday, September 29, 2000 8:10 PM

[Date sent:Fri, 29 Sep 2000 11:10:46 -0800 To:Multiple recipients of list ODTUG-DEV2K-L <ODTUG-DEV2K-L_at_fatcity.com> Send reply to:ODTUG-DEV2K-L_at_fatcity.com
From:"Zetie, Carl" <CZetie_at_gigaweb.com>
Subject:RE: TECH: 11i architecture (Forms consuming lot of memory) ]

>
> I'm sure Duncan knows, but I don't know how much he is allowed to say as an
> Oracle employee or how much I should say as an ex-Oracle employee who saw
> this evolution from the inside :->
>
> But I will say that the explanation offered is not correct. Yes, Forms
> runtime was originally conceived as a single-user engine. But multi-user
> support was not "bolted on" nor does it in any way resemble "faking out" the
> OS into running, effectively, multiple independent single users each in
> their own virtual OS as described in the proffered analogy.
>
> A great deal of development effort went into creating a forms server that
> would be as efficient as possible running both multiple instances of a
> single module and multiple users running different modules, while at the
> same time preserving compatibility with existing (often extremely baroque!)
> Forms behavior.
>
> The forms server does have shared code (DLLs on NT, shared libraries on
> Unix). The forms server does have shared memory - to the extent possible
> while giving each user/session an independent state. Sharing the .exe itself
> is a function of the OS, the most that Forms can do to help is to break as
> much code as possible out into well-organized libraries, and that is
> something that has been happening step by step since Dev2k 1.3.2 (to my
> knowledge). Depending on the OS the user may appear to have a unique virtual
> memory allocation even for their code pages, but physically it is the same
> memory.
>
> > Wouldn't it be nice if Oracle's Forms architecture could
> > reuse form descriptions after loading them to memory just once?
>
> Uh... it does.
>
> The biggest challenge in running multiple forms used to be (probably still
> is) that to the operating system, the FMX files look like data, not
> executable, so it will allocate a unique and private memory allocation for
> the memory image of the FMX to each Forms session that opens it. Forms
> can't rely on any of the standard OS features that normally share code
> segments to share the FMX. However, some OSes do provide the ability to
> share read-only data pages ("fork on change" I think is the technical
> term)...
>
> The "state" of a form is actually very large and very complex when you think
> about it: it includes the definition, size, state, position, data contents,
> etc. of every object in the form. Nearly all of that information is nearly
> always the same for every user (how many items actually change size/position
> at runtime?) but potentially almost any of it could change - which is why it
> is all in a data segment: in-memory FMX is actually a complex mixture of
> static and dynamic data. So starting a couple of releases back, the dev team
> restructured the FMX file so that everything static was clustered together
> in one part of the FMX, and everything dynamic - essentially anything you
> could change with a set_XXX_property() built-in or anything a user action
> could change - was also clustered together. Each user of the form is now
> sharing the same memory image until something they do causes their version
> of the image - say, the enabled/disabled state of an item or the position of
> a window - to change, at which point a unique copy of that page only is
> created, representing the state for that user. It's a very clever solution
> to a problem that is a great deal more complicated than "2-3Mb ... just to
> preserve stack and state data".
>
> If you want to criticize Forms on scalability, you can legitimately point to
> the fact that it doesn't use threads, but runs each user session in a
> separate process. That is expensive in process slots (a finite resource in
> most OSes, although rarely the limiting factor) and more importantly in
> process context switches. That can hurt throughput and response time on a
> heavily loaded machine. However, making code that was not designed to be
> thread-safe threaded is very hard, so I don't know if the dev team will ever
> attempt it?
>
>
> Incidentally, memory costs about $1/MB these days. $15/enterprise
> application user doesn't seem like a lot in the grand scheme of things...
>
>
> > -----Original Message-----
> > From: Hathi,Manish [mailto:mhathi_at_mwd.dst.ca.us]
> > Sent: Friday, September 29, 2000 9:42 AM
> > To: Multiple recipients of list ODTUG-DEV2K-L
> > Subject: FW: TECH: 11i architecture (Forms consuming lot of memory)
> >
> >
> > Can anybody using Web Forms confirm the explanation below?
> >
> > May be Duncan can clarify?
> >
> > -----Original Message-----
> > Sent: Thursday, September 28, 2000 3:57 PM
> > To: OAUGnet
> >
> >
> > I have no hard data, but here's my take on it. Oracle Forms was built
> > to be a single-user environment, and Web publishing of forms was
> > bolted on. Instead of designing a multi-user system architecture
> > employing shared services and shared common code and memory, Oracle
> > tweaked Forms to create an entirely new runtime environment for every
> > user session.
> >
> > The analogy that works for me is the "Run in separate memory space"
> > check box available for 16-bit app shortcuts on MS Windows NT. This
> > actually causes NT to start a new VDM (virtual DOS machine) for each
> > app instead of reusing an existing VDM.
> >
> > In both cases, memory gets slurped up at an alarming rate.
> >
> > The reduced memory requirements in UNIX are almost certainly due to
> > the fact that subsequent sessions share the f60* executable code
> > already resident in memory. That's something NT doesn't grok, to my
> > knowledge. However, opening forms soaks up more memory for every
> > session. Wouldn't it be nice if Oracle's Forms architecture could
> > reuse form descriptions after loading them to memory just once?
> > Instead of paying 12Mb of RAM for every instance of the Order Entry
> > Workbench running on the server, you could pay 12Mb for the first and
> > 2-3Mb for all others just to preserve stack and state data.
> >
> > There may be other reasons as well, but I am confident that the
> > shared-nothing runtime memory model is the primary culprit.
> >
> > I'd like to see Oracle break up the monolithic forms runtime
> > executables into services/daemons that share info about forms and
> > user session state. Not only would this improve hardware resource
> > usage, it would enable true reactive failover between middle tier
> > servers instead of the preventive hardware clustering required today.
> > --Chris Taylor
> >
> > --- Messick Charles J TSgt AFPC/DPDIPS
> > <Charles.Messick_at_afpc.randolph.af.mil> wrote:
> > > Greetings all,
> > >
> > > Would anybody happen to know why the application tier requires
> > > 8-10mb(Unix) or 12-15mb(NT) of memory per user? I'm looking for
> > > answer
> > > beyond the 'because Oracle says so' sort of thing. We're still
> > > looking at
> > > moving to 11i and that question was asked.
> > >
> > >
> > > TSgt CJ Messick
> > > HQ Air Force Personnel Center
> > > cj.messick_at_afpc.randolph.af.mil
> > >
> > > The opinions expressed are those of the individual and do not
> > > represent an
> > > official position of the United States Air Force.
> > >
>
> --
> ODTUG 2000 was a great success! Visit our website at www.odtug.com for
> photos, highlights and presentation handouts. And plan now for ODTUG
> 2001 (June 24 to 28) at the Sheraton Hotel and Marina in San Diego, CA.
> --
> Author: Zetie, Carl
> INET: CZetie_at_gigaweb.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ODTUG-DEV2K-L
Received on Fri Sep 29 2000 - 15:13:16 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US