Mongrel users - Jan 2007 - mongrel memory usage ballooning and process stomping

Hi,
  I have mongrel 0.3.14, with ruby 1.8.5, rails 1.1.6 and mongrel cluster
0.2.1, on debian sage 3.1 with apache 2.0, and fastthread 0.6.1.
I am load balancing 3 mongrel processes using the random port trick.

When I start mongrel the processes have about 60MB, but after some hour of
usage the memory ballons upto more than 180MB and the site becomes terribly
slow. Forcing me to restart mongrel cluster.

Also, it reports me 9 mongrel processes instead of three. I am not able to
understand why that''s happening. Are really 9 mongrel processes started
instead of three?

Please help. Thanks.

ssinghi at galle1:~$ ps aux|grep mongrel
ssinghi  18252  6.6 20.2 198464 183200 ?     S    05:47  17:09
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a
127.0.0.1 -P log/mongrel.8002.pid -c /home/ssinghi/test.com/current
ssinghi  18257  0.0 20.2 198464 183200 ?     S    05:47   0:00
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a
127.0.0.1 -P log/mongrel.8002.pid -c /home/ssinghi/test.com/current
ssinghi  18258  0.0 20.2 198464 183200 ?     S    05:47   0:00
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a
127.0.0.1 -P log/mongrel.8002.pid -c /home/ssinghi/test.com/current
ssinghi  18276  6.6 20.3 199324 184576 ?     S    05:47  17:07
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a
127.0.0.1 -P log/mongrel.8000.pid -c /home/ssinghi/test.com/current
ssinghi  18279  6.4 20.4 200772 185528 ?     S    05:47  16:37
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a
127.0.0.1 -P log/mongrel.8001.pid -c /home/ssinghi/test.com/current
ssinghi  18283  0.0 20.3 199324 184576 ?     S    05:47   0:00
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a
127.0.0.1 -P log/mongrel.8000.pid -c /home/ssinghi/test.com/current
ssinghi  18284  0.0 20.3 199324 184576 ?     S    05:47   0:00
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a
127.0.0.1 -P log/mongrel.8000.pid -c /home/ssinghi/test.com/current
ssinghi  18285  0.0 20.4 200772 185528 ?     S    05:47   0:00
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a
127.0.0.1 -P log/mongrel.8001.pid -c /home/ssinghi/test.com/current
ssinghi  18286  0.0 20.4 200772 185528 ?     S    05:47   0:00
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a
127.0.0.1 -P log/mongrel.8001.pid -c /home/ssinghi/test.com/current
ssinghi  19556  0.0  0.0  1820  572 pts/0    R+   10:06   0:00 grep mongrel


My mongrel_cluster.yml file has

cwd: /home/ssinghi/test.com/current
port: "8000"
environment: production
address: 127.0.0.1
pid_file: log/mongrel.pid
servers: 3


-- 
Surendra Singhi
http://ssinghi.kreeti.com, http://www.kreeti.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20070117/013a243a/attachment-0001.html

How are the mongrel started (cron, launchd, etc)? I had something
similar happen to me, but I think it was from the cluster being
started by root instead of the user I wanted to start it. It gave me
an extra set of mongrel processes running that mongrel_rails
cluster::stop wouldn''t stop.

Michael B.

On 1/17/07, Surendra Singhi <singhi.surendra at gmail.com>
wrote:
> Hi,
>   I have mongrel 0.3.14, with ruby 1.8.5, rails 1.1.6 and mongrel cluster
> 0.2.1, on debian sage 3.1 with apache 2.0, and fastthread 0.6.1.
> I am load balancing 3 mongrel processes using the random port trick.
>
>  When I start mongrel the processes have about 60MB, but after some hour of
> usage the memory ballons upto more than 180MB and the site becomes terribly
> slow. Forcing me to restart mongrel cluster.
>
> Also, it reports me 9 mongrel processes instead of three. I am not able to
> understand why that''s happening. Are really 9 mongrel processes
started
> instead of three?
>
> Please help. Thanks.
-- 
Michael Biven
michael.biven at gmail.com
http://biven.org

Some linux distros have weird reporting of processes. I have seen it  
where top or ps will report 3 mongrels for each one that is really  
running. And looking at your output you can see that each set of  
three mongrels reported have the same port number. This means that  
you really only have 3 mongrels running because only one can be  
running per port at a time.

	As far as the memory usage goes, that sounds like a classic memory  
leak in your rails app. I have seen mongrel balloon like that when  
people add an extra :include directive to a find that ends up loading  
a ton of extra records into memory. If you are loading more then a  
few hundred ActiveRecords into memory on any one page then that will  
surely cause memory to ballon like this.

	A little more info about your app and what it does woudl help debug.  
Are you using Rmagcik? Are you useing send_file or send_data to  
stream out large content?


Cheers-
-Ezra



