[MTOS-dev] MT::Object::load_iter() problem
Hirotaka Ogawa
hirotaka.ogawa at gmail.com
Thu Mar 6 01:51:14 PST 2008
On Thu, Mar 6, 2008 at 3:42 AM, Brad Choate <brad at sixapart.com> wrote:
> Ogawa-san-- thanks for your continued work and feedback in this area.
> We're actively working on this as well, and I just realized two other
> places we stash things that may account for the remaining delta you're
> seeing.
> In MT::Object, there is a 'cache_property' method that is used
> to cache data in the object itself. I'm moving that cache storage into
> MT::Request, and will be committing that change soon into the
> release-31 branch.
I'm not sure this part. Do you mean that cache_property had been
bundled with MT::Object as a field, but now was moved to MT::Request?
So, cache_property would be able to be cleared safely and surely even
if its parent MT::Object was leaked.
> Also, when we look for the previous/next entry on a
> given entry object, a reference to that object is stored in the entry.
> This could be weakened, but I would prefer just storing the id-- the
> object is already cached in RAM, so keeping the id should be good
> enough.
>From view point of time-space tradeoffs, I think this is reasonable.
>
> -Brad
>
>
>
>
> On Mar 5, 2008, at 2:03 AM, Hirotaka Ogawa wrote:
>
> > MT::Object::load_iter() is really complicated.
> >
> > When ObjectDriver is DBI::sqlite, load_iter() fetches objects from
> > MT::OD::D::Cache::RAM, which looks up the internal cache first and
> > queries the database only when lookup failed.
> >
> > Otherwise, load_iter() fetches objects from MT::OD::D::DBI which
> > directly queries the database, and then stores fetched objects to
> > MT::OD::D::Cache::RAM, internal cache. That is, when using mysql or
> > postgres, cached objects stored by a load_iter() are never reused by
> > the next load_iter() requests. They could be reused only if they were
> > required by the next load() methods.
> >
> > In addition, objects loaded by load_iter() seem to be leaked. After
> > calling $MT::Object::DRIVER->clear_cache() which clears all contents
> > of the internal cache, some objects are never destroyed and still
> > remain in memory.
> >
> > To fix this situation, load_iter() fetches objects from
> > MT::OD::D::Cache::RAM[1] or MT::OD::D::DBI[2], without depending on
> > ObjectDriver setting.
> >
> > [1] Using MT::OD::D::Cache::RAM (same as DBI::sqlite case)
> >
> > sub load_iter {
> > my $class = shift;
> > my $driver = $class->driver;
> > return scalar $driver->search($class, @_);
> > }
> >
> > [2] Using MT::OD::D::DBI
> >
> > sub load_iter {
> > my $class = shift;
> > my $driver = $class->driver;
> > while ( $driver->isa('Data::ObjectDriver::Driver::BaseCache') ) {
> > $driver = $driver->fallback;
> > }
> > return scalar $driver->search($class, @_);
> > }
> >
> > But, after applying this modification, still leak remains.
> >
> > Using FCGI environment, I reapeatedly performed 'rebuild all' for a
> > relatively small blog with 237 entries, 390 comments, and 1745
> > trackbacks and measured RSS of the FCGI proccess.
> >
> > Without weaken:
> >
> > Initial 25,152KB
> > 1st rebuild 60,192KB
> > 2nd rebuild 87,144KB
> > 3rd rebuild 114,160KB
> > 4th rebuild 140,848KB
> > 5th rebuild 163,164KB
> >
> > With weaken:
> >
> > Initial 24,544KB
> > 1st rebuild 40,332KB
> > 2nd rebuild 46,388KB
> > 3rd rebuild 52,424KB
> > 4th rebuild 58,464KB
> > 5th rebuild 64,524KB
> >
> > With weaken + load_iter mods:
> >
> > Initial 24,528KB
> > 1st rebuild 38,032KB
> > 2nd rebuild 42,544KB
> > 3rd rebuild 46,908KB
> > 4th rebuild 51,204KB
> > 5th rebuild 55,708KB
> >
> > --
> > Hirotaka Ogawa makes no sense.
> > http://as-is.net/blog/
> > _______________________________________________
> > MTOS-dev mailing list
> > MTOS-dev at sixapart.com
> > http://www.sixapart.com/mailman/listinfo/mtos-dev
>
> --
> Brad Choate
> Engineering Manager, Movable Type, Six Apart, Ltd.
> http://www.sixapart.com/movabletype/
> Mobile: (918) 271-0105 - AIM: bschoate
>
>
>
>
>
--
Hirotaka Ogawa makes no sense.
http://as-is.net/blog/
More information about the MTOS-dev
mailing list