5 ms·

I can only hope that running my app in dev mode in 3.2 won't bleed memory 40 MB per request. I have no such issues in production environment and it makes testin

I can only hope that running my app in dev mode in 3.2 won't bleed memory 40 MB per request. I have no such issues in production environment and it makes testing/debugging a royal pain.

snprbob86 15y ago
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.
- jaylevitt 15y ago
  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..
  - snprbob86 15y ago
    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.
    - jaylevitt 15y ago
      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.)

I can only hope that running my app in dev mode in 3.2 won't bleed memory 40 MB per request. I have no such issues in production environment and it makes testing/debugging a royal pain.

snprbob86 15y ago

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.

jaylevitt 15y ago
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..
- snprbob86 15y ago
  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.
  - jaylevitt 15y ago
    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.)