mysql client strace di accesso lento

Trovo un problema con collegamenti / login lenti a un server mysql caricato, anche quando si connette tramite il file sox unix (CentOS 6.3). Le query si completano molto rapidamente – (0.00 sec) in questo caso – ma il login richiede fino a parecchi secondi, in questo caso:

 real 0m3.128s user 0m0.010s sys 0m0.011s 

mysqld è in esecuzione con skip-name-resolve e un thread_cache_size tale da non creare nuovi thread durante questo numero. È un problema basato sul carico , vale a dire che le registrazioni sono molto veloci quando il server è inattivo. Il server gestisce circa 60 connessioni e 300 query al secondo su hardware potente, quindi è bene sottoutilizzato.

Ecco la sezione di un strace in cui si ferma, notato con le righe vuote. Sto assumendo la stalla in read( significa che sta aspettando una risposta dal server:

 $ time strace mysql -e 'select 1' [...] read(3, "# /etc/services:\n# $Id: services"..., 4096) = 4096 read(3, "ervice\nfinger 79/tcp\nfi"..., 4096) = 4096 read(3, " 209/udp "..., 4096) = 4096 read(3, "a-cluster 694/tcp "..., 4096) = 4096 read(3, " 1494/tcp "..., 4096) = 4096 read(3, "603/udp #"..., 4096) = 4096 close(3) = 0 munmap(0x7f10609da000, 4096) = 0 rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x3318c32920}, {SIG_DFL, [], 0}, 8) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 fcntl(3, F_SETFL, O_RDONLY) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) connect(3, {sa_family=AF_FILE, path="/var/run/mysqld/mysqld.sock"}, 110) = 0 setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 setsockopt(3, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported) setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 read(3, "e\0\0\0\n5.5.29-ndb-7.2.10-cluster-g"..., 16384) = 105 open("/usr/lib/locale/locale-archive", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0 mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f105216f000 close(4) = 0 stat("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0755, st_size=18312, ...}) = 0 brk(0x222b000) = 0x222b000 open("/usr/share/mysql/charsets/Index.xml", O_RDONLY) = 4 read(4, "<?xml version='1.0' encoding=\"ut"..., 18312) = 18312 close(4) = 0 futex(0x986300, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(3, "P\0\0\1\205\242\17\0\0\0\0\1!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 84) = 84 

Per quello che vale, questo mysqld è un nodo API davanti a NDB (MySQL Cluster), ma ho una sensazione che non ha nulla a che fare con NDB, dato che le query contro le tabelle NDB stanno tornando molto rapidamente.

AGGIORNARE

configurare la nostra applicazione php per utilizzare le connessioni persistenti ( p:<hostname> con mysqli) ha risolto completamente il problema, ma sono ancora sorpreso di ciò che un basso tasso di connessione è diventato un problema rispetto al normale mysqld e al cluster Percona XtraDB.

per rispondere alla domanda di @ HTTP500, non vediamo il checking permissions , ma vedi alcuni di questi in qualsiasi momento:

 395354 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL | 

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.