On Fri, Nov 27, 2009 at 06:41:04PM -0800, Ross Boylan wrote:
> > With both these patches (8c7a9ed and c99bd95) applied, I'm now seeing
> > ???apt-cacher??? processes maintain a negligible CPU usage, even when APT
> > is fetching from them.
> >
> > This is highly imprecise (I'm just watching ???htop???) and I haven't put
> > any significant stress onto it, but is a good sign. I would encourage
> > anyone else experiencing the behaviour reported in this bug report to
> > try these patches and report the results.
> >
> The changes have no apparent effect for me. aptitude update goes
> basically to 100% CPU; while downloading debs, CPU use was also high,
> though possibly a bit lower than in the past (the download was too quick
> to be sure).
Disappointing.
Could you
- Download something bigger so you can be sure which process is
hogging.
- Is it still the [libcurl] process?
- Are you running aptitude on the same server as apt-cacher. What is
the aptitude CPU usage? It might be worth using wget to download a
single file through the cache and check it is still hogging.
- What does the load average go up to whilst you have 100% CPU?
- Tell me the versions of the underlying libraries: libc6, libcurl3
- Can you comment out/disable the 4 lines:
# Check for pending new request
if ($active_handles && $select->can_read(0)) {
debug_message('Pending connection');
next LIBCURL_REQUEST;
}
Does that make any difference?
- After you have disabled the $select->can_read(0) block, if libcurl CPU usage
is still high, can you strace the process and see what it is doing.
If all that seems OK, my only other suggestion is that we try to reduce
the priority of the libcurl process. Is it impinging on the rest of the
system? Something like the following should do it:
diff --git a/apt-cacher2 b/apt-cacher2
index ed53849..3399608 100755
--- a/apt-cacher2
+++ b/apt-cacher2
@@ -1153,6 +1153,8 @@ sub connect_curlm {
my $active_handles = 0;
my $idcounter=1;
+ setpriority(0,$$,10);
+
while ($select->can_read($cfg->{curl_idle_timeout})) {
LIBCURL_REQUEST:
{
If you play with the last number in setpriority() and see if anything
helps. 0 is the default so should do nothing. 19 should be least
hogging.
Mark
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
