> one problem we are currently experiencing with 0.9.1 from CVS is that the system
> spins out of control after it has been up for around 2 days. The problem happens
> when a script runs to process radacct data (it just basically moves rows from one
> table to another). Now this script runs ev
> Two strange things:
> - there seemed to be no performance impact with all the threads hanging around
> (maybe we steered clear of this since we regularly restart radiusd)
We didn't see any mayor effects but we did get increasing reports of random connection
failures, which I
:
- there seemed to be no performance impact with all the threads hanging around (maybe
we steered clear of this since we regularly restart radiusd)
- one of my servers didn't exhibit this problem, although they all run identical (as
far as I can tell) OS and software.
We use an entirely dif
On Fri, 26 Sep 2003 07:35:22 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > I haven't needed to check the log dump yet as the problem hasn't
> > duplicated with this new code.
>
> That's good, but I would like to know what was broken, and what g
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> I haven't needed to check the log dump yet as the problem hasn't
> duplicated with this new code.
That's good, but I would like to know what was broken, and what got
fixed.
> One thing I did notice was that the eap module wouldn't compile from
> th
> > There are a few references to Thread 6 which it is assigned to, but
> > nothing in the log that lets me know what the request was or what
> > happened to it... There appear to be dumps of requests in the log
> > but I cannot see any relation to this info and a request number.
>
> That's a l
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> Our NASes sometimes report radacct data to the wrong radius server
> (something I have yet to fix), so sometimes a stop packet arrives at a
> server that didn't log the start etc. Could this be contributing to
> the problem?
No. That packet shoul
On Thu, 25 Sep 2003 11:33:05 +0100
"Gary Petticrew" <[EMAIL PROTECTED]> wrote:
> I had a similar problem, but found it was being caused by radutmp and
> radwtmp! Soon as I stopped accounting to those files (I didn't have a
> reason to use them), server ran extremely well.
We are not using radwtm
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 24, 2003 6:05 PM
Subject: Re: threads hanging around
> On Wed, 24 Sep 2003 12:15:19 -0400
> "Alan DeKok" <[EMAIL PROTECTED]> wrote:
>
> > Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > > I have
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> OK, done that and have found:
>
> Wed Sep 24 16:23:58 2003 : Error: WARNING: Unresponsive child (id 6151) for request
> 426
Yup. The thread stops processing the request somewhere.
> until:
>
> Wed Sep 24 16:27:18 2003 : Error: Dropping conflict
On Wed, 24 Sep 2003 12:15:19 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > I have now tried the unmodified code and exactly the same behaviour
> > occurs. The number of threads steadily increases, default started
> > with 11 and over the space of
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> I have now tried the unmodified code and exactly the same behaviour
> occurs. The number of threads steadily increases, default started
> with 11 and over the space of 30 minutes it is up to 19
There's not much I can say. If no one else can repro
> > > OK will try, although my patch was simply to comment out the one
> > > line which sends a reject if there is no method of auth availible.
> >
> > That *shouldn't* cause a problem...
>
> I am about to try the unmodified code on one of our servers, if it is the problem I
> will let you kno
On Wed, 24 Sep 2003 10:17:58 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > > Then something's wrong.
> >
> > my thoughts exactly.. any ideas?
>
> Other than what I've said, I can't say. It depends on your local
> configuration. Usually, th
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > Then something's wrong.
>
> my thoughts exactly.. any ideas?
Other than what I've said, I can't say. It depends on your local
configuration. Usually, that means DB's are slow...
> > Hmm... try reproducing it with an unmodified version of t
> > Also when running -X the server isn't running threadded is it? hence
> > if there is a problem with the thread code this would not show it?
>
> Yes.
yes it would or yes it wouldn't? :)
> > At present the servers seem to service requests quite happily, but
> > the number of threads creeps
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> The only time I saw pauses (of about .5 of a second) was when
> messages like "Sleeping for 3" appeared, the server never seemed to
> pause waiting for a responce or other such item.
That shouldn't be a problem.
> Also when running -X the server
On Mon, 22 Sep 2003 18:57:05 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > OK, What should I be looking for? all I see is details from the
> > radius requests scrolling up the screen, is there anything I should be
> > looking for as an indication
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> OK, What should I be looking for? all I see is details from the
> radius requests scrolling up the screen, is there anything I should be
> looking for as an indication of it being held back?
Pauses. That's about it.
The server could really do w
On Mon, 22 Sep 2003 09:47:21 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > > Run it in debug mode and watch where the time is spent.
> >
> > by this do you mean the -X flag or some other debug option?
>
> -X.
>
> > I have max_spare_thread
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > Run it in debug mode and watch where the time is spent.
>
> by this do you mean the -X flag or some other debug option?
-X.
> I have max_spare_threads set to 6 and min set to 3. I have also set
> the max_request_time to 5. The databases ar
Hiya
Also just had a look through the source for the conflicting packet error and
found the following comment:
/*
* The current request isn't finished, which
* means that the NAS sent us a new packet, while
* we were waiting for a proxy response.
*
* In that case,
On Wed, 17 Sep 2003 12:20:57 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > indeed. but 403 threads is a little excessive for the load of 1 or 2
> > requests every 5 seconds. Only need that many threads when the load
> > is very high.
>
> Or, i
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> indeed. but 403 threads is a little excessive for the load of 1 or 2
> requests every 5 seconds. Only need that many threads when the load
> is very high.
Or, if each thread takes forever to process a request.
> > Then something else is causing
On Wed, 17 Sep 2003 12:05:26 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > > Find out why the server is taking so long to process requests,fix
> > > the problem, and it will be much better.
> ...
> > The length of time these theads are hanging a
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > Find out why the server is taking so long to process requests,fix
> > the problem, and it will be much better.
...
> The length of time these theads are hanging around is days.
That's not a problem. The purpose of the "thread pool" is precisely
On Wed, 03 Sep 2003 09:15:36 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> > Also the logs are now full of:
> >
> > Error: Dropping conflicting packet from client nas:1812 - ID: 85 due to unfinished
> > request 10061
>
> This error means that a
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> Also the logs are now full of:
>
> Error: Dropping conflicting packet from client nas:1812 - ID: 85 due to unfinished
> request 10061
This error means that a request is taking a HUGE amount of time to
process, so the NAS gives up on it.
Find ou
Hiya
Are there any issues with threads hanging around when they are not really
needed in FreeRadius 0.9? We had a massive auth session which ended up spawning a lot
of threads to handle the load. The load now however has dropped back down to normal,
but all the threads are still
29 matches
Mail list logo
