On Mon, Oct 24, 2011 at 02:59:18PM +0200, Lucas Nussbaum wrote:
> Anyway, I agree that UDD cannot be fast by design. We just need to make
> it sufficiently fast to be useful. One way to move forward could be to
> have two instances of UDD:
> - one hosted on samosa, that only does the importing and the execution
> of "official" services that run reasonable queries for which UDD has
> been optimized (by adding indexes, etc).
> - one on another machine (alioth?), that would be available to everyone
> to hack on UDD-based tools. That one could have a strict query
> duration limit.
Depending on this limit it would make sense for the purpose of
blends.alioth.debian.org which would end up in accessing a local
database and should speed up things even more.
> Also, wouldn't it be possible to just add more RAM to samosa ? It only
> has 6 GB, and RAM isn't that expensive nowadays. With <$1000, we could
> probably get a significant performance increase.
See private mail.
> Note that the recent load problems were apparently caused by a lack of
> VACUUMing in the DB. I'm not sure why auto-vacuum doesn't work as
> expected, but I'm going to cron a VACUUM FULL once per month.
> This doesn't solve the root issue, though.
>
> (Andreas, could you confirm that the situation improved for you too?)
Yes, drastically:
$ time ./tasks.py debian-med
real 6m12.815s
user 1m22.989s
sys 0m0.964s
These are the "old" numbers, before samosa went slowly! This is not the
longest running Blend but it is a very good sign that for all Blends the
job will run less than one hour again. If we could keep this status it
would be sufficient for my purposes. In the "slow times" the time above
was about 300min which is definitely inacceptable.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111024141313.gb12...@an3as.eu
