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.

  • assicurandosi che i demoni siano al sicuro
  • MySQL: la ricerca di database inutilizzati
  • Come faccio a rimuovere completamente MySQL da un'installazione di linux?
  • Installazione non intertriggers (silenziosa) di MySQL 5.7 su Ubuntu 16.04 LTS
  • installare mysql client e mysql-server con default charset utf8 a fedora 11
  • Emissione con dimensione massima di righe in MySQL
  • 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 | 

  • Cache MySQL (innodb_buffer_pool_size vs query_cache_ *)
  • `psql` equivalenza di modalità espansa per` mysql`
  • Differnce tra wait_timeout e interactive_timeout
  • MySQL 5.7 bind-address non funziona
  • MySQL VSS è "sicuro" ancora?
  • Aggiunta di un utente MySQL quando nessun utente MySQL dispone di diritti di amministratore?
  • Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.