On Jan 17, 2007, at 10:36 AM, Michael Biven wrote:
> How are the mongrel started (cron, launchd, etc)? I had something
> similar happen to me, but I think it was from the cluster being
> started by root instead of the user I wanted to start it. It gave me
> an extra set of mongrel processes running that mongrel_rails
> cluster::stop wouldn''t stop.
>
> Michael B.
>
> On 1/17/07, Surendra Singhi <singhi.surendra at gmail.com> wrote:
>> Hi,
>>   I have mongrel 0.3.14, with ruby 1.8.5, rails 1.1.6 and mongrel  
>> cluster
>> 0.2.1, on debian sage 3.1 with apache 2.0, and fastthread 0.6.1.
>> I am load balancing 3 mongrel processes using the random port trick.
>>
>>  When I start mongrel the processes have about 60MB, but after  
>> some hour of
>> usage the memory ballons upto more than 180MB and the site becomes  
>> terribly
>> slow. Forcing me to restart mongrel cluster.
>>
>> Also, it reports me 9 mongrel processes instead of three. I am not  
>> able to
>> understand why that''s happening. Are really 9 mongrel
processes
>> started
>> instead of three?
>>
>> Please help. Thanks.
>
> -- 
> Michael Biven
> michael.biven at gmail.com
> http://biven.org
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

Is there anything you can do to force garbage collection in a case
like this? (loading in a few hundred records, or using send_file,
send_data?)

I already went through my application and removed RMagick (now using
mini-magick) but I''m still having monit restart a mongrel instance
every day (running 12, get maybe 2-4 restarts a day, even at odd times
like 2am, when there''s little use on the site)

Any help apprecaited. Thanks.

>         As far as the memory usage goes, that sounds like a classic memory
> leak in your rails app. I have seen mongrel balloon like that when
> people add an extra :include directive to a find that ends up loading
> a ton of extra records into memory. If you are loading more then a
> few hundred ActiveRecords into memory on any one page then that will
> surely cause memory to ballon like this.
>
>         A little more info about your app and what it does woudl help
debug.
> Are you using Rmagcik? Are you useing send_file or send_data to
> stream out large content?

I am seeing this same problem on my debian production server.  top  
shows the correct number of processes, but each mongrel instance and  
ruby running backgroundrb all are ballooning to 15% memory  
consumption within a day or two.  The application is http:// 
myfreecopyright.com

It may be in the code, but how do I troubleshoot this?

Cheers
-Matt


On Jan 17, 2007, at 2:34 PM, Ezra Zygmuntowicz wrote:
>
> 	Some linux distros have weird reporting of processes. I have seen it
> where top or ps will report 3 mongrels for each one that is really
> running. And looking at your output you can see that each set of
> three mongrels reported have the same port number. This means that
> you really only have 3 mongrels running because only one can be
> running per port at a time.
>
> 	As far as the memory usage goes, that sounds like a classic memory
> leak in your rails app. I have seen mongrel balloon like that when
> people add an extra :include directive to a find that ends up loading
> a ton of extra records into memory. If you are loading more then a
> few hundred ActiveRecords into memory on any one page then that will
> surely cause memory to ballon like this.
>
> 	A little more info about your app and what it does woudl help debug.
> Are you using Rmagcik? Are you useing send_file or send_data to
> stream out large content?
>
>
> Cheers-
> -Ezra
>
>
>
> On Jan 17, 2007, at 10:36 AM, Michael Biven wrote:
>
>> How are the mongrel started (cron, launchd, etc)? I had something
>> similar happen to me, but I think it was from the cluster being
>> started by root instead of the user I wanted to start it. It gave me
>> an extra set of mongrel processes running that mongrel_rails
>> cluster::stop wouldn''t stop.
>>
>> Michael B.
>>
>> On 1/17/07, Surendra Singhi <singhi.surendra at gmail.com> wrote:
>>> Hi,
>>>   I have mongrel 0.3.14, with ruby 1.8.5, rails 1.1.6 and mongrel
>>> cluster
>>> 0.2.1, on debian sage 3.1 with apache 2.0, and fastthread 0.6.1.
>>> I am load balancing 3 mongrel processes using the random port
trick.
>>>
>>>  When I start mongrel the processes have about 60MB, but after
>>> some hour of
>>> usage the memory ballons upto more than 180MB and the site becomes
>>> terribly
>>> slow. Forcing me to restart mongrel cluster.
>>>
>>> Also, it reports me 9 mongrel processes instead of three. I am not
>>> able to
>>> understand why that''s happening. Are really 9 mongrel
processes
>>> started
>>> instead of three?
>>>
>>> Please help. Thanks.
>>
>> -- 
>> Michael Biven
>> michael.biven at gmail.com
>> http://biven.org
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> -- Ezra Zygmuntowicz 
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

Hi,

First of all thanks everyone for their responses.

On 1/18/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
>         Some linux distros have weird reporting of processes. I have seen
> it
> where top or ps will report 3 mongrels for each one that is really
> running. And looking at your output you can see that each set of
> three mongrels reported have the same port number. This means that
> you really only have 3 mongrels running because only one can be
> running per port at a time.

The output of ''ps aefux'' is below. Though I don''t
understand ps completely
it seems that the one mongrel process spawns another child process, which in
turns spawns a third one.


ssinghi  22988  0.7 11.3 142900 102572 ?     S    21:53   0:24
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a
127.0.0.1 -P log/mon
ssinghi  22998  0.0 11.3 142900 102572 ?     S    21:54   0:00  \_
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a
127.0.0.1 -P log
ssinghi  23000  0.0 11.3 142900 102572 ?     S    21:54   0:00      \_
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a
127.0.0.1 -P
ssinghi  22991  0.9 12.0 131192 108844 ?     S    21:53   0:33
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a
127.0.0.1 -P log/mon
ssinghi  22996  0.0 12.0 131192 108844 ?     S    21:54   0:00  \_
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a
127.0.0.1 -P log
ssinghi  22997  0.0 12.0 131192 108844 ?     S    21:54   0:00      \_
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a
127.0.0.1 -P
ssinghi  22994  0.5 10.1 127980 92160 ?      S    21:53   0:18
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a
127.0.0.1 -P log/mon
ssinghi  22999  0.0 10.1 127980 92160 ?      S    21:54   0:00  \_
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a
127.0.0.1 -P log
ssinghi  23001  0.0 10.1 127980 92160 ?      S    21:54   0:00      \_
/usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a
127.0.0.1 -P



        As far as the memory usage goes, that sounds like a classic
memory
> leak in your rails app. I have seen mongrel balloon like that when
> people add an extra :include directive to a find that ends up loading
> a ton of extra records into memory. If you are loading more then a
> few hundred ActiveRecords into memory on any one page then that will
> surely cause memory to ballon like this.

Yes, we are doing eager loading at many places, and there is a sitemap part
where about 10,000 records are loaded. I will try to optimize those parts,
and see
if they make a difference.

        A little more info about your app and what it does woudl help
debug.
> Are you using Rmagcik?

Yes we are using that. I will look into mini-magick. Joey thanks for that.

Are you useing send_file or send_data to
> stream out large content?

We are streaming data for images.

We are also using ferret and mediacloth.

I guess, I need to investigate more on the above mentioned things.
Thanks a lot.

Surendra Singhi



On Jan 17, 2007, at 10:36 AM, Michael Biven wrote:
>
> > How are the mongrel started (cron, launchd, etc)? I had something
> > similar happen to me, but I think it was from the cluster being
> > started by root instead of the user I wanted to start it. It gave me
> > an extra set of mongrel processes running that mongrel_rails
> > cluster::stop wouldn''t stop.
> >
> > Michael B.
> >
> > On 1/17/07, Surendra Singhi <singhi.surendra at gmail.com>
wrote:
> >> Hi,
> >>   I have mongrel 0.3.14, with ruby 1.8.5, rails 1.1.6 and mongrel
> >> cluster
> >> 0.2.1, on debian sage 3.1 with apache 2.0, and fastthread 0.6.1.
> >> I am load balancing 3 mongrel processes using the random port
trick.
> >>
> >>  When I start mongrel the processes have about 60MB, but after
> >> some hour of
> >> usage the memory ballons upto more than 180MB and the site becomes
> >> terribly
> >> slow. Forcing me to restart mongrel cluster.
> >>
> >> Also, it reports me 9 mongrel processes instead of three. I am not
> >> able to
> >> understand why that''s happening. Are really 9 mongrel
processes
> >> started
> >> instead of three?
> >>
> >> Please help. Thanks.
> >
> > --
> > Michael Biven
> > michael.biven at gmail.com
> > http://biven.org
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Surendra Singhi
http://ssinghi.kreeti.com, http://www.kreeti.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20070118/9b203e83/attachment-0001.html

So in my application I am not using any of the mentioned culprits  
mentioned below which would cause the memory to balloon.

Here is my setup:
Debian 3.1
Rails 1.1.6
Ruby 1.8.5
Mongrel 0.3.18
Fastthread 0.6.1
Mongrel Cluster 0.2.1
Apache 2.2.3
Backgroundrb (can''t find the version but it is the last one before 2.x)

Here is ps:
3265  0.0 15.9  75380 62860 ?        Sl   Jan10   1:01  
backgroundrb                                                             
                            TERM=vt100 SHELL=/bin/bash
9577  0.0 12.0  59448 47520 ?        Sl   Jan15   0:20 /usr/bin/ 
ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8000 -a  
127.0.0.1 -P log/mongrel.8000.pid -c
9580  0.0 10.4  53208 41012 ?        Sl   Jan15   0:11 /usr/bin/ 
ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8001 -a  
127.0.0.1 -P log/mongrel.8001.pid -c
9584  0.0 12.0  59808 47536 ?        Sl   Jan15   0:09 /usr/bin/ 
ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 8002 -a  
127.0.0.1 -P log/mongrel.8002.pid -c

You can see that mongrel has slowly crept up to almost 60K of memory  
usage and backgroundrb is at 75K.  This app is not getting hammered  
and only has a steady usage. But every time I restart everything  
after a couple days everything creeps up to this high memory usage.

I am not using eager loading, nor RMagick.  Any ideas?  How should I  
troubleshoot this.

Thank you.

Matt




On Jan 17, 2007, at 2:34 PM, Ezra Zygmuntowicz wrote:
>
> 	Some linux distros have weird reporting of processes. I have seen it
> where top or ps will report 3 mongrels for each one that is really
> running. And looking at your output you can see that each set of
> three mongrels reported have the same port number. This means that
> you really only have 3 mongrels running because only one can be
> running per port at a time.
>
> 	As far as the memory usage goes, that sounds like a classic memory
> leak in your rails app. I have seen mongrel balloon like that when
> people add an extra :include directive to a find that ends up loading
> a ton of extra records into memory. If you are loading more then a
> few hundred ActiveRecords into memory on any one page then that will
> surely cause memory to ballon like this.
>
> 	A little more info about your app and what it does woudl help debug.
> Are you using Rmagcik? Are you useing send_file or send_data to
> stream out large content?
>
>
> Cheers-
> -Ezra
>
>
>
> On Jan 17, 2007, at 10:36 AM, Michael Biven wrote:
>
>> How are the mongrel started (cron, launchd, etc)? I had something
>> similar happen to me, but I think it was from the cluster being
>> started by root instead of the user I wanted to start it. It gave me
>> an extra set of mongrel processes running that mongrel_rails
>> cluster::stop wouldn''t stop.
>>
>> Michael B.
>>
>> On 1/17/07, Surendra Singhi <singhi.surendra at gmail.com> wrote:
>>> Hi,
>>>   I have mongrel 0.3.14, with ruby 1.8.5, rails 1.1.6 and mongrel
>>> cluster
>>> 0.2.1, on debian sage 3.1 with apache 2.0, and fastthread 0.6.1.
>>> I am load balancing 3 mongrel processes using the random port
trick.
>>>
>>>  When I start mongrel the processes have about 60MB, but after
>>> some hour of
>>> usage the memory ballons upto more than 180MB and the site becomes
>>> terribly
>>> slow. Forcing me to restart mongrel cluster.
>>>
>>> Also, it reports me 9 mongrel processes instead of three. I am not
>>> able to
>>> understand why that''s happening. Are really 9 mongrel
processes
>>> started
>>> instead of three?
>>>
>>> Please help. Thanks.
>>
>> -- 
>> Michael Biven
>> michael.biven at gmail.com
>> http://biven.org
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> -- Ezra Zygmuntowicz 
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

Hi~


On Jan 17, 2007, at 11:06 PM, Surendra Singhi wrote:
> Hi,
>
> First of all thanks everyone for their responses.
>
> On 1/18/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
>         Some linux distros have weird reporting of processes. I  
> have seen it
> where top or ps will report 3 mongrels for each one that is really
> running. And looking at your output you can see that each set of
> three mongrels reported have the same port number. This means that
> you really only have 3 mongrels running because only one can be
> running per port at a time.
>
> The output of ''ps aefux'' is below. Though I
don''t understand ps
> completely it seems that the one mongrel process spawns another  
> child process, which in turns spawns a third one.
>
Yes I have seen this before and it is nothing to worry about, even  
though it shows 9 mongrels you really only have 3 running.

>
>         As far as the memory usage goes, that sounds like a classic  
> memory
> leak in your rails app. I have seen mongrel balloon like that when
> people add an extra :include directive to a find that ends up loading
> a ton of extra records into memory. If you are loading more then a
> few hundred ActiveRecords into memory on any one page then that will
> surely cause memory to ballon like this.
>
> Yes, we are doing eager loading at many places, and there is a  
> sitemap part
> where about 10,000 records are loaded. I will try to optimize those  
> parts, and see
> if they make a difference.
This is one of your biggest problems right here. Its easy to return  
thousands of records from an AR query. But AR objects are expensive  
in terms of cpu and memory usage to construct. Working with 10,000  
records at once is a sure fire way to leak tons of memory and make  
your mongrels unstable.  Try to work with smaller sets of data.  I  
have yet to ever see a legitimate use case where you want to display  
10k records on one web page ;)

Use pagination or whatever you need to do to work with smaller sets  
of data. There is a paginating_find plugin that is useful and there  
is a gem called Paginator that I highly recommend over the stock  
rails paginator.
>
>         A little more info about your app and what it does woudl  
> help debug.
> Are you using Rmagcik?
>
> Yes we are using that. I will look into mini-magick. Joey thanks  
> for that.
>
Mini magick is very nice. But also look at ImageScience. If you are  
only using rmagick for thumbnailing, resizing and cropping then image  
science is much better. Its about 5 times faster and it doesn''t leak  
any memory. Highly recommended.

> Are you useing send_file or send_data to
> stream out large content?
>
> We are streaming data for images.
Is this a convenience or a requirement? This should be avoided if at  
all possible. The way rails works with mongrel is that mongrel will  
not send the finished request to the client until rails has  
completely finished. WHat I mean is when you use send_data or  
send_file with mongrel;, raiuls will try to stream the data in  
chunks. But mongrel will just buffer these chunks into a StringIO  
until rails is completely finished and then mongrel will send the  
entire thing to the client. This means that every time you stream  
data like this, the entire image has to be loaded into ram in mongrel  
before it will send it to the client.

