Stable Typo on Textdrive
[ Posted by Urban Hafner ]
This Typo blog is hosted on Textdrive, which is a really nice hosting company. More in the style of the guys next door than your average company that just wants to make money.
One problem though is that I have a shared account on one of their severs and therefore have rather strict limits on the number of processes I can run and their memory consumption. This is of course understandable as otherwise it wouldn’t be possible for them to offer such accounts. The problem I had for a long time with this was that my blog consumed quite some memory and got killed quite regularly. To keep it running most of the times I created a cron job that I ran 4 times a day to kill my Rails fcgi instance and spawn a new one:
#!/bin/sh
APP=www
ROOT=/users/home/hafner/bettong.net/$APP
TMP=/users/home/hafner/var/run
# Kill the old process
date
kill -9 `cat $TMP/$APP-0.pid`
sleep 1
# Start a new one
RAILS_ENV=production /usr/local/bin/spawn-fcgi -f $ROOT/public/dispatch.fcgi \
-s $TMP/$APP-0.socket -P $TMP/$APP-0.pid
Unfortunately that didn’t always work. Sometimes the spawn-fcgi exited complaining that I couldn’t allocate enough memory. But it worked well enough to keep the site running often enough.
Some days ago while restoring my Typo database (don’t worry, Typo didn’t mess up anything, it was entirely my fault that I deleted all comments while only trying to delete the spam … Oh, well) I noticed that the session table was quite full. So I created another cron script that would remove all session entries older that 3 days:
#!/bin/sh
echo "Clear Typo session table"
/usr/local/bin/ruby /home/hafner/bettong.net/www/script/runner \
'ActiveRecord::Base.connection.delete("DELETE FROM sessions WHERE updated_at < now() - INTERVAL 72 HOUR")'
Interestingly though since then my blog has been running much more stable (i.e. the restart-rails.sh cron job always had to kill the Rails fcgi before spawning a new one which certainly hasn’t been the case before). So I’ve now reduced the number of times restart-rails.sh is called to twice a day. So maybe the whole contents of the session table is loaded into memory and that caused the process to be so big. I’ll see how the process behaves when running for half a day and if that works out I’ll gradually increase the running time of the process. I’ll report back to you when I have some more data.
