nagy MySQL terheles, 1 processz?

Sziasztok!

Egy gentoo szerveren gond van a MySQL-el. Több szerveren is van gentoo, de ott nem tapasztaltam ilyet.
40 keres/mp, CPU 2x ~99% (fokozatosan kezdett kuszni, 1 honapja 30keres/mp-nel csak csucsidoben erte el, most mar delutan felmaszik)

# ps aux | grep mysql
mysql 20250 128 3.6 1222632 153284 ? Ssl 21:39 0:10 /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
root 20369 0.0 0.0 1980 696 pts/3 S+ 21:39 0:00 grep --colour=auto mysql

show processlist: http://pastebin.com/m686806e6

Mysql-t ujraforditottam, max connect 500, 1000, semmi valtozas.
1 40 MB-s tablaban dolgozik foleg, ~90.000 sorral indexelve. (Nem reg 110.000 sor volt, aztan toroltuk a regi kepeket, de nem sokat segitett).
Amit mindenkepp furcsalok,hogy csak 1 mysql processzt latok es egy debian szerveren 35keres/mp forgalmat 2x 2magos proci 15%-kal letudja. Tudom, fugg a keresek milyensegetol is, viszont a ps aux | grep -c mysql szepen 30-40db-t ir mindig. Szemben a problemassal: 1

Mi lehet a gond?

Hozzászólások

Bármi tipp, ötlet, megérzés jól jönne most Urak!

A mysql konzolon a show processlist nyomkodása sokat segíthet és ezzel együtt a konfigban a slow query logot is érdemes lenne bekapcsolni. Elképzelhető, hogy a query kess bekapcsolása, illetve a memóriájának emelése sokat segít a dolgon.

Közben látom a processlist-et. Szerintem ami sorting állapotban van az gyanús lehet. Azokra a querykre egy EXPLAIN megnéznék hogy egyáltalán mit tervez vele a mysql.

A kepeket binaris adatkent a MySQLben taroljatok, vagy csak filenev + utvonal?

Nem lehet véletlenül, hogy mysql_pconnect fut? Az tud sok connectiont fogni, bár a terhelést nem kellene növelnie.