View Full Version : data.db is really large

04-11-2011, 07:45 PM
resin-data/default/distcache/data.db is currently at 19GB on our production instance. What exactly is in this file, and is there a configuration setting that can cap it to a reasonable size akin to log rotation?

04-14-2011, 02:51 AM
That file is the persistent store for persistent sessions.

Which is the typical size of your sessions and how many would normally be alive?

04-14-2011, 02:24 PM
It's an internal site, so we don't typically have more than 10-20 users at a time, if that. I'm not sure how big the session data should be, but we have been hearing reports of performance degradation over time, so that gives me an idea of what to look for. Is there a way to see what's in the db?

04-14-2011, 10:30 PM
That's much too large then. It has to be a bug.

Which exact version of Resin is this with?

04-14-2011, 10:41 PM
We're using Resin 4.0.14 Pro with five webapps.

I was thinking about what we might doing wrong. One is that we're running Spring Webflow, but we don't necessarily use them as a process with a beginning and an end, so the data might not get evicted from the session. This would explain why our users are seeing degraded performance as they use the site more.

We also have another form that is binding too many values (100-1000) to a drop-down box. We get OutOfMemoryError exceptions when we call up this form, but I haven't checked to see if this goes into the session data.

04-15-2011, 07:17 PM
It sounds more like a Resin bug, because with only 20 users, it really shouldn't matter how big your data is.

This may already be fixed in 4.0.16, but I'll take a look in 4.0.18 to see if we can duplicate it here.

04-24-2012, 03:11 PM
Was this issue determined to be a Resin bug? We have recently upgraded from Resin 3.0 (clustered sessions disabled) to Resin 4.0.23 (clustered sessions enabled) and the size of data.db has grown daily over the past week to its current size of 9.6GB on the triad servers. We probably have somewhere on the order of 10,000 users and we are setting the session-timeout to 2 hours.

The interesting thing is the size of the file remains pretty stable over the course of the day, and then when we check in the morning it will have jumped in size by about 2GB. This seems strange considering the vast majority of traffic occurs during business hours.

We have not noticed any problems with performance otherwise. Is there anything we can do to prevent the size of this file from growing?


04-24-2012, 05:49 PM
This is now being tracked here: