I've asked Julian to file separate PR reports for the specific problems, so I'll respond in-line to the general/non-PR stuff.
-----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Julien TOUCHE > Sent: Friday, April 16, 2004 10:09 AM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop-dev] Re: openbsd > > > > with last port, a run as daemon or not with no problem at all > one is with external libpcap 0.8.3 (compile libpcap with prefix=/opt and > `FLAVOR=pcap8 make install`), other as normal > both run for nearly two days each with no single problem except they > need about 5 minutes before responding normally to http requests. As a really rough guess, that sounds like some kind of conflict with one of the Mutexes holding things up? I wonder if you enable some of the debugging messages, what shows up when it finally begins to respond?? You could even try the #define PARM_SHOW_NTOP_HEARTBEAT 1 option - it should then begin to show messages for each of the thread loops, etc. > but you are STRONGLY advised to `sysctl -w kern.maxproc=1024` as else > ntop exhausted proc table with zombies (something like a self Dos; > experimented) ... There used to be problems w/ zombies under Solaris. I saw some recently, but it wasn't clear if that was because the ntop instance CRASHED or because it was creating them. The logic in util.c's killThread() has always bothered me: int killThread(pthread_t *threadId) { int rc; rc = pthread_detach(*threadId); if(rc != 0) traceEvent(CONST_TRACE_NOISY, "killThread(0x%x), rc = %s(%d)", threadId, strerror(rc), rc); myGlobals.numThreads--; return(rc); } I've always thought there should be a pthread_kill() call too. But we only kill threads at the end of the run, so the OS reap should fix this. However, for most reporting pages, we fork() to create a child with a copy of the data so ntop can continue on. I wonder if those are the zombies... Try running with -K (debug mode) - it skips the fork() calls (although this means that the http creation is done in the same thread, so response time suffers - don't create the BIG pages showing 1000s of hosts...) See if -K makes ntop stop creating zombies. If so, that gives us a place to look. > (this one i think is due to the fact ntop use root limits against the one > of _ntop user; why is another story ...) Why is probably because the process is initiated as root. > > minor note: > * in some case i have vertical frame, other horizontal ? Left over html files from the old version? Don't know - need to see an example. > * somehow, i find strange ntop take 90% CPU of a PII/350 for a home > server traffic (even it is high in this category) Userland threads - so the compile converts many of the interrupt driven calls to polling calls - this is what we saw in FreeBSD. That's why the pcap set nonblocking option exists - it converts the key call to a poll()/nanosleep() cycle. Give it a try - now that you have libpcap 0.8.x, the set_pcap_nonblocking() call should be available to you. <snip/> > Regards > > Julien _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
