[typo] [FATAL] failed to allocate memory

Scott Laird scott at sigkill.org
Tue Aug 15 14:27:47 EDT 2006


One thing I'd recommend (if you aren't doing this already) is to build
a memory profiler component with an action that dumps your memory
profile data.  Then you can run zillions of queries without paying the
price of the memory profiler per hit, while still having your data
always be accessible.

If one of these was easily available, then I wouldn't have to write my
own when I start working on memory leaks.  Hint, hint.


Scott

On 8/15/06, Steve Longdo <steve.longdo at gmail.com> wrote:
> On TextDrive the profiling code has enough overhead it kills the thread
> sometimes.  I have noticed that the number of Blog objects seems to stack up
> over time though.  I've seen as many 22 instantiated at the same time.
> Considering that I only have one Blog that seems kind of high.
>
> Granted they don't take up much memory themselves, but I wonder if they hold
> on to arrays of Content objects and prevent them from being garbage
> collected.  I am still digging into it.
>
>
>  On 8/15/06, Piers Cawley <pdcawley at bofh.org.uk> wrote:
> > "Scott Laird" <scott at sigkill.org> writes:
> >
> > > On 8/15/06, Scott Laird <scott at sigkill.org> wrote:
> > >> On 8/15/06, Josh Knowles < joshknowles at gmail.com> wrote:
> > >> > On 8/15/06, Josh Knowles <joshknowles at gmail.com> wrote:
> > >> > > I thought it might be something like this but was given no log
> message
> > >> > indicating that my process was being killed.  Thanks for the link and
> the
> > >> > shove in the right direction!
> > >> >
> > >> > So even with the removal of the majority of the components my two
> processes
> > >> > are still hovering around 42-48meg, is this normal?
> > >> >
> > >> > Josh
> > >>
> > >> That's still higher then I'd like to see, but it's within the range
> > >> that people have reported.
> > >
> > > ...and having said that, I just checked mine, and I'm seeing 56-62 MB
> > > after two days.  And, more annoying, it's racked up about 9 hours of
> > > CPU time along the way.  Admittedly, this is a slow box (Athlon 700
> > > Mhz), and my blog is fairly busy.
> > >
> > > I'm not focusing on doing a lot of speed or memory improvements with
> > > 4.0 right now.  I'm going to release 4.0.3 with a couple more bug
> > > fixes soon, but after that I'm going to start concentrating on Typo
> > > 4.1.  One of the big goals for 4.1 is performance; if I find anything
> > > big and obvious, then I'll back-port the change to 4.0, but I don't
> > > want to experiment with 4.0--that's what 4.1 is for.
> >
> > I wonder how much affect the new regime of including more things has
> > had on memory usage? In theory we could be far more particular about
> > when we fetch stuff, but then we end up paying with more load on the
> > database server. It's all about the trade offs I'm afraid.
> >
> > --
> > Piers Cawley <pdcawley at bofh.org.uk>
> > http://www.bofh.org.uk/
> > _______________________________________________
> > Typo-list mailing list
> > Typo-list at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/typo-list
> >
>
>
>
> --
> Thanks,
> -Steve
> http://www.stevelongdo.com
> _______________________________________________
> Typo-list mailing list
> Typo-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/typo-list
>
>


More information about the Typo-list mailing list