On Tue, Jul 21, 2009 at 11:56 PM, Julian
Edwards<email address hidden> wrote:
> Herb ran a test on staging and with the cache set to 500:
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> 1000 26950 13.9 11.2 1196480 905636 pts/3 Rl+ 16:40 10:12 /usr/bin/python2.4 cronscripts/update-pkgcache.py
>
> So it's a large improvement.
I find that surprising, but it is good news. Are you dealing with any
objects with large text fields or similar?
We should reduce the cache size in the [database] section in
lib/canonical/config/schema-lazr.conf. The appservers already override
this value in the [launchpad] section, so will continue to use the
value we have been testing on edge for the last few weeks. Everything
else will get the reduced cache value, which is good because they have
had less testing and I think it is better to tweak values up for slow
scripts as necessary rather than risk having systems go down because
of high memory use.
On Tue, Jul 21, 2009 at 11:56 PM, Julian update- pkgcache. py
Edwards<email address hidden> wrote:
> Herb ran a test on staging and with the cache set to 500:
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> 1000 26950 13.9 11.2 1196480 905636 pts/3 Rl+ 16:40 10:12 /usr/bin/python2.4 cronscripts/
>
> So it's a large improvement.
I find that surprising, but it is good news. Are you dealing with any
objects with large text fields or similar?
We should reduce the cache size in the [database] section in config/ schema- lazr.conf. The appservers already override
lib/canonical/
this value in the [launchpad] section, so will continue to use the
value we have been testing on edge for the last few weeks. Everything
else will get the reduced cache value, which is good because they have
had less testing and I think it is better to tweak values up for slow
scripts as necessary rather than risk having systems go down because
of high memory use.
-- www.stuartbisho p.net/
Stuart Bishop <email address hidden>
http://