>
> We are also using ferret and mediacloth.
I don''t think these two are the cause of any of your leaks.
>
> I guess, I need to investigate more on the above mentioned things.
> Thanks a lot.
>
> Surendra Singhi
>


	From what you have said the thing I worry about the most is loading  
10k AR objects into memory. That is not going to scale and will cause  
you no end of problems. Work with smaller sets. Switch to  
ImageScience if you can or at least to mini magick. If image Science  
will do everything you need to do then use it above all other options.

	Hope that helps.

Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

Is mongrel not releasing the memory used for these operations? I need
to use send_file to stream some static images (4k max) (approved,
declined, etc) which rails then turns into new cached images. This
allows a group of people to get the current status of an item via html
email with images. It''s a neat hack, but I''d like to make it
better.

>But mongrel will just buffer these chunks into a StringIO
>until rails is completely finished and then mongrel will send the
>entire thing to the client. This means that every time you stream
>data like this, the entire image has to be loaded into ram in mongrel
>before it will send it to the client.

On Jan 18, 2007, at 12:28 PM, Joey Geiger wrote:
> Is mongrel not releasing the memory used for these operations? I need
> to use send_file to stream some static images (4k max) (approved,
> declined, etc) which rails then turns into new cached images. This
> allows a group of people to get the current status of an item via html
> email with images. It''s a neat hack, but I''d like to make
it better.

	For small 4k images that you cache after the first time they are  
streamed then I would not worry about it. Those should be fine. And  
mongrel+ruby does its bet to release memory used in this way. It''s  
when you are constantly streaming data without caching it, that can  
cause slow memory buildups and the only way to reclaim the mem is to  
restart the mongrels. This is not entirely mongrels fault though.  
Ruby is pretty bad at releasing memory once it has it. Especially if  
you are swamping it so the GC can''t keep up.

	But 4k and cached I think should be fine. Are you experiencing leaks?



-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

Zed: Sorry not blaming you and your app. I guess that came across
wrong. Without mongrel right now, I''d be somewhat screwed from an ease
of use standpoint.

Right now, my hands are fairly tied with the use of x-sendfile and
headers since I''m actually double proxying my application (Apache 1.3
-> nginx(localhost:8000) -> mongrel_cluster(localhost:8001-4)). Nginx
serves any static images that rails creates back to apache. (Anyone
know how to get ProxyPass ! /images/ to work on 1.3? :)

I do believe that it is my app that''s having issues, but it''s
not to
the point where it''s threatening the stability of my system. I have
monit watching the mongrels, so they will restart when they use too
much memory.

The flowchart for part of it is something like this:
user submits a comment (comment id 5)
system notifies 5 editors via html email that there is a new comment
inside the email, there is an <img src="status_image/5" />
showing the status
editor1 views the email
the controller does a send_file("images/pending.png") and caches it as
(/status_image/5.png)
editor1 sees the status as pending and moves to another email
editor2 views the email, sees the status as pending and approves the comment
controller removes the cached image (/status_image/5.png)
editor3 now views the email
the controller does a send_file("images/approved.png") and caches it
as (/status_image/5.png)
editor3 now sees the comment has been approved and moves on
editor1 comes back to view the comment and now sees that it has been
approved and moves on

While I''m caching the images, the application has to do this a bunch
of times, and re-do it each time the status of the item is changed, so
each of the editors sees the freshest status. So it''s not a big hit
and restart every time, but I think over the course of a few days, it
builds up, and the process is restarted.

I''m learning this day by day as I go on, so I''m always open to
suggestions.

On 1/18/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
> On Jan 18, 2007, at 12:28 PM, Joey Geiger wrote:
>
> > Is mongrel not releasing the memory used for these operations? I need
> > to use send_file to stream some static images (4k max) (approved,
> > declined, etc) which rails then turns into new cached images. This
> > allows a group of people to get the current status of an item via html
> > email with images. It''s a neat hack, but I''d like to
make it better.
>
>
>         For small 4k images that you cache after the first time they are
> streamed then I would not worry about it. Those should be fine. And
> mongrel+ruby does its bet to release memory used in this way. It''s
> when you are constantly streaming data without caching it, that can
> cause slow memory buildups and the only way to reclaim the mem is to
> restart the mongrels. This is not entirely mongrels fault though.
> Ruby is pretty bad at releasing memory once it has it. Especially if
> you are swamping it so the GC can''t keep up.
>
>         But 4k and cached I think should be fine. Are you experiencing
leaks?
>
>
>
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

On Thu, 18 Jan 2007 14:28:50 -0600
"Joey Geiger" <jgeiger at gmail.com> wrote:
> Is mongrel not releasing the memory used for these operations? I need
> to use send_file to stream some static images (4k max) (approved,
> declined, etc) which rails then turns into new cached images. This
> allows a group of people to get the current status of an item via html
> email with images. It''s a neat hack, but I''d like to make
it better.
> 
> 
> >But mongrel will just buffer these chunks into a StringIO
> >until rails is completely finished and then mongrel will send the
> >entire thing to the client. This means that every time you stream
> >data like this, the entire image has to be loaded into ram in mongrel
> >before it will send it to the client.
No, first off, doing it this way is incredibly bad simply because
you''re holding up rails while you send the files.  No matter how big
the size this is a waste.  Look at using X-Sendfile headers to get the web
server to do this for you.

