I’ve just updated Typo to r1303 today. After migrating the database to
version 58 everything seemed to work fine. Unfortunately my fcgi
instance seems to die after a few minutes. But I don’t get any entry in
any log/ file. Should I look somewhere else?
I’m running on Textdrive if that makes any difference. But I don’t
think I’m hitting the memory limit as I’m not getting any messages
from the process killing big processes (how was that called again?). At
least I don’t think I am. It should write something into a file in my
home dir, shouldn’t it?
Also I’m using the new tmcode macro. Maybe that may be part of my
problem?
home dir, shouldn’t it?
I don’t know about the workings of TextDrive; I do know they have
pretty tight limits on memory use, but I don’t know where you’d find
out about what processes got reaped.
Certainly dying without informing the logfile of anything smacks of
being 'kill -9’d by a resource limiter.
Do you get anything at all added to your logfile?
Also I’m using the new tmcode macro. Maybe that may be part of my
problem?
Possibly. I’ve not looked at its workings to be honest.
least I don’t think I am. It should write something into a file in my
home dir, shouldn’t it?
Also I’m using the new tmcode macro. Maybe that may be part of my
problem?
What happens if you roll back to r1299?
That takes it back to rails 1.1.6. If it’s stable, I’d appreciate it
if you could then step forward to r1300 check that for stability.
If it’s stable, move forward one step at a time checking each version
for stability, which should help us nail down which specific changes
are responsible for what I’m assuming is a memory leak issue.
If it was killed by TxD’s samurai process, then you will see a
process_watchdog.log in your home directory which lists why/when/what was
killed.
Fair enough. I wonder what is causing it then. I can’t replicate the
issue here at the moment, but I’m giving whiteboards a hard look at
the moment because they don’t quite work right at the moment.
That takes it back to rails 1.1.6. If it’s stable, I’d appreciate it
if you could then step forward to r1300 check that for stability.
If it’s stable, move forward one step at a time checking each version
for stability, which should help us nail down which specific changes
are responsible for what I’m assuming is a memory leak issue.
I’ll try tomorrow. Is there anything special to be aware of? Like
having to migrating the database back?
If it’s stable, move forward one step at a time checking each version
Go to main admin page
output?
Development probably doesn’t give more output, and probably breaks, if
anything earlier. But it might be worth trying.
One other thing to try is to change blog.rb, text_filter.rb and
user.rb back to using ActiveRecord::Base rather than CachedModel as
their super classes.
If you do remove the CachedModel inheritance stuff, you can also
modify the beginning of app/controllers/application.rb so the opening
stanza looks like:
class ApplicationController < ActionController::Base
include LoginSystem
before_filter :reset_local_cache, :fire_triggers
before_filter :fire_triggers
after_filter :reset_local_cache
I’m afraid this sort of debugging is unlikely to be quick – I run
with a different hosting provider, or I could probably get at what’s
up a wee bit quicker. Thanks for your help with this.
Incidentally, Piers, if tmcode is causing a problem (such as increased
memory usage) I would say that points to an issue with the whiteboard
implementation. Since you said you’re giving whiteboards a hard look,
hopefully if that’s the case you’ll find it.
On the other hand, tmcode could just be a red herring.
Ah… try running in production mode; development mode leaks memory.
Try going back to a vanilla r1324 and uncommenting the
RAILS_ENV=production line in config/environment.rb
I actually run in production mode normally. I tried it again with r1324
(and the scribbish theme instead of one not supplied in the Typo tree)
and I get the same error.
So, what do we know?
Migrations went smoothly and you’re on schema version 61
Textdrive isn’t killing stuff because it’s not putting any reports
in your home directory
Ah… try running in production mode; development mode leaks memory.
Try going back to a vanilla r1324 and uncommenting the
RAILS_ENV=production line in config/environment.rb
I actually run in production mode normally. I tried it again with r1324
(and the scribbish theme instead of one not supplied in the Typo tree)
and I get the same error.
Migrations went smoothly and you’re on schema version 61
Textdrive isn’t killing stuff because it’s not putting any reports
in your home directory
Typo’s dying before it logs anything.
Sometimes I get the message “[FATAL] failed to allocate memory” on
the console that I started the FCGI on. BTW, maybe it’s of interest: I’m
running Typo as an FCGI process using lighttpd. I mean, I start the FCGI
using “spawn-fcgi” and tell lighttpd where to find the socket.
Does it always die in the same place?
Not really. It seems that the problem occurs whenever Typo tries to load
a new page that isn’t in the cache, yet. Sometimes it works for a page
more, but once I try to load another page that isn’t in the cache (or so
I’m guessing) it blows up.
the console that I started the FCGI on. BTW, maybe it’s of interest: I’m
running Typo as an FCGI process using lighttpd. I mean, I start the FCGI
using “spawn-fcgi” and tell lighttpd where to find the socket.
Oh crap. Memory leak. I hate memory leaks.
Does it always die in the same place?
Not really. It seems that the problem occurs whenever Typo tries to load
a new page that isn’t in the cache, yet. Sometimes it works for a page
more, but once I try to load another page that isn’t in the cache (or so
I’m guessing) it blows up.
Typo’s dying before it logs anything.
Does it always die in the same place?
Not really. It seems that the problem occurs whenever Typo tries
to load
a new page that isn’t in the cache, yet. Sometimes it works for a
page
more, but once I try to load another page that isn’t in the cache
(or so
I’m guessing) it blows up.
Bugger. Definitely a memory leak.
Seems like. BTW, thanks for all the help tracking down this bug!