Ervin Peters posted on Mon, 27 Aug 2018 10:51:39 +0200 as excerpted: > ...but after open, save and close the profile (without any changes) > everything works fine. > > > PAN 0.142 He slipped to Sam a double gin (01b5bf4 git.gnome.org/pan2; > x86_64-pc-linux-gnu) > > on gentoo linux ... > > > Also sometimes the read state isn't saved when hitting the window close > icon while pan switches from a huge group to anoterh huge group.
Gentoo here too. 0.142 is pretty old. 0.145 is available as ~arch. You might try it and see if the problems persist, tho I don't remember having them back on 0.142 either, so it could be something else, perhaps an older library if you're on stable for everything. (I'm on ~amd64 in general, but actually running a live-git pan using a pan-9999 ebuild I've occasionally updated since years ago, and check for git updates weekly or so. The -9999 ebuild used to be available in-tree but isn't any more.) The read state... is normally saved when switching groups, and these days, every few minutes within the same group as well. I don't know if the autosave was in 0.142 yet, but it should be in 0.145, and the number of minutes between saves is set in the preferences dialog, miscellaneous tab, minutes to autosave newsrc file option. You might try lowering that a bit, so at least if it doesn't get updated on group change you only lose say two minutes worth of read-message tracking rather than 5 (what I have set here and I think possibly the default, as I don't remember changing the option, certainly not recently), or since you last changed groups if your pan is too old to have the autosave. Meanwhile, ssd or spinning rust, and how much RAM (and swap if applicable) do you have? What's free's output when you're running pan in one of those large groups? (And if you have it handy from htop or ps or whatever, what's pan's memory usage, rss/resident-set-size, etc. FWIW, htop says 143M resident, 590M virtual, here, but that's after a resent pan restart, and as I said, I don't tend to do groups with millions of headers any more.) I'm now all ssd, and I don't really do binaries much any more and don't really frequent groups with millions of articles, but I do have my cache set to several gigs (pan's cache default size is 10 MiB) and have expiry set to unexpiring, with articles from some groups going back to 2002, when I started with pan. Since pan (re)threads messages each session and keeps that information in memory, it can take quite a bit of RAM for large groups, and back when I was on spinning rust, I remember it taking some time (minutes) to start pan as it loaded in my several gigs of posts from cache to rethread them. If you're doing groups with 10s of millions of headers, pan will be using quite a bit of memory and if you have swap and 16 gigs (what I have, plus swap that's generally only used when I build chromium as that appears to use up to ~24 gig) or less of RAM, it might be hitting swap, which might help explain both issues, the lost server due to a timeout trying to read in its config due to swap thrashing at the same time, and the lost read- message tracking due to that data being swapped out when you close pan, with not enough time to swap it back in and save before the resources cleanup begins. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
