On Sunday 27 August 2006 03:30, Duncan wrote: > Csv4Me2 <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Sun, 27 Aug 2006 > > 02:10:53 +0200: > > As long as the current versions don't load the startrek group succesfully > > i won't change versions. All new versions fail that simple test. The max > > size of a succesfull group download seem to depend solely on the > > available amount of system RAM. As soon as pan (0.1xx) causes the system > > to swap it slows down horrendously and never (?) finishes. This is IMHO > > not a bug but a design/implementation limitation. > > Adding to, removing from and sorting databases that are way larger than > > the amount of core memory is a challenge! But it can be done and has been > > done. See the sort program. Perhaps a v1.x issue ? > > I wonder if you are running into the 0.109 bug I just ran into (see the > tasklist optimization thread for the gory details). It's not a memory > issue (I've 8 gig memory here, and seldom fill it all up with cache let > alone start flushing to swap) but a CPU bottleneck. Darren says it has been > bugged and patched for 0.110. I hope so. I'm about ready to go to sleep > now, but if 0.110 isn't out tomorrow, I'll likely go try to find the bug > and apply the patch and rebuild 0.109, as pan's behavior trying to queue > tens of thousands of small posts at a time with 0.109 is beyond > ridiculous, at least here.
No, I'm not. When loading the complete startrek group pan claims about 1.8 G of memory (oscillating a bit and eventually claiming the full 2G of swap space) on my 1.5 G RAM box. The swap drive is exerting itself nicely averaging at 10 MB/sec or so. Definitely a memory starvation issue AND a working set problem. The last CVS version of pan loads this group just fine, takes ages though because old pan uses a single connection for the header download. C _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
