Re: JDBC HIGH CPU and Restart Issue

["Joe Sam Shirah" <joe_sam@xxxxxxxxxxxxx>]

   Hi Pete,

   As I understood Paul's post, he's running Tomcat on a Windows server.
Just some comments to your response from my experience:

> If you download tomcat, bin/catalina.sh contains code that sets the
> server job priority to 6.

   One of many reasons that I always try to put server apps on a separate
box and let the AS/400 do the things it handles best.

> The heap should (I am advised) be large
> enough to handle application startup without garbage collection.

   This depends on whether you are using the 32 bit or classic JVM, and is
an area where Java folks without an AS/400 background can get you into
trouble, unless you have a dedicated machine.  At one client, the experts
clapped themselves happily on the back for "solving" a JVM memory problem.
The only issue is that they permanently took away 8 gig of memory from the
other users and jobs on the machine.

> but be aware that java does a lot more paging than a (for instance) rpg

   With the classic JVM, a major goal is to avoid disk paging altogether.
That's mostly due to asynchronous gc, but also performance in general.

   As always, my free advice is guaranteed to be worth what you paid for
it.


                                                        Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400

----- Original Message ----- 
From: "Pete Hall" <pete@xxxxxxxxxxxxxx>
Newsgroups: midrange.java400-l
To: <java400-l@xxxxxxxxxxxx>
Sent: Thursday, May 06, 2010 7:25 PM
Subject: Re: JDBC HIGH CPU and Restart Issue


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> pholm@xxxxxxxxxxxxxxxxx wrote:
> >    All,
> >    I've found some related info on google but nothing definitive.
> >    Environment:  V5R4 iSeries acting as database with Tomcat and
> >    JDBC/connection pools hosted on a Windows server.
> >    Problem:  Occasionally the QZDASOINT job servicing the JDBC will
> > consume
> >    most CPU.  I've lowered the QZDASOINIT priority to 30 to lessen the
> > impact
> >    to interactive users.  However the problem and high cpu persist
> >    occasionally.  If we do a ENDJOB on these jobs they are restarted
> >    automatically and resume using too much CPU.  If we end Tomcat the
> > jobs go
> >    away.  Restarting Tomcat restarts the QZDASOINIT jobs.  We have
> > connection
> >    pool code but we do not have any logic to reissue JDBC queries to the
> >    system.  I suspect it to be an i5 issue.  Has anyone experienced the
> > issue
> >    or have insight?
> >    Thanks, Paul Holm
>
> If you download tomcat, bin/catalina.sh contains code that sets the
> server job priority to 6. That's one issue. It should never be that low.
>
> A second problem might be heap size and garbage collection cycles
> processing during startup. The heap should (I am advised) be large
> enough to handle application startup without garbage collection.
>
> A third issue might be paging, if the storage pool isn't large enough,
> but be aware that java does a lot more paging than a (for instance) rpg
> program. Look at this after the first two are handled.
>
> - --
> Pete Hall
> pete@xxxxxxxxxxxxxx
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvjT+EACgkQXczQcKdXKg79OQCfTb6M/QVkFq+IwFhL4VglGVcx
> e1cAoKyEIkXCsdk0Osgk1K7gx9L5T5Qn
> =OVS3
> -----END PGP SIGNATURE-----
> --
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.