Just the -XX:+HeapDumpOnOutOfMemoryError you already have. Tomcat
usually doesn't shut down nicely (as evidenced by the "pausing" of
connectors in your log file) when you get an OOME. Are you sure that
weekly Tomcat-restart process isn't still running?
Yes, it's still running. Should i disable it?
Are you using a database? Are you using pooled connections? If
so, enable "abandoned" tracing if that's a possibility for you
(Tomcat's two built-in choices of dbcp can do abandoned
tracing).
Yes, a mysql database and pooled connections. How can I enable
that abandoned tracing?
Check the documentation for DBCP (which Tomcat uses) here:
http://commons.apache.org/dbcp/configuration.html
I have set logAbandoned=true. I haven't enabled the removeAbandoned and
the removeAbandonedTimeout just in case. Will I get the info in the
catalina log?
I enabled slow queries for mysql, but the developer claims the
queries are fine (although some report more than a second to be
run).
Well, are you actually seeing slow queries in MySQL? It's not good
enough to just enable logging... you have to read the log ;)
I can revert the GC strategy. the verbose options for GC are fine?
Sure: that's just logging. You will have a miniscule performance
degradation due to the logging, but I'm sure it's worth it to see what
is happening.
I'll retake that path of checking mysql indexes and slow queries.
Just use mysqldumpslow to be sure. Also, if you suspect a query, use
EXPLAIN on it. Mysqldumpslow be default "anonymizes" queries so you
can see a "class" of equivalent queries that are failing. MySQL
determines its query plan based not just upon the structure of the
query, but also upon the data and the indexes that are available at
the time of the query. You might want to disable this anonymizing of
the dat to get an /actual/ query that was slow. Then run EXPLAIN on
that to see what the plan was: maybe MySQL is making a bad decision,
or maybe you need an additional index. Or maybe the query is just
written poorly in the first place. MySQL is notorious for using
DEPENDENT SUBQUERIES (awful performance) when such a query is not
necessary.
I'll check about the anonymizing thing.
Right now I get the following cronjob forwarded to my email
/usr/bin/mysqldumpslow -s -t /var/log/mysql-slow.log | mail -s ....
Yes, I have pinpointed several queries that took quite long and
specially subqueries. I forwarded this info to the developer but she
said it was alright. More than a second to run a query seems to be a lot
to me. The problem is that since the database E/R is not documented,
it's going to take a while to improve the performance of the queries.
The developer is quitting so I hope a new developer is more cooperative
and we can work out these things.
In the meantime I will check what I can do. I have also downloaded
mysqltuner script and mysqlfragfinder a long time ago and follow the
output of these tuning scripts.
That we have outgrown our hardware, that's probably for sure. This
a virtual private server. I have said the owners to move to a
dedicated server but I guess they want me to squeeze this VPS as
much as I can.
Sheesh, if it's virtualized, just have them provision a larger
instance for you and move the virtual machine. I'd recommend a 64-bit
OS/JVM so you can get heaps bigger than about 1.5GiB.
:-) I'm trying to convince them.
Many thanks for your inputs, you have been very helpful
Miguel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
