Hi and thanks for the answers. As I understand from what I've read in the comments here: http://www.xaprb.com/blog/2006/07/16/how-we-enabled-threading-in-mysql/ This might be normal behaviour. Apparently the different types of threading used on the boxes (LinuxThreads vs NPTL) can result, for the case of LinuxThreads, in seeing the mysql threads as processes, when in fact they're not. I have no clue how boxes prepared and compiled the same way could end up with different setups, but it seems this is the reason from what i get when running "getconf GNU_LIBPTHREAD_VERSION". It seems the LinuxThreads builds are much less efficient than the NPTL ones, which for the same traffic and mysql config consume much less memory and resources (not sure how normal that is). It still sems like there's a problem here because the number of threads on the linuxthreads boxes seem to never decrease, and some need to be manually killed at shutdown. Anyway, I'll switch all boxes to NPTL and see if there's any more issues or if that does the trick. Cheers, Quentin
On 5/31/07, Scott Tanner <[EMAIL PROTECTED]> wrote:
I know I've run into this before, and it was a build issue. We build from source on redhat linux, so it may not be related to your issue. Anyways, I just did a test and built mysql from source with the flag "--with-mysqld-ldflags=-all-static". I end up with the process spawning mysqld: >ps -eaf | grep -c my 12 I removed that flag and rebuilt again, and now I have 2 processes. Just for reference: /configure --prefix=/usr/pkg/mysql5_test \ --with-libwrap=/usr/pkg/tcpd \ --with-mysqld-user=mydaemon \ --without-debug \ --with-unix-socket-path=/var/mysql/mysql.sock \ --with-client-ldflags=-all-static \ --enable-shared \ --enable-thread-safe-client \ --with-extra-charsets=none Scott On Wed, 2007-05-30 at 18:29 +0200, Quentin Gouedard wrote: > Oh and by the way mysql works just fine on that machine. You can run > queries without any problems. > Only it keeps spawning new processes over again. It takes about 3h > before the machine starts having problems due to memory getting full > of useless mysql processes. > I just got a new machine for my site, and it's happenning there too > (although on none of my 5 other boxes), which is good cause i can do > some more extensive testing before i actually use it. > Another thing is, mysql won't stop. > /etc/init.d/mysql stop just hangs. > There are some processes that need to be killed manually in the end. > I'm guessing this could have to do with the process owner being root. > > Some similar problems are reported here though: > http://forums.gentoo.org//viewtopic-t-544730-highlight-mysql.html > > > On 5/30/07, Quentin Gouedard <[EMAIL PROTECTED]> wrote: > Merci Geoffroy, > starting from the command prompt shows: > > # /usr/sbin/mysqld --console --verbose --basedir=/usr > --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid > --socket=/var/run/mysqld/mysqld.sock > 070530 18:01:28 [Note] /usr/sbin/mysqld: ready for > connections. > Version: '5.0.38-log' socket: '/var/run/mysqld/mysqld.sock' > port: 3306 Gentoo Linux mysql-5.0.38 > > > However running a ps already shows multiple mysqld processes. > Something i had not noticed so far: > > # ps -ef | grep mysqld > mysql 25752 27831 0 18:01 pts/2 > 00:00:00 /usr/sbin/mysqld --console --verbose --basedir=/usr > --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid > --socket=/var/run/mysqld/mysqld.sock > root 16560 25752 0 18:01 pts/2 > 00:00:00 /usr/sbin/mysqld --console --verbose --basedir=/usr > --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid > --socket=/var/run/mysqld/mysqld.sock > root 16560 25752 0 18:01 pts/2 > 00:00:00 /usr/sbin/mysqld --console --verbose --basedir=/usr > --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid > --socket=/var/run/mysqld/mysqld.sock > root 23390 16560 0 18:01 pts/2 > 00:00:00 /usr/sbin/mysqld --console --verbose --basedir=/usr > --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid > --socket=/var/run/mysqld/mysqld.sock(etc.) > > the first process created is the only one with "mysql" owner. > All the subsequent processes are own by root, and have as > parent one of the previously created processes (not always the > first one). Not sure if that helps in understanding this > though. > > Thanks anyway for your help. > > > On 5/30/07, Geoffroy Cogniaux <[EMAIL PROTECTED]> > wrote: > Try to start it with mysql_safe instead or try to > start mysqld manually > within a command prompt, without fork, to see what > happen. > ./mysqld --console --verbose --your_options > > Can you at least connect to mysql with a remote client > on this server or > not? > > Have a look on this page about starting issues: > http://dev.mysql.com/doc/refman/5.0/en/unix-post-installation.html#starting- > server > > Geoffroy > > -----Message d'origine----- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De > la part de Quentin > Gouedard > Envoyé: mercredi 30 mai 2007 09:02 > À: Scott Tanner > Cc: mysql@lists.mysql.com > Objet: Re: mysql creating lots of processes (not > threads, linux processes) > > Nope, I'm using 5.0.38 on Gentoo, built via emerge in > the exact same manner. > Thanks for your answers guys. > > On 5/30/07, Scott Tanner > <[EMAIL PROTECTED]> wrote: > > > > Sounds like your not using threaded libraries. Was > mysql built > > differently, or are you using a different RPM on > this server? > > > > > > Scott > > > > > > > > On Tue, 2007-05-29 at 22:49 +0200, Quentin Gouedard > wrote: > > > No, I have just collectd+mrtg, but i don't even > use them to monitor > > mysql. > > > I launch mysql via /etc/init.d/mysql start , and > the script is the exact > > > same as on the other servers. Even just after > startup there's already > > 15-20 > > > processes created. > > > > > > On 5/29/07, Geoffroy Cogniaux > <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > > > > > It looks like automatic start-up called by a > monitoring process > > (Nagios, > > > > ...). Have you such tools on your servers ? > > > > > > > > Geoffroy > > > > > > > > -----Message d'origine----- > > > > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > > Quentin > > > > Gouedard > > > > Envoyé: mardi 29 mai 2007 16:41 > > > > À: mysql@lists.mysql.com > > > > Objet: mysql creating lots of processes (not > threads, linux processes) > > > > > > > > Hi, > > > > So I use mysql as the DB for a large site (up to > 10000 concurrent > > users at > > > > peaks). > > > > I have a front server as a reverse proxy and > multiple (7) backend > > machines > > > > serving the site. > > > > Each machine has data strictly similar in nature > and quantity. > > > > > > > > On 6 of these machines, I have 1 single mysqld > process (process in > > linux > > > > terms): > > > > # ps -ef | grep mysqld | wc -l > > > > 2 > > > > > > > > There are generally 5-8 threads (processes as > mysql means it) running > > when > > > > i > > > > do a show processlist; > > > > > > > > > > > > Now, on one of those machines there are huge > number of processes for > > > > mysql. > > > > # ps -ef | grep mysqld | wc -l > > > > 34 > > > > Running just ps shows for each of these > processes: > > > > mysql 25952 10073 0 > 16:25 ? 00:00:02 /usr/sbin/mysqld > > > > --defaults-file=/etc/mysql/my.cnf > --basedir=/usr > > --datadir=/var/lib/mysql > > > > --pid-file=/var/run/mysqld/mysqld.pid > > --socket=/var/run/mysqld/mysqld.sock > > > > > > > > This machine has no particular data, is doing > nothing different than > > the > > > > others. > > > > The show processlist command also returns 5-8 > processes. > > > > > > > > So where are these myqsld processes from ? > There's like 20 at startup > > > > (instantly after launching mysql), but it keeps > increasing, until i > > > > restart > > > > mysql or the server runs out of memory. I have > compared the mysql > > > > configuration of this machine and the 6 other, > variable by variable, > > and > > > > they are strictly identical. > > > > How come this server behaves differently ? What > can I do to have the > > > > single-process behaviour on that machine too ? > > > > > > > > Thanks, > > > > Quentin > > > > > > > > > > > > > > > > > > > > >