Re: Re: [ADMIN] High memory usage [PATCH]

From: "Dave Cramer" <Dave(at)micro-automation(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Rainer Mager" <rmager(at)vgkk(dot)com>
Cc: "PostgreSQL jdbc list" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Re: [ADMIN] High memory usage [PATCH]
Date: 2001-06-22 00:33:59
Message-ID: 018601c0fab3$082dc080$0201a8c0@INSPIRON
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-jdbc pgsql-patches

my two cents worth...

1) what is the problem that this is trying to solve, I assume from the
subject that it is some sort of high memory usage?
2) I am trying to understand how a statement would ever be used by more than
one thread at a time? I would think that it would be impossible to share
statements across threads.
3) The double locking method used is alledgedly unsafe on SMP machines
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double_p.html.

Dave

----- Original Message -----
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Rainer Mager" <rmager(at)vgkk(dot)com>
Cc: "PostgreSQL jdbc list" <pgsql-jdbc(at)postgresql(dot)org>; "PostgreSQL-patches"
<pgsql-patches(at)postgresql(dot)org>
Sent: Thursday, June 21, 2001 6:23 PM
Subject: [JDBC] Re: [ADMIN] High memory usage [PATCH]

>
> JDBC folks, can you comment on this patch? Thanks.
>
>
> > Attached is my patch to the official 7.1.2 PreparedStatement.java class.
> > This seems to work quite well for me in a test case. To try to reproduce
the
> > seen problem I will need to test all night. I'll report tomorrow.
> >
> > BTW, this is my first attempt at making a unified diff so I might have
done
> > something wrong. If this diff doesn't apply please tell me.
> >
> > --Rainer
> >
> > > -----Original Message-----
> > > From: pgsql-admin-owner(at)postgresql(dot)org
> > > [mailto:pgsql-admin-owner(at)postgresql(dot)org]On Behalf Of Rainer Mager
> > > Sent: Wednesday, June 20, 2001 9:08 AM
> > > To: Tom Lane
> > > Cc: PostgreSQL Admin
> > > Subject: RE: [ADMIN] High memory usage
> > >
> > >
> > > I'll work on a patch but if someone has already done this I would be
> > > grateful.
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>

----------------------------------------------------------------------------
----

> --- PreparedStatement.java Sat Feb 17 01:45:00 2001
> +++ PreparedStatement.java.new Wed Jun 20 12:34:57 2001
> @@ -39,10 +39,12 @@
> // Some performance caches
> private StringBuffer sbuf = new StringBuffer();
>
> - // We use ThreadLocal for SimpleDateFormat's because they are not
that
> - // thread safe, so each calling thread has its own object.
> - private ThreadLocal tl_df = new ThreadLocal(); // setDate()
SimpleDateFormat
> - private ThreadLocal tl_tsdf = new ThreadLocal(); //
setTimestamp() SimpleDateFormat
> + // Because SimpleDateFormat is not thread safe we create one for each
> + // PreparedStatemnt here AND synchronize on it for each usage.
> + // We can NOT use ThreadLocal because they are not freed until the
thread
> + // completes. This would be a memory leak for long running threads.
> + private SimpleDateFormat df = null;
> + private SimpleDateFormat tsdf = null;
>
> /**
> * Constructor for the PreparedStatement class.
> @@ -90,9 +92,6 @@
> * New in 7.1 - overides Statement.close() to dispose of a few
local objects
> */
> public void close() throws SQLException {
> - // free the ThreadLocal caches
> - tl_df.set(null);
> -
> super.close();
> }
>
> @@ -332,14 +331,18 @@
> */
> public void setDate(int parameterIndex, java.sql.Date x) throws
SQLException
> {
> - SimpleDateFormat df = (SimpleDateFormat) tl_df.get();
> - if(df==null) {
> + // The df DateFormat is initialized here to delay creation until needed.
> + if( df == null ) {
> + synchronized( this ) {
> + if( df == null ) {
> df = new SimpleDateFormat("''yyyy-MM-dd''");
> - tl_df.set(df);
> + }
> + }
> }
>
> - set(parameterIndex, df.format(x));
> -
> + // We must synchronize here because SimpleDateFormat is not thread safe.
> + synchronized( df ) {
> + set( parameterIndex, df.format(x) );
> // The above is how the date should be handled.
> //
> // However, in JDK's prior to 1.1.6 (confirmed with the
> @@ -351,6 +354,7 @@
> //
> //set(parameterIndex, df.format(new
java.util.Date(x.getTime()+86400000)));
> }
> + }
>
> /**
> * Set a parameter to a java.sql.Time value. The driver converts
> @@ -375,17 +379,22 @@
> */
> public void setTimestamp(int parameterIndex, Timestamp x) throws
SQLException
> {
> - SimpleDateFormat df = (SimpleDateFormat) tl_tsdf.get();
> - if(df==null) {
> - df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> - tl_tsdf.set(df);
> + // The tsdf DateFormat is initialized here to delay creation until
needed.
> + if( tsdf == null ) {
> + synchronized( this ) {
> + if( tsdf == null ) {
> + tsdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> + tsdf.setTimeZone(TimeZone.getTimeZone("GMT"));
> + }
> + }
> }
> - df.setTimeZone(TimeZone.getTimeZone("GMT"));
>
> + // We must synchronize here because SimpleDateFormat is not thread safe.
> + synchronized( tsdf ) {
> // Use the shared StringBuffer
> synchronized(sbuf) {
> sbuf.setLength(0);
> -
sbuf.append("'").append(df.format(x)).append('.').append(x.getNanos()/100000
00).append("+00'");
> +
sbuf.append("'").append(tsdf.format(x)).append('.').append(x.getNanos()/1000
0000).append("+00'");
> set(parameterIndex, sbuf.toString());
> }
>
> @@ -393,6 +402,7 @@
> // to be identical. Pays to read the docs ;-)
> //set(parameterIndex,"'"+x.toString()+"'");
> }
> + }
>
> /**
> * When a very large ASCII value is input to a LONGVARCHAR parameter,
>

----------------------------------------------------------------------------
----

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Yasuo Ohgaki 2001-06-22 02:31:08 Re: Gradual increase in CPU utilization by postmaster
Previous Message Gerard Mason 2001-06-21 23:43:21 Re: pg_dump dumps views as tables???

Browse pgsql-jdbc by date

  From Date Subject
Next Message Rainer Mager 2001-06-22 04:56:17 RE: Re: [ADMIN] High memory usage [PATCH]
Previous Message Bruce Momjian 2001-06-21 22:23:58 Re: [ADMIN] High memory usage [PATCH]

Browse pgsql-patches by date

  From Date Subject
Next Message Marko Kreen 2001-06-22 00:36:40 Re: use GUC for cmdline
Previous Message Tom Lane 2001-06-21 23:50:44 Re: use GUC for cmdline