Re: hardening window against NewsBruiser



On Thu, 2005-12-08 at 00:00 -0800, Kurt von Finck wrote:

> Both changes affect only blogs.g.o and are implemented through its
> Apache vhost entry. My solution was a CPU and child process throttle,
> which is:
> 
> RLimitCPU 60 60
> RLimitNPROC 10 10
> 
> This limits any single process to 60 seconds of CPU time, and limits to
> 10 the number of processes that can be launched by processes launched by
> Apache children.

When I checked this morning, we had about 80 Newsbruiser proceses
running, even with those above lines ... so I'm pretty puzzled. 

> Owen implemented a mod-cache fix, which is:
> 
> CacheEnable mem /
> 
> Hopefully Owen's fix will do 90% of the heavy lifting, while mine will
> be there to mop up overflow.

This *also wasn't working* ... spent a few basically unsuccessful hours
on it:

 - Tweaked mem cache parameters around, increased the sizes, and so
   forth. No apparent caching going on.

 - Switched to the disk cache; found that Newsbruiser wasn't writing
   out a Content-Length header and that was keeping mod_disk_cache
   from working.

   Patched Newsbruiser to write Content-Length, stuff started getting
   cached and served from the cache yay?! no ... it was getting 
   served with the wrong content-type, making blogs.gnome.org not
   work well.

   From a quick web search this looks like it is Apache PR 30278
   fixed in 2.0.53 (we're using 2.0.46)

 - Switched back to the mem cache hoping that the Content-Length
   fix would help. No luck. Upped sizes some more. No luck.

 - Added a bunch of:

Alias /attachment/alexl/2005/12/07/0/search0.png /var/www/blogs.gnome.org/NewsBruiserData/alexl/attachments/2005/12/07-0/search0.png

   Lines to the blogs.gnome.org conf file. Success ... more or less;
   when Apache served the files rather than Newsbruiser, the mem cache
   worked (though there isn't much point), load dropped back to
   something sane, and the machine no longer is in danger of falling
   over.

I've left the mem cache on for the moment, though to repeat, there isn't
much point ... stuff served statically doesn't need to be cached;
stuff served dynamically isn't being cached.

If someone wants to investigate further, what I'd suggest is:

 - Do it on a different machine, not on gnome.org (though if it is
   old-Apache buginess, that could be a problem for reproduction.)

 - Write a simple Python cgi that a) logs when it is called b)
   returns a small amount of data with content type and content
   length.

 - Try to get it's results cached via the memory cache.

Another thing that could be done is to track down the details of
PR 30278 and see if it could be worked around. All I've seen is
the summary "mod_disk_cache.c: Correctly store cached content type."

Regards,
						Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]