It's probably not Rails itself...

I had a similar issue, which turned out to be a bad Rails plugin, which maintained a few unnecessary pointers to my model classes. The small plugin caused a 20+MB per request leak in development. I rewrote the piece of functionality I needed from the offending module & the issue went away entirely.

Sadly, there isn't really decent memory profiler support to help you track it down. I found the issue by running `git bisect run` with a little script which restarted the server, beat on it a bit with `ab` and then printed memory usage with `ps`. Took me about 10 minutes to track it down to the exact offending commit.

How did you deal with the migrations problem? I usually can't bisect Rails code because there's no way to migrate from here to there anymore, let alone do so automatically..

I store the schema as SQL instead of the .rb file nightmare. Here's the script to do it quickly with Postgres & bypass the Rake slowness:

    #!/bin/bash

    root="/path/to/your/code"
    user='postgres'
    db='dev'
    schema="$root/db/schema.sql"

    pg_dump -U $user $db \
      --schema=public \
      --schema-only \
      --no-owner \
      --no-privileges \
      --file $schema

    pg_dump -U $user $db \
      --table public.schema_migrations \
      --no-owner \
      --data-only \
      --insert \
      >> $schema

Then a trivial `dropdb`, `createdb`, `psql < db/schema.sql`

And then a small script with 4 or 5 curl calls can get enough data into the database to drive some tests.

Gah, of course. Brilliant, especially skipping rake. (Though, pro tip: With Ruby 1.9.3, set export RUBY_GC_MALLOC_LIMIT=59000000 and you'll save 5-6 seconds at launch.)