From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87865 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.gnus.general Subject: Re: strange memory usage for nntp groups Date: Thu, 28 Dec 2017 20:03:46 +0100 Message-ID: <868tdmllnx.fsf@zoho.com> References: <878tdnhocx.fsf@ucl.ac.uk> <86k1x7n49g.fsf@zoho.com> <871sjfraio.fsf@ucl.ac.uk> <86fu7vmu33.fsf@zoho.com> <87lghmsoa7.fsf@ucl.ac.uk> <87k1x6hejg.fsf@ucl.ac.uk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1514487752 15155 195.159.176.226 (28 Dec 2017 19:02:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 28 Dec 2017 19:02:32 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m36079@lists.math.uh.edu Thu Dec 28 20:02:28 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048034.atla03.us.yomura.com ([107.189.48.34]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUdRk-00032r-12 for ding-account@gmane.org; Thu, 28 Dec 2017 20:02:28 +0100 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048034.atla03.us.yomura.com (Halon) with ESMTPS id eae77b26-ec01-11e7-83d2-b499baa2b07a; Thu, 28 Dec 2017 19:04:24 +0000 (UTC) Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.89) (envelope-from ) id 1eUdTR-0004WC-5E; Thu, 28 Dec 2017 13:04:13 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eUdTO-0004VM-6P for ding@lists.math.uh.edu; Thu, 28 Dec 2017 13:04:10 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eUdTM-0002E7-Of for ding@lists.math.uh.edu; Thu, 28 Dec 2017 13:04:10 -0600 Original-Received: from [195.159.176.226] (helo=blaine.gmane.org) by quimby.gnus.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eUdTL-0002YP-El for ding@gnus.org; Thu, 28 Dec 2017 20:04:07 +0100 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eUdRF-0001RR-4j for ding@gnus.org; Thu, 28 Dec 2017 20:01:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 17 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:eZh5G9Pm0Q9U6aZhoi/IyWfGjok= X-Spam-Score: 2.1 (++) X-Spam-Report: SpamAssassin (3.4.1 2015-04-28) analysis follows Bayesian score: 0.4932 Ham tokens: 0.000-151--5429h-0s--0d--H*M:fsf, 0.000-3--94h-0s--0d--HX-Complaints-To:sk:usenet@, 0.000-3--90h-0s--0d--Hx-spam-relays-external:sk:blaine., 0.000-3--90h-0s--0d--H*RU:195.159.176.226, 0.000-3--90h-0s--0d--Hx-spam-relays-external:195.159.176.226 Spam tokens: 0.996-27774--569h-23667s--0d--H*r:quimby.gnus.org, 0.996-15530--320h-13235s--0d--H*RT:sk:junkmas, 0.996-15530--320h-13235s--0d--Hx-spam-relays-internal:sk:junkmas, 0.996-15530--320h-13235s--0d--HX-Envelope-From:sk:junkmas, 0.994-28682--949h-24743s--0d--HTo:D*gnus.org Autolearn status: no autolearn_force=no 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (moasen[at]zoho.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4932] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87865 Archived-At: Eric S Fraga wrote: > Can anybody suggest how I can read large > newsgroups on systems with small memory? > I would have thought that gnus should be able > to do this. Does it need to keep the whole > set of headers in memory? I'm happy to pay > the price of network access in lieu of memory > overload... Small system or big, having huge files is almost never a good idea. Perhaps the file can be split up over time, or when the get too big? -- underground experts united http://user.it.uu.se/~embe8573