ron@mlfarm.uucp (Ronald Florence) (05/30/90)
We use pathalias (9.1 87/10/04) with Xenix 2.3.2, on a ps2/80 with six
megabytes of ram. Building our map normally takes ~2 minutes.
The recent batch of maps apparently has taken our pathalias over some
threshold. Without the map u.usa.ca.1, the build takes the same ~2
minutes. With all of the maps included on the command line, pathalias
churns and swaps, slowly growing in size. An hour later, when I
finally killed the process, it was at 5704K (according to ps); the
machine was swapping furiously (the vmstat display made you want to
cry); and the last message from the "-v" option in pathalias was
still "***mapping".
I assume we need more memory. Why does the memory need grow so
ferociously with what seems an incremental addition of nodes and
links? Is there a fix short of another two megabytes of ram?
Thanks in advance for any advice or suggestions.
--
Ronald Florence {yale,uunet}!hsi!mlfarm!roncampbell@Thalatta.COM (Bill Campbell) (05/31/90)
In article <RON.90May30172314@mlfarm.uucp> ron@mlfarm.uucp (Ronald Florence) writes:
:>We use pathalias (9.1 87/10/04) with Xenix 2.3.2, on a ps2/80 with six
:>megabytes of ram. Building our map normally takes ~2 minutes.
:>
:>The recent batch of maps apparently has taken our pathalias over some
:>threshold. Without the map u.usa.ca.1, the build takes the same ~2
:>minutes. With all of the maps included on the command line, pathalias
:>churns and swaps, slowly growing in size. An hour later, when I
:>finally killed the process, it was at 5704K (according to ps); the
:>machine was swapping furiously (the vmstat display made you want to
:>cry); and the last message from the "-v" option in pathalias was
:>still "***mapping".
:>
:>I assume we need more memory. Why does the memory need grow so
:>ferociously with what seems an incremental addition of nodes and
:>links? Is there a fix short of another two megabytes of ram?
:>
:>Thanks in advance for any advice or suggestions.
:>--
There has been considerable discussion on comp.mail.uucp about
this problem. It seems there is a bug in one of the map entries
in the ca.1 map and a new mexico map that causes older pathalias
to loop.
There is supposed to be a new version of pathalias available that
doesn't blow up on this.
Try looking at the discussions in comp.mail.misc and
comp.mail.uucp.
--
....microsoft--\ Bill Campbell; Celestial Software
...uw-entropy----!thebes!camco!bill 6641 East Mercer Way
....fluke------/ Mercer Island, Wa 98040
....hplsla----/ (206) 232-4164mem@zinn.MV.COM (Mark E. Mallett) (06/01/90)
In article <RON.90May30172314@mlfarm.uucp> ron@mlfarm.uucp (Ronald Florence) writes: >We use pathalias (9.1 87/10/04) with Xenix 2.3.2, on a ps2/80 with six >megabytes of ram. Building our map normally takes ~2 minutes. > >The recent batch of maps apparently has taken our pathalias over some >threshold. Without the map u.usa.ca.1, the build takes the same ~2 >minutes. With all of the maps included on the command line, pathalias >churns and swaps, slowly growing in size. An hour later, when I >finally killed the process, it was at 5704K (according to ps); etc. I spent quite a bit of yesterday tracking this down. The problem seems to be that bcsinc (in u.usa.ca.1) and rt1 (in u.usa.nm.1) declare each other to be terminal links with DEAD cost. I was able to replicate the problem with a 3-line pathalias input file: bcsinc <rt1>(DEAD) ditka <rt1>(DEMAND+FAST), zinn(HOURLY+FAST) rt1 <bcsinc>(DEAD) Running pathalias with trace options shows that rt1->bcsinc and bcsinc->rt1 (that is, the terminal defs of them) are trying to be resolved coninuously, with ever-increasing costs and links. I got around it by adding this to my local-defs file (which is a file that I feed into the pathalias run to supply local definitions and overrides): bcsinc rt1(DEAD) rt1 bcsinc(DEAD) In fact, I originally had "bcsinc" spelled wrong in the addition, and it still worked. Apparently all it needs is some other route between the two sites. I checked this three-line problem with a neighbor, who ran it with the -l zinn option (to pretend it was me), and they had the same results -- pathalias went into an infinite loop. Incidentally, I also checked this with another neighbor who does NOT have the problem. He says he is running an "unreleased" version of pathalias 9.1, and in fact the trace output is quite different from mine -- both in the formatting (terminals have <> instead of trailing ') and in the costs for DEAD and back links. I can hardly wait to see the update... -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask (in mail!) about MV.COM
eddjp@althea.UUCP (Dewey Paciaffi) (06/01/90)
In article <RON.90May30172314@mlfarm.uucp> ron@mlfarm.uucp (Ronald Florence) writes: >We use pathalias (9.1 87/10/04) with Xenix 2.3.2, on a ps2/80 with six >megabytes of ram. Building our map normally takes ~2 minutes. > >The recent batch of maps apparently has taken our pathalias over some >threshold. Without the map u.usa.ca.1, the build takes the same ~2 >minutes. With all of the maps included on the command line, pathalias >churns and swaps, slowly growing in size. An hour later, when I >finally killed the process, it was at 5704K (according to ps); the >machine was swapping furiously (the vmstat display made you want to >cry); and the last message from the "-v" option in pathalias was >still "***mapping". Found this in comp.mail.misc, seems to be widespread : =============================================================================== -In article <1990May29.182555.27806@pmsmam.uucp> wwm@pmsmam.uucp (Bill Meahan) writes: -> Since the latest distribution I've received from comp.mail.maps, my attempts -> to build a new pathalias database result in pathalias hanging forever while -> taking up about 4.5 MEGS of core. -> -> After spending far too much time chasing the problem, I've found that -> keeping u.usa.nm.1 out of the input stream solves(?) the problem. Apparently -> something in the lastest bunch of maps (which do NOT include nm.1 so far) -> is inconsistent with the Apr 25 version of u.usa.nm.1. -I ran into exactly the same problem. The version of pathalias I've been -using (pathalias9) runs into a loop... it cycles repeatedly between -nodes "rt1", "rt1.lanl.gov", and "bcsinc". rt1 and rt1.lanl.gov are one -and the same, and there's a bi-directional private dead link between rt1 -and bcsinc. -I have no idea why this particular combination causes pathalias to -loop... it seems that it should work properly. -I was able to resolve (work around) the problem by downloading the -latest version of pathalias from uunet (~/mail/pathalias.Z). This is a -more recent version than the one I had been using... it supports the -"adjust" clause, rather than the "-a" command-line option. It seems to -"eat" the current maps distribution without any distress. -Ghu alone knows why it fixes things, though. -- -Dave Platt VOICE: (415) 493-8805 - UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com - INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net - USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 =============================================================================== Hope this helps those who may not have seen it... -- Dewey Paciaffi eddjp@althea.UUCP