We wrote a wrapper with LD_PRELOAD. When mysqld does
pthread_attr_setstacksize() we translate it into an anonymous mmap()
and use pthread_attr_setstackaddr() instead. It's the equivalent
of FLOATING_STACKS. ;)
Our mysqld (which is running as slave) will seg fault if we set
the thread_stack to 25
Michael Bacarella wrote:
Does Red Hat have some kind of userland address space hack that
we're not aware of?
Do you have any special kernel config options that you did not use before?
the thread stacks are 2MB apiece (bf601000-bf80 is
2093056 bytes, or 2044kB)! Yet:
# mysql -e 'show variable
> >>>Does Red Hat have some kind of userland address space hack that
> >>>we're not aware of?
> >>
> >>Do you have any special kernel config options that you did not use before?
> > the thread stacks are 2MB apiece (bf601000-bf80 is
> > 2093056 bytes, or 2044kB)! Yet:
> >
> > # mysql -e 'sho
Michael Bacarella wrote:
We recently started getting "Can't create thread" errors since
switching to Debian.
On Red Hat 8.0 we were able to spawn more than 400 mysql threads
and never encountered this error. mysql 3.23.56 compiled from
source, stock kernel. (2GB of RAM)
Now we
t: Re: "Can't create thread"
>
> > > We recently started getting "Can't create thread" errors since
> > > switching to Debian.
> > >
> > > On Red Hat 8.0 we were able to spawn more than 400 mysql threads
> > > and n
> > We recently started getting "Can't create thread" errors since
> > switching to Debian.
> >
> > On Red Hat 8.0 we were able to spawn more than 400 mysql threads
> > and never encountered this error. mysql 3.23.56 compiled from
> > source,
Michael Bacarella wrote:
We recently started getting "Can't create thread" errors since
switching to Debian.
On Red Hat 8.0 we were able to spawn more than 400 mysql threads
and never encountered this error. mysql 3.23.56 compiled from
source, stock kernel. (2GB of RAM)
Now we
We recently started getting "Can't create thread" errors since
switching to Debian.
On Red Hat 8.0 we were able to spawn more than 400 mysql threads
and never encountered this error. mysql 3.23.56 compiled from
source, stock kernel. (2GB of RAM)
Now we get it all the time on
t did. I set ulimit -u to 50
and restarted mysql. It worked fine until max_used_connectsion and the
number of sleeping/persistent connections got up to 45, then it started
throwing off the "Can't create thread" error. Then I did ulimit -u 150 and
restarted mysql again. This time
gt; set-variable = wait_timeout=10
>
> I tried this, and it was a mixed bag. On the one hand, the "Can't create
> thread..." error did indeed go away, and max_used_connections and the
> number of sleeping/persistent connections dropped down well below
> 250. However
and it was a mixed bag. On the one hand, the "Can't create
> thread..." error did indeed go away, and max_used_connections and the
> number of sleeping/persistent connections dropped down well below
> 250. However, making this change caused a new problem: on about ever
Hi Don,
Thanks for the suggestions. Here's what happened.
> Your pconnects are probably sleeping too long.
in /etc/my.cnf:
[mysqld]
set-variable = wait_timeout=10
I tried this, and it was a mixed bag. On the one hand, the "Can't create
thread..." error
On 31-Mar-2003 Mike William wrote:
> After a routine restart of our MySQL 3.23 server today, we began getting
> the following PHP error message during times of moderately high database
> server load:
>
> Warning: MySQL Connection Failed: Can't create a new thread (errno 11).
> If
> you are no
After a routine restart of our MySQL 3.23 server today, we began getting
the following PHP error message during times of moderately high database
server load:
Warning: MySQL Connection Failed: Can't create a new thread (errno 11). If
you are not out of
available memory, you can consult the man
14 matches
Mail list logo
