IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Details?
Shared mem where? In the database?

Where is the Java code running? In the database? Out of the db, but on the same box? A different box?

If it's the shared memory in the database, and the Java process is not a Java stored proc, then it's not the Java running out of memory (sorry, Ross, you're full of crap :-). Oracle requires a lot of shared memory to run properly - it's used for many different things. Java may be trying to create a prepared statement on the fly, and Oracle is running out of memory trying to parse it because too many other things are using the shared memory at the moment.

Oracle recommends using half of the available RAM on the box for shared memory.

You might try pmap (if this is on Solaris) to figure out where it's going.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New No shit :)

If it's the shared memory in the database, and the Java process is not a Java stored proc, then it's not the Java running out of memory (sorry, Ross, you're full of crap :-). Oracle requires a lot of shared memory to run properly - it's used for many different things. Java may be trying to create a prepared statement on the fly, and Oracle is running out of memory trying to parse it because too many other things are using the shared memory at the moment.

I swear by my beard, I've seen non-stored-proc Java eat enormous chunks of RAM, with a starting point at 200M. Of course, it may have been shitty Java. This was not DB mem - this app was started on its own from a shell script and every VM started ate a huge gulp of its own RAM. This app did have a huge amount of logic in it, but no more than a typical large-scale business app of yore.

(Thinking back on this, I know why it needed such huge amounts of RAM. The purpose of the app was to route bank requests from any number of places to any number of other places as fast as possible, with a huge queue of requests possible - projected as many as tens of thousands per second - credit card transactions - and this app needed to build a huge tree structure to figure out an efficient route. That's a theory. I didn't write it :)
-drl
Expand Edited by deSitter Feb. 9, 2004, 09:23:39 AM EST
New Java can use a lot of RAM.
So can a lot of other languages.

Most RAM-hungry Java apps are either UI apps or just poorly written (or simply have large memory requirements like in-memory routing trees :-).

Weblogic (v. 5 or so) used a good 150M of RAM just to start up. The admin interface used about 130M (!) just to start up. As a comparison, Inprise's app server (which does pretty much the exact same thing as Weblogic) used 32M to start, as did the admin program. Much of that is the JVM simply grabbing a large block of memory at the start so it doesn't have to get it piecemeal later on (which can lead to memory fragmentation).

Regardless, the error message that Bill is seeing is coming from within the Oracle process, not the JVM.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
     oracle/java expertise please - (boxley) - (10)
         Java threads are out of memory - (deSitter) - (2)
             209 at present have ability to bump to 400 whaddya think? -NT - (boxley) - (1)
                 Let the experts here say - (deSitter)
         Details? - (admin) - (2)
             No shit :) - (deSitter) - (1)
                 Java can use a lot of RAM. - (admin)
         While I don't know about memory allocation/verification with - (Simon_Jester) - (3)
             thru the app yes, to public - (boxley) - (2)
                 I meant, does the app have permission to do the select - (Simon_Jester) - (1)
                     yes that app has permissions - (boxley)

Sounds like a horse. Maybe it was.
120 ms