Second, "mongrel" seems to be said in place of "whatever ruby
stuff i''m currently running".  I think this comes from people who
are used to saying "Apache" when they mean "all my php
stuff" or "tomcat" when they mean "all my java stuff". 
In those environments the whole stack is also mostly the web server and the web
servers are gigantic usually in comparison to whatever you wrote.  In the case
of Mongrel, the "web server" is just a very tiny little piece of the
whole stack.  It''s literally like %1 of the total code in the system. 
To really start thinking clearly about what you''re using you have to
start thinking in terms of "mongrel+rails+[my included libs]" to find
your problems.  This is also true in the PHP and Java worlds, but it''s
not as important.

Third, Remember, *LOTS* of people run mongrel without memory leaks. 
I''d put out that there''s easily thousands of mongrels running
without leaks.  If *YOU* are seeing leaks *YOU* are doing something wrong. 
Sorry to be harsh, but first thing people jump at is Mongrel and then we find
out they''re doing 10-20 really dumb things they should check on first. 
Always assume that what you''ve got sucks, then after you''ve
ruled out all possible potential problems with what you''ve written then
start looking at the "m+r+[mil]" stack as potential causes.

Finally, if you''re doing the image generation and sending via a
consistent URL, it wouldn''t be hard to write a Mongrel handler that
dealt with this work without touching rails at all.  Take a look at
lib/mongrel/handlers.rb for tons of examples.

Hope that helps.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

I''m interested in trying ImageScience but I can''t get
FreeImage, the
processing lib, to build on MacOS X 10.4 (Intel). Has anyone had luck?

I tried building from source and using DarwinPorts, both no dice:

