Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!Germany.EU.net!howland.reston.ans.net!gatech!newsfeed.internetmci.com!in2.uu.net!olivea!strobe!jerry From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.solaris,news.software.nntp Subject: Re: INND takethis really long pauses problem (more info) Date: 20 Jan 1996 05:16:25 GMT Organization: Olivetti ATC; Cupertino, CA; USA Lines: 33 Distribution: inet Message-ID: <4dptr9$o0f@olivea.ATC.Olivetti.Com> References: <30e8909b.1118570368@newsfeed.kdcol.com> <30ec12f8.10926492@news.kdcol.com> <30f9e36c.10513600@newsfeed.kdcol.com> <slrn4fmpin.l7q.hwr@snert.pilhuhn.de> NNTP-Posting-Host: strobe.atc.olivetti.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:12472 comp.unix.solaris:57144 news.software.nntp:19007 In article <slrn4fmpin.l7q.hwr@snert.pilhuhn.de> hwr@pilhuhn.de (Heiko W.Rupp) writes: >This is a problem with the streaming patch - I never saw it that hard, >but these pauses ocured from the very beginning. Jerry has posted a >replacement with some fixes some days ago, so this might help here. >You might look in news.software.nntp Just to clarify the situation. The problem I eventually tracked down involved innd going into a heavily compute bound state. The length of time depended on the size of the article being processed and was most noticable with the 1 megabyte alt.binaries type. The key symptoms that marked this condition were that innd was using up all the free CPU cycles and no other innd work was being accomplished. The patches I recently posted prevent this from happening. Note that streaming is still likely to hog innd and make other functions SLIGHTLY more sluggish. With streaming innd can process several history lookups or small articles in one pass thru the loop. I also see another problem with different symptoms. I still sometimes have long delays for "ctlinnd" commands. The difference now is that innd is not consuming abnormal CPU resources. Monitoring the logs shows that it continues to service incomming articles from several sites. This only happens under heavy load. A second server running the same code but with only one feed never shows this problem. Thus it is clear that innd is still cycling thru its channel service loop. That should be checking for ctlinnd commands once every pass. It is unclear to me how the streaming patches could be preventing innd from getting ctlinnd commands when innd is still checking for them. I begin to wonder if some kernal/networking bug is being triggered. Perhaps the volume of queued data prevents the ctlinnd commands from being passed? Is something giving priority to TCP processing over unix domain?