cudcv@warwick.ac.uk (Rob McMahon) (03/10/91)
Posting news via NNTP to our (admittedly overloaded) news server often borders on the painful, like time to go and make a cup of coffee. Whilst idling some time until I got a prompt back, I followed what was happening, and it seems to be this: nntpd -> inews -W -> relaynews newsrun -> relaynews grabs lock tries to get lock, sleeps ... ... releases lock grabs lock wakes up, still locked, sleeps ... ... releases lock grabs lock wakes up, still locked, sleeps ... ... realease lock ... etc. On a bad day, this can take 15 - 20 minutes. It seems like what is needed is some sort of mechanism to say "I'm next". I can see the aversion to using flock/lockf, but has anyone tried adapting the algorithm to do something like (this isn't real shell, you understand, it's all running as one process) ... echo $$ > LOCKtmp while :; do if ln LOCKtmp LOCK; then break else ln LOCKtmp LOCK.wait sleep n fi done ... rm LOCK kill -ALRM `cat LOCK.wait` Am I dreaming ? Suggestions ? Cheers, Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
tale@rpi.edu (David C Lawrence) (03/11/91)
The answer is simplere than that to avoid delays on the lock file.
Simply do not call relaynews directly from anywhere in inews.
Depending on how you are set-up to process in.coming/, either rnews or
newsspool is a suitable alternative.
--
(setq mail '("tale@rpi.edu" "uupsi!rpi!tale" "tale@rpitsmts.bitnet"))henry@zoo.toronto.edu (Henry Spencer) (03/12/91)
In article <ZFF&53@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >Posting news via NNTP to our (admittedly overloaded) news server often borders >on the painful, like time to go and make a cup of coffee... There's a problem in that the posting strategy basically assumes that the relaynews lock has a low duty cycle, which is not always true on hard- working NNTP systems. Probably the best quick fix is to have inews spool the stuff rather than firing up relaynews, although then people will complain that their posting hasn't appeared quickly. A priority scheme for input spooling would help, and in fact modifications along these lines are in the works. -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry
moraes@cs.toronto.edu (Mark Moraes) (03/13/91)
Modifying inews (or whatever posting agent is used %) to warn of a small delay and using newsspool seemed to work nicely for us. (Also for a couple of other sites whom I've suggested this fix to) It is only a problem on sites that turn off unbatching during the day. For sites running C News relaynews, this is not necessary on machines of > Sun3 CPU power. Mark. % nn warns of a small delay when posting anyway since it takes a while for nnmaster to notice a new article.
bdale@col.hp.com (Bdale Garbee) (03/14/91)
>Probably the best quick fix is to have inews spool >the stuff rather than firing up relaynews, although then people will >complain that their posting hasn't appeared quickly. This is what we've done for some time, and the moaning seemed to dampen towards zero about a week after we changed... Bdale
ronald@robobar.co.uk (Ronald S H Khoo) (03/14/91)
henry@zoo.toronto.edu (Henry Spencer) writes: > There's a problem in that the posting strategy basically assumes that the > relaynews lock has a low duty cycle, which is not always true on hard- > working NNTP systems. It's not just hardworking NNTP systems that have high duty-cycle relaynews locks either. UUCP sites in countries with seriously expensive telephone charges (no flatrate or free local calls in the UK [except maybe Hull?]) have problems too. I saw relaynews locked solid for ages last night. And posting isn't the only place where the low duty cycle is assumed either. There's a real problem that sendbatches is totally locked out during one single newsrun that lasts for hours. This means that valuable trailblazer time is wasted between finishing the 6pm call collecting the news from the backbone and newsrun to finish processing it, before the stuff for downstream sites get queued. In fact, I'm thinking of kludgeing it so that newsrun keeps a count of how many batches its done, and after a limit, sleeping for a few minutes to let sendbatches in (retaining LOCKinput, of course) then exiting or continuing. Basically, just forcibly lower the duty cycle. Henry, is this unreasonable, or have you got a better idea ? -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
henry@zoo.toronto.edu (Henry Spencer) (03/20/91)
In article <1991Mar14.092311.20751@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >In fact, I'm thinking of kludgeing it so that newsrun keeps a count of how >many batches its done, and after a limit, sleeping for a few minutes to >let sendbatches in (retaining LOCKinput, of course) then exiting or >continuing. Basically, just forcibly lower the duty cycle. > >Henry, is this unreasonable, or have you got a better idea ? Actually, in systems where news comes in compressed, there is already an effect much like this, since newsrun and friends take time off from holding down LOCK every time they have to decompress a batch. The obvious place to put code for a delay would be at the end of the outer loop, which runs 50 batches per iteration. This is worth considering; I'll take a look at it next time I'm working on the input subsystem. -- "[Some people] positively *wish* to | Henry Spencer @ U of Toronto Zoology believe ill of the modern world."-R.Peto| henry@zoo.toronto.edu utzoo!henry