gonzo:~/Unix/Sources/imagescience_stuff/FreeImage hunter$ sudo port  
install freeimage
--->  Building freeimage with target all
Error: Target com.apple.build returned: shell command "cd "/opt/local/
var/db/dports/build/ 
_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp 
orts_graphics_freeimage/work/FreeImage" && make all" returned
error 2
Command output: Source/FreeImage/BitmapAccess.cpp:813: error:  
expected `;'' before ''TAGMAP''
Source/FreeImage/BitmapAccess.cpp:821: error: ''strcmp'' was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:825: error:
''FreeImage_GetTagCount''
was not declared in this scope
Source/FreeImage/BitmapAccess.cpp:825: error: ''WORD'' was not
declared
in this scope
Source/FreeImage/BitmapAccess.cpp:825: error:  
''FreeImage_TagDataWidth'' cannot be used as a function
Source/FreeImage/BitmapAccess.cpp:825: error:  
''FreeImage_GetTagLength'' was not declared in this scope
Source/FreeImage/BitmapAccess.cpp:839: error: ''WORD'' was not
declared
in this scope
Source/FreeImage/BitmapAccess.cpp:858: error: ''TAGMAP'' is not
a class
or namespace
Source/FreeImage/BitmapAccess.cpp:858: error: ''iterator'' was
not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:858: error: expected `;'' before
''i''
Source/FreeImage/BitmapAccess.cpp:859: error: ''i'' was not
declared in
this scope
Source/FreeImage/BitmapAccess.cpp:869: error: ''TAGMAP'' is not
a class
or namespace
Source/FreeImage/BitmapAccess.cpp:869: error: ''iterator'' was
not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:869: error: expected `;'' before
''i''
Source/FreeImage/BitmapAccess.cpp:869: error: ''i'' was not
declared in
this scope
Source/FreeImage/BitmapAccess.cpp:874: error: type ''<type
error>''
argument given to ''delete'', expected pointer
Source/FreeImage/BitmapAccess.cpp: In function ''BOOL  
FreeImage_GetMetadata(FREE_IMAGE_MDMODEL, FIBITMAP*, const char*,  
FITAG**)'':
Source/FreeImage/BitmapAccess.cpp:887: error: ''TAGMAP'' was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:887: error: ''tagmap'' was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:891: error: ''METADATAMAP''
was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:891: error: ''metadata'' was
not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:891: error: ''struct  
FREEIMAGEHEADER'' has no member named ''metadata''
Source/FreeImage/BitmapAccess.cpp: In function ''unsigned int  
FreeImage_GetMetadataCount(FREE_IMAGE_MDMODEL, FIBITMAP*)'':
Source/FreeImage/BitmapAccess.cpp:912: error: ''TAGMAP'' was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:912: error: ''tagmap'' was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:915: error: ''METADATAMAP''
was not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:915: error: ''metadata'' was
not
declared in this scope
Source/FreeImage/BitmapAccess.cpp:915: error: ''struct  
FREEIMAGEHEADER'' has no member named ''metadata''
make[1]: *** [Source/FreeImage/BitmapAccess.o-ppc] Error 1
make: *** [all] Error 2


On Jan 18, 2007, at 11:59 AM, Ezra Zygmuntowicz wrote:
> Mini magick is very nice. But also look at ImageScience. If you are
> only using rmagick for thumbnailing, resizing and cropping then image
> science is much better. Its about 5 times faster and it doesn''t
leak
> any memory. Highly recommended.

On Thu, 18 Jan 2007 16:14:43 -0600
"Joey Geiger" <jgeiger at gmail.com> wrote:
> Zed: Sorry not blaming you and your app. I guess that came across
> wrong. Without mongrel right now, I''d be somewhat screwed from an
ease
> of use standpoint.
Oh hey man, it''s quite all right to blame mongrel.  Just shooting you
some device that works for me when debugging a problem.  It just works better
when you blame what you got first, then start fanning out.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

Hunter,

I would just install it without using ports, you can check out the
image_science page for info on how to compile with specific Mac OSX tips.


On 1/18/07, Hunter Hillegas <lists at lastonepicked.com>
wrote:
>
> I''m interested in trying ImageScience but I can''t get
FreeImage, the
> processing lib, to build on MacOS X 10.4 (Intel). Has anyone had luck?
>
> I tried building from source and using DarwinPorts, both no dice:
>
> gonzo:~/Unix/Sources/imagescience_stuff/FreeImage hunter$ sudo port
> install freeimage
> --->  Building freeimage with target all
> Error: Target com.apple.build returned: shell command "cd
"/opt/local/
> var/db/dports/build/
> _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp
> orts_graphics_freeimage/work/FreeImage" && make all"
returned error 2
> Command output: Source/FreeImage/BitmapAccess.cpp:813: error:
> expected `;'' before ''TAGMAP''
> Source/FreeImage/BitmapAccess.cpp:821: error: ''strcmp''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:825: error:
''FreeImage_GetTagCount''
> was not declared in this scope
> Source/FreeImage/BitmapAccess.cpp:825: error: ''WORD'' was
not declared
> in this scope
> Source/FreeImage/BitmapAccess.cpp:825: error:
> ''FreeImage_TagDataWidth'' cannot be used as a function
> Source/FreeImage/BitmapAccess.cpp:825: error:
> ''FreeImage_GetTagLength'' was not declared in this scope
> Source/FreeImage/BitmapAccess.cpp:839: error: ''WORD'' was
not declared
> in this scope
> Source/FreeImage/BitmapAccess.cpp:858: error: ''TAGMAP'' is
not a class
> or namespace
> Source/FreeImage/BitmapAccess.cpp:858: error: ''iterator''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:858: error: expected `;'' before
''i''
> Source/FreeImage/BitmapAccess.cpp:859: error: ''i'' was not
declared in
> this scope
> Source/FreeImage/BitmapAccess.cpp:869: error: ''TAGMAP'' is
not a class
> or namespace
> Source/FreeImage/BitmapAccess.cpp:869: error: ''iterator''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:869: error: expected `;'' before
''i''
> Source/FreeImage/BitmapAccess.cpp:869: error: ''i'' was not
declared in
> this scope
> Source/FreeImage/BitmapAccess.cpp:874: error: type ''<type
error>''
> argument given to ''delete'', expected pointer
> Source/FreeImage/BitmapAccess.cpp: In function ''BOOL
> FreeImage_GetMetadata(FREE_IMAGE_MDMODEL, FIBITMAP*, const char*,
> FITAG**)'':
> Source/FreeImage/BitmapAccess.cpp:887: error: ''TAGMAP''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:887: error: ''tagmap''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:891: error:
''METADATAMAP'' was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:891: error: ''metadata''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:891: error: ''struct
> FREEIMAGEHEADER'' has no member named ''metadata''
> Source/FreeImage/BitmapAccess.cpp: In function ''unsigned int
> FreeImage_GetMetadataCount(FREE_IMAGE_MDMODEL, FIBITMAP*)'':
> Source/FreeImage/BitmapAccess.cpp:912: error: ''TAGMAP''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:912: error: ''tagmap''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:915: error:
''METADATAMAP'' was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:915: error: ''metadata''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:915: error: ''struct
> FREEIMAGEHEADER'' has no member named ''metadata''
> make[1]: *** [Source/FreeImage/BitmapAccess.o-ppc] Error 1
> make: *** [all] Error 2
>
>
> On Jan 18, 2007, at 11:59 AM, Ezra Zygmuntowicz wrote:
>
> > Mini magick is very nice. But also look at ImageScience. If you are
> > only using rmagick for thumbnailing, resizing and cropping then image
> > science is much better. Its about 5 times faster and it
doesn''t leak
> > any memory. Highly recommended.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20070119/f83a700a/attachment.html

Hi all,

Ezra Zygmuntowicz wrote:
> Mini magick is very nice. But also look at ImageScience. If you are  
> only using rmagick for thumbnailing, resizing and cropping then image  
> science is much better. Its about 5 times faster and it doesn''t
leak
> any memory. Highly recommended.
I''ve created a Debian package for ImageScience. It is not well tested 
but works for me. If anyone is interested, I can upload it somewhere.

Philippe J.

Yeah, I tried building it myself but got a similar compile error. I''m  
on Intel but I assume that it works with both arches.

