Re: pan stops working/responding

On 9/7/23 2:26 AM, Duncan wrote:
> dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Thu, 7 Sep 2023 00:20:07 -0700
> as excerpted:
>
>> If I select a high-activity group I haven't read before (such as
>> gmane.linux.kernel which I guess is the mailing list and has hundreds
>> thousands posts) pan soon stops working/responding.  I can no longer
>> select any other group, nor any menu item, and if I cover or minimize
>> pan and return later, it no longer even redraws its screen.  Today this
>> has gone one for about six hours, which just to show one screen of
>> posts, it shouldn't take this long!  I don't know why it'd have to
>> prepare to show all posts from years ago because I probably won't look
>> that far back.  Pan even stops responding like this if I mark that I've
>> read all articles in the high-activity group and come back later,
>> perhaps just to see the top page of articles.
> Please verify the following preference is UNCHECKED:
>
> Preferences > Behavior > Groups > Get new headers when entering group
>
> (I keep Get new headers in subscribed groups on startup unchecked as well,
> for similar reasons, but if you're careful not to subscribe to groups that
> are too high volume that should be less of an issue, because unlike when
> you first enter a group, presumably pan has a memory of where you were in
> all your subscribed groups.)
I set both those preferences and tried to read gmane.linux.kernel 
again... same happened.  This time I waited several hours, came back 
several times, waited overnight and checked a few more times, and 
finally waited 30 hours before I reboot so pan got killed.  I think pan 
getting killed in the past messed up how it saved some files and was 
causing the crashing I was having for years.

> Then, when grabbing your first headers, us the get headers ... dialog
> instead of getting new/all headers, and get the last N-days-worth or N-
> hundred headers, thus restricting that initial header download.
>
> After that, I'd suggest quick-changing groups out and back in, thus
> ensuring that pan stores where it was in the group (I got in this habit
> long ago, when pan wasn't as good about saving its current position and
> would lose track of read messages since the last time you switched groups
> if it crashed).
>
> Then it should know where it was and getting "new" headers should only get
> new ones from there, so should be fine -- you won't have to restrict
> yourself to getting only N days or N count headers again unless you don't
> update for too long and it has too many new headers again.
>
> The problem is that when you haven't visited the group before (or if pan
> crashed or froze and had to be killed while in the group before it finished
> loading headers), *ALL* messages are new.  Couple that with the fact that
> pan builds its threading model in memory (as opposed to a generally slower
> but much more memory-conservative model where it only has a few pages worth
> of header data in RAM at once and stores the rest in a file-based database
> of some sort, swapping back and forth between them as necessary to keep a
> low-memory working-set in RAM), AND gmane's archive-purposed lack of
> expiry, and high-volume groups/mailing-lists like the main linux kernel
> list are just too much.
>
> (The same of course applies to the higher volume binary groups, even with a
> reasonable expiry there, but that's due to the many-individual-message-
> segments-per-message and combined-header issue (in pan, where many such
> segments appear as a single combined header in its listing), which is a bit
> different than the actually text-based-message linux kernel list, where
> it's purely a problem of the raw number of single-segment text messages...
> when they're archived over N years as on gmane.)
>
> This used to be a far worse problem back in the 32-bit era where max app
> memory was 4 gig at best (more likely 2 gig, and that's assuming you
> actually had multiple gigs of physical RAM!!).  Where now it's millions of
> headers triggering a problem, back then it was a couple hundred thousand...
> or even a few tens of thousands on less memory-endowed systems!
>
> But of course that was before disk space was cheap enough that long
> retention (more than a few days or weeks) was common, too, so most servers
> didn't /have/ more than a a couple hundred thousand headers on even their
> busiest groups.


_______________________________________________
Pan-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/pan-users