On 29 Sep, Poul-Henning Kamp wrote: > In message <200509290731.j8T7V2OR007019_at_gw.catspoiler.org>, Don Lewis writes: > >>(kgdb) print runningbufspace >>$3 = 1585152 >>(kgdb) print lorunningspace >>$4 = 524288 >>print hirunningspace >>$5 = 1048576 >> >>so runningbufspace >> hirunningspace >> >>The bufdaemon and the syncer both ignore the runningbufspace limit. >>Maybe they should obey the limit, but each be guaranteed a minimum >>quota. > > I'm not quite sure what a/the sensible solution is, but the > lemming-syncer certainly is my prime suspect. It's probably not helping things. On the other hand, 1.5 MB of in-flight I/O doesn't sound like a lot now that disks commonly have 8MB caches and there may be multiple drives in the system. Hmn, vmstat -s says 0 pages, free, which probably going to cause problems ... 201909 pages active 24736 pages inactive 0 pages in VM cache 28573 pages wired down 0 pages free Looks like something is gobbling the last of the free memory faster than we can react. I'm running the test again and according to top the free memory seems to stabilize at a minimum of 1656K. Maybe we need to get more aggressive about not handing out memory pages when the pagedaemon runs out of pbufs. There may also just be too much transient kmem demand when snapshots are created or removed.Received on Thu Sep 29 2005 - 07:03:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC