From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/81924 Path: news.gmane.org!not-for-mail From: Wolfgang Jenkner Newsgroups: gmane.emacs.gnus.general Subject: Re: Excessive nntp reads since today Date: Tue, 12 Jun 2012 16:35:38 +0200 Message-ID: <85pq94k37p.fsf@iznogoud.viz> References: <877gvcd91f.fsf@thinkpad.tsdh.de> <85txygk74a.fsf@iznogoud.viz> <87y5nsbqj4.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1339511805 21860 80.91.229.3 (12 Jun 2012 14:36:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Jun 2012 14:36:45 +0000 (UTC) Cc: ding@gnus.org To: Tassilo Horn Original-X-From: ding-owner+M30194@lists.math.uh.edu Tue Jun 12 16:36:44 2012 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SeSD2-0007RF-Fz for ding-account@gmane.org; Tue, 12 Jun 2012 16:36:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1SeSCN-00021S-9d; Tue, 12 Jun 2012 09:35:59 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SeSCM-00021I-77 for ding@lists.math.uh.edu; Tue, 12 Jun 2012 09:35:58 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SeSCC-0002jA-4N for ding@lists.math.uh.edu; Tue, 12 Jun 2012 09:35:57 -0500 Original-Received: from mx08.lb01.inode.at ([62.99.145.8] helo=mx.inode.at) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1SeSCA-0002md-Cz for ding@gnus.org; Tue, 12 Jun 2012 16:35:46 +0200 Original-Received: from [91.119.76.58] (port=11410 helo=iznogoud.viz) by smartmx-08.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SeSC4-0008S7-QS; Tue, 12 Jun 2012 16:35:41 +0200 Original-Received: from wolfgang by iznogoud.viz with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SeSC2-0000dT-T4; Tue, 12 Jun 2012 16:35:38 +0200 Mail-Followup-To: Tassilo Horn , ding@gnus.org In-Reply-To: <87y5nsbqj4.fsf@thinkpad.tsdh.de> (Tassilo Horn's message of "Tue, 12 Jun 2012 15:36:47 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (berkeley-unix) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:81924 Archived-At: On Tue, Jun 12 2012, Tassilo Horn wrote: > Wolfgang Jenkner writes: > >>> My `gnus-fetch-old-headers' is 'some, so it might want to fetch some >>> older messages to connect new articles in a thread, but not so many. >>> I just entered the gmane xetex group which had 4 new articles. The >>> summary showed those 4 articles + 2 old articles from yesterday (the >>> 4 new were replies of the 2 old ones). But when entering the group, >>> the "nntp read: kb" message counted to more than 12.000. >>> >>> I suspect this change is the culprit, so I added Wolfgang to the Cc. >>> >>> ,---- >>> | commit 44f603535c63aab124e139b145fce20fff488f38 >>> | Author: Wolfgang Jenkner >>> | Date: Mon Jun 11 23:49:17 2012 +0200 >>> | >>> | Make `A T' work when agentized >>> | >>> | * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of >>> | articles when fetch-old is non-nil (bug#11370). >>> `---- >> >> I admit that it hadn't occurred to me to test this patch with >> non-default values of gnus-fetch-old-headers, but the docstring of this >> variable actually seems to match the behaviour you describe... > > It matches the behavior in that it had to fetch 2 additional messages to > fill in gaps in lose thread branches. The docstring states that it fetches all old headers (though only some subset of them is displayed). > But the two old messages were from yesterday, and that's a low-traffic > group with about 20 messages in the last week. There's no chance that > this required fetching 12 MB of header data, right? Perhaps tracing (or stepping through) gnus-agent-retrieve-headers could give a clue? Wolfgang