I don't know much about PostgreSQL with plJava, but I can give a few
tips about memory stability when using Java (see inline):
Em 19/11/2012 14:55, Achilleas Mantzios escreveu:
Hello Peter, glad to meet you again after http://2012.pgconf.eu !
On Δευ 19 Î?οε 2012 16:26:56 you wrote:
On 19 November 2012 08:02, Thomas Hill <Thomas.K.Hill@xxxxxxxxxxx> wrote:
was wondering if there is anyone wanted to share some experiences gained and
some knowledge on pl/Java. Have looked into it for a couple of days now and
am getting the impression it is not something ready to use in production
environment. Also have trouble sending to the developer mailing list (the
last email on the mail archive of that list is almost three weeks old) which
raises questions on how active this project is.
I'd caution you against using pl/java in production. I came up against
a problem with it that I could not find a satisfactory solution for.
Essentially, each Postgres backend (connection process) must start its
own JVM, and does so using the JNI. If native memory runs out (I
realise that this may not actually be due to malloc() returning NULL,
but the effect is about the same), this failure is handled rather
poorly. It results in an OutOfMemoryError due to "native memory
exhaustion".
This is the situation in J2EE app servers as well, once OutOfMemoryError is thrown
there is not much the admin can do besides killing/restarting the app server.
If you uses JDK 6, would worth make a test using JRockit - it's memory
management is far more stable than default Oracle/Sun JVM.
I've servers that run for months without restart, even reloading classes
to accomodate code changes.
The biggest problem with JVM is class reloading, since nursery is not
garbage collected (or, at least, is not effective as it should be).
JRockit uses a different approach, so it's not affected by this problem.
But eventually even JRockit will run out of memory if you don't use the
right approach.
In the past, one choice was using static classes whenever possible. This
is not true (neither recommended) anymore, and in most of the cases
having thousands of cicles creation-use-release makes GC more effective
(and your VM more stable).
This results in a segfault of the Postgres backend,
originating from within libjvm.so. There is a workaround - which is to
set the maximum JVM heap size to a sufficiently low value -
Wouldn't that just make the problem manifest itself earlier?
but in
general the need to do so left me with a very low opinion of pl/java
as a project.
However, in most cases this error denotes a system (jvm itself) memory leak,
an insufficient garbage collector operation or a poorly designed application.
In the java 7, i heard good stories about the new G1 garbage collector.
I've been using JDK 7 with G1 GC for hosting NetBeans and Tomcat, and
once you don't have lots of class reload, you get a stable environment.
JDK 7 still suffer of nursery (or whatever the new name they put in)
issues, and classes are not properly disposed. I don't even think this
is a Java issue - most Object Oriented Virtual Machines that relay on
garbage collection suffer of the same issue (references are kept and
then objects are never released, so classes cannot be disposed).
Regards,
Edson Richter
We have never tried pl/java, despite being a postgresql/java house, and this is definitely
something we are looking forward to explore, but i agree with Thomas that the traffic on the list
is low which points to what Peter is suggesting about being scared to use this in production environments.
That would be very cool if it was much more active and stable.
-
Achilleas Mantzios
IT DEV
IT DEPT
Dynacom Tankers Mgmt
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