I''ll go back and check it again... The OS X instructions
weren''t
working for me.

On Jan 19, 2007, at 7:33 AM, Michael D''Auria wrote:
> Hunter,
>
> I would just install it without using ports, you can check out the  
> image_science page for info on how to compile with specific Mac OSX  
> tips.
>
>
> On 1/18/07, Hunter Hillegas <lists at lastonepicked.com> wrote:
I''m
> interested in trying ImageScience but I can''t get FreeImage, the
> processing lib, to build on MacOS X 10.4 (Intel). Has anyone had luck?
>
> I tried building from source and using DarwinPorts, both no dice:
>
> gonzo:~/Unix/Sources/imagescience_stuff/FreeImage hunter$ sudo port
> install freeimage
> --->  Building freeimage with target all
> Error: Target com.apple.build returned: shell command "cd
"/opt/local/
> var/db/dports/build/
> _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_ 
> dp
> orts_graphics_freeimage/work/FreeImage" && make all"
returned error 2
> Command output: Source/FreeImage/BitmapAccess.cpp:813: error:
> expected `;'' before ''TAGMAP''
> Source/FreeImage/BitmapAccess.cpp:821: error: ''strcmp''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:825: error:
''FreeImage_GetTagCount''
> was not declared in this scope
> Source/FreeImage/BitmapAccess.cpp:825: error: ''WORD'' was
not declared
> in this scope
> Source/FreeImage/BitmapAccess.cpp:825: error:
> ''FreeImage_TagDataWidth'' cannot be used as a function
> Source/FreeImage/BitmapAccess.cpp:825: error:
> ''FreeImage_GetTagLength'' was not declared in this scope
> Source/FreeImage/BitmapAccess.cpp:839: error: ''WORD'' was
not declared
> in this scope
> Source/FreeImage/BitmapAccess.cpp:858: error: ''TAGMAP'' is
not a class
> or namespace
> Source/FreeImage/BitmapAccess.cpp:858: error: ''iterator''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:858: error: expected `;'' before
''i''
> Source/FreeImage/BitmapAccess.cpp:859: error: ''i'' was not
declared in
> this scope
> Source/FreeImage/BitmapAccess.cpp:869: error: ''TAGMAP'' is
not a class
> or namespace
> Source/FreeImage/BitmapAccess.cpp:869: error: ''iterator''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:869: error: expected `;'' before
''i''
> Source/FreeImage/BitmapAccess.cpp:869: error: ''i'' was not
declared in
> this scope
> Source/FreeImage/BitmapAccess.cpp:874: error: type ''<type
error>''
> argument given to ''delete'', expected pointer
> Source/FreeImage/BitmapAccess.cpp: In function ''BOOL
> FreeImage_GetMetadata(FREE_IMAGE_MDMODEL, FIBITMAP*, const char*,
> FITAG**)'':
> Source/FreeImage/BitmapAccess.cpp:887: error: ''TAGMAP''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:887: error: ''tagmap''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:891: error:
''METADATAMAP'' was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:891: error: ''metadata''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:891: error: ''struct
> FREEIMAGEHEADER'' has no member named ''metadata''
> Source/FreeImage/BitmapAccess.cpp: In function ''unsigned int
> FreeImage_GetMetadataCount(FREE_IMAGE_MDMODEL, FIBITMAP*)'':
> Source/FreeImage/BitmapAccess.cpp:912: error: ''TAGMAP''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:912: error: ''tagmap''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:915: error:
''METADATAMAP'' was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:915: error: ''metadata''
was not
> declared in this scope
> Source/FreeImage/BitmapAccess.cpp:915: error: ''struct
> FREEIMAGEHEADER'' has no member named ''metadata''
> make[1]: *** [Source/FreeImage/BitmapAccess.o-ppc] Error 1
> make: *** [all] Error 2
>
>
> On Jan 18, 2007, at 11:59 AM, Ezra Zygmuntowicz wrote:
>
> > Mini magick is very nice. But also look at ImageScience. If you are
> > only using rmagick for thumbnailing, resizing and cropping then  
> image
> > science is much better. Its about 5 times faster and it
doesn''t leak
> > any memory. Highly recommended.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

This is the fixed version ...

Philippe Jayet wrote:
> I''ve created a Debian package for ImageScience. It is not well
tested
> but works for me. If anyone is interested, I can upload it somewhere.
The package is for FreeImage, the ImageScience dependency !

Philippe J.

Philippe Jayet dijo [Fri, Jan 19, 2007 at 05:04:58PM
+0100]:
> Ezra Zygmuntowicz wrote:
> > Mini magick is very nice. But also look at ImageScience. If you are  
> > only using rmagick for thumbnailing, resizing and cropping then image
> > science is much better. Its about 5 times faster and it
doesn''t leak
> > any memory. Highly recommended.
> 
> I''ve created a Debian package for ImageScience. It is not well
tested
> but works for me. If anyone is interested, I can upload it somewhere.
Hi,

Philippe sent this message at the Mongrel list - Debian Ruby guys, any
takers interested in it?

Greetings,

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20070119/d7f0af16/attachment.bin