Hi David, Thanks, you're a genuis, didn't you know that? Your patch worked perfectly :)
However, it didn't solve the random freezes problem. The server felt relieved a bit, load average value pushed down a little, so when the server is working, this change did him good. Now more about a state when the server sleeps. It behaves as though the load average has suddently fired to some immense value - the system responds to ping, but all other activity has almost halted. It's not like the server went to a swap, because it occurs practically instantly, and this state goes for hours. The system is lacking some resources, or may be a bug somewhere, can you give any hints to it? My best wishes ---- Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 6 Dec 2002, David Schultz wrote: > Date: Fri, 6 Dec 2002 05:47:24 -0800 > From: David Schultz <[EMAIL PROTECTED]> > To: Varshavchick Alexander <[EMAIL PROTECTED]> > Cc: Terry Lambert <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: maxusers and random system freezes > > Thus spake Varshavchick Alexander <[EMAIL PROTECTED]>: > > On Fri, 6 Dec 2002, David Schultz wrote: > > > > > Thus spake Varshavchick Alexander <[EMAIL PROTECTED]>: > > > > Well, now I made KVA space 2G, we'll see later on if it helps to get rid > > > > of the sudden system halts, but for some reason a side-effect has > > > > appeared: pthread_create function returns EAGAIN error now, so I had to > > > > recompile the software using it with linux threads to make it working. > > > > With the old kernel these pieces worked without problems. Can it be that > > > > somehow the enlarged KVA space messed up with the threads mechanism? > > > > > > I'm not a pthreads expert, but my best guess is that your program > > > tried to create a thread with a stack address that was too high. > > > Remember that with a 2 GB KVA, user processes have only 2 GB to > > > play with instead of 3 GB, so attempting to mmap() a stack above > > > about 2 GB would cause pthread_create() to return EAGAIN. > > > > > > > Yes this makes sense, however this call to pthread_create didn't specify > > any special addresses for the new thread. The pthread_create was called > > with the NULL attribute which means that the system defaults were being > > used. Something in the system has gone wrong... > > I just glanced at the source in -STABLE, and it appears to be a > pthreads bug. (Then again, maybe I'm missing something, since > nobody seems to have noticed this before.) The default address at > which new thread stacks are created is just below the main stack. > This address is based on the lexical constant USRSTACK, but it > should be initialized in uthread_init() based on the kern.usrstack > value returned by sysctl. (The correct value is already used to > map the main stack's red zone.) The result is that you need to > make world and recompile any apps statically linked against > pthreads after building your new kernel in order to get things to > work. > > I don't have time to fiddle with pthreads until after Christmas, > but you might see if the following patch (against -STABLE) helps > when you reduce the configured KVA size without remaking pthreads. > > Index: uthread/uthread_init.c > =================================================================== > RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v > retrieving revision 1.23.2.10 > diff -u -r1.23.2.10 uthread_init.c > --- uthread/uthread_init.c 2002/10/22 14:44:03 1.23.2.10 > +++ uthread/uthread_init.c 2002/12/06 13:41:06 > @@ -245,6 +245,8 @@ > len = sizeof (int); > if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1) > _usrstack = (void *)USRSTACK; > + _next_stack = _usrstack - PTHREAD_STACK_INITIAL - > + PTHREAD_STACK_DEFAULT - (2 * PTHREAD_STACK_GUARD); > /* > * Create a red zone below the main stack. All other stacks are > * constrained to a maximum size by the paramters passed to > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
