Long time to connect to MySQL server on sparc64
Hi, I have problem with connection to MySQL server running on Sun Netra X1. Connecting to MySQL server takes average around 20 second, but it's variable. After connect to the server, SQL queries are fast. Problem is only with connection and it doesn't matter if I connecting through mysql socket, localhost or client from LAN. The delay is same. I don't know what is wrong, but it's very annoying and makes web pages which uses DB very slow. The MySQL server is from package mysql-server-5.0.51a.tgz with common my.cnf (sample my-small.cnf) configuration and running on OpenBSD 4.3 GENERIC#1555 sparc64. I tried compile MySQL 4.1.22 from source but problem is same. There's propably something wrong only with sparc64 distribution because I have same configuration on OpenBSD 4.3 GENERIC#698 i386 and without this problem. After some attempts to find a solution to the problem I found technique which make connection faster, but I don't know what that implies. If I connect to the MySQL and at the same time execute something on server into which I connecting, the connection accomplish immediately. If I execute infinity loop like this "while true; do uptime; done;" connection to MySQL afterwards isn't longer than 1 second. Can anybody help me how fix this problem?
Re: Long time to connect to MySQL server on sparc64
The log didn't help at all. General log: mysql-server-5.0.51a). started with: Tcp port: 3306 Unix socket: /var/run/mysql/mysql.sock Time Id CommandArgument 090803 22:43:22 1 Connect r...@localhost on 1 Query select @@version_comment limit 1 090803 22:43:44 1 Quit 090803 22:46:34 2 Connect r...@localhost on 2 Query select @@version_comment limit 1 090803 22:47:54 2 Query show status 090803 22:47:58 2 Quit Error log: 090803 22:42:46 mysqld started 090803 22:42:49 InnoDB: Started; log sequence number 0 172056 090803 22:42:49 [Note] /usr/local/libexec/mysqld: ready for connections. Version: '5.0.51a-log' socket: '/var/run/mysql/mysql.sock' port: 3306 OpenBSD port: mysql-server-5.0.51a 090803 22:48:04 [Note] /usr/local/libexec/mysqld: Normal shutdown 090803 22:48:05 InnoDB: Starting shutdown... 090803 22:48:06 InnoDB: Shutdown completed; log sequence number 0 172056 090803 22:48:06 [Note] /usr/local/libexec/mysqld: Shutdown complete 090803 22:48:06 mysqld ended DNS resolver is fast. I tried also --skip-name-resolve but didn't help too. I think there is no problem with network. The delay is also when I connecting through mysql.sock. As I write in last post, I have two servers. One is i386 arch, second one is sparc64. On the both servers is same OpenBSD 3.4 and same version MySQL from package. Both are on same LAN, both have same my.cnf which is example copy from /var/local/share/mysql/my-small.cnf without changes. Different is only architecture but problem is only on sparc64. The i368 server is Intel Celeron 500MHz with 192MB RAM and sparc64 is Netra X1 UltraSPARC IIe 500MHz with 512MB RAM. Today I have found that on sparc64 is also variable delay when I starting and stopping mysql server in comparison with i386. - Original Message - From: "Darrin Chandler" To: "MPrik" Cc: Sent: Monday, August 03, 2009 2:55 AM Subject: Re: Long time to connect to MySQL server on sparc64 On Sun, Aug 02, 2009 at 11:18:38PM +0200, MPrik wrote: Hi, I have problem with connection to MySQL server running on Sun Netra X1. Connecting to MySQL server takes average around 20 second, but it's variable. After connect to the server, SQL queries are fast. Problem is only with connection and it doesn't matter if I connecting through mysql socket, localhost or client from LAN. The delay is same. I don't know what is wrong, but it's very annoying and makes web pages which uses DB very slow. The MySQL server is from package mysql-server-5.0.51a.tgz with common my.cnf (sample my-small.cnf) configuration and running on OpenBSD 4.3 GENERIC#1555 sparc64. I tried compile MySQL 4.1.22 from source but problem is same. There's propably something wrong only with sparc64 distribution because I have same configuration on OpenBSD 4.3 GENERIC#698 i386 and without this problem. After some attempts to find a solution to the problem I found technique which make connection faster, but I don't know what that implies. If I connect to the MySQL and at the same time execute something on server into which I connecting, the connection accomplish immediately. If I execute infinity loop like this "while true; do uptime; done;" connection to MySQL afterwards isn't longer than 1 second. Can anybody help me how fix this problem? Check your mysql logs. There may be a clue there. How is DNS on this machine? Does it resolve the machines trying to connect to it? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Long time to connect to MySQL server on sparc64
44 mysqld CALL poll(0x50594000,0x3,0x3e8) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x48b95da0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d000,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x3,0x3ca) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4ddd3d80,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d400,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x3,0x13) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x48b95da0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d000,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0 x50594000,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x3,0x3e8) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x48b95da0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d000,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x3,0x3c0) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4ddd3d80,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d400,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x2,0) 9344 mysqld RET poll 0 934 4 mysqld CALL poll(0x50594000,0x3,0x1d) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x48b95da0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d000,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x3,0x3e8) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x48b95da0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL poll(0x40b6d000,0,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL poll(0x50594000,0x3,0x3b6)> On Mo n, Aug 3, 2009 at 5:41 PM, MPrik wrote:>> DNS resolver is fast. I tried also --skip-name-resolve but didn't helptoo.>> I think there is no problem with network. The delay is also when I>> connecting through mysql.sock.>> As I write in last post, I have two servers. One is i386 arch, second oneis>> sparc64. On the both servers is same OpenBSD 3.4 and same version MySQLfrom>> package. Both are on same LAN, both have same my.cnf which is examplecopy>> from /var/local/share/mysql/my-small.cnf without changes. Different isonly>> architecture but problem is only on sparc64. The i368 server is Intel>> Celeron 500MHz with 192MB RAM and sparc64 is Netra X1 UltraSPARC IIe500MHz>> with 512MB RAM.>> Today I have found that on sparc64 is also variable delay when I starting>> and stopping mysql server in comparison with i386.>> ktrace it.>
Re: Long time to connect to MySQL server on sparc64
I have no knowledge of the procces tracing. Can anybody explain me what this ktrace output represent, please? The man pages didn't help. The marked segment is probably that problem, the delay when connecting to mysql, because is repeated many times. . . . 9344 mysqld RET fcntl 6 9344 mysqld CALL setsockopt(0x16,0,0x3,0xfffd699c,0x4) 9344 mysqld RET setsockopt -1 errno 42 Protocol not available 9344 mysqld CALL gettimeofday(0xfffd69a0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL mmap(0,0x22000,0x3,0x1002,0x,0,0) 9344 mysqld RET mmap 1198186496/0x476ae000 9344 mysqld CALL mprotect(0x476ae000,0x2000,0) 9344 mysqld RET mprotect 0 9344 mysqld CALL poll(0x40b6c800,0x2,0) 9344 mysqld RET poll 0 9344 mysqld CALL gettimeofday(0x476cfda0,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL setsockopt(0x16,0x,0x8,0x476cfc0c,0x4) 9344 mysqld RET setsockopt 0 9344 mysqld PSIG SIGPROF caught handler=0x4e0ee9a0 mask=0x0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL sigprocmask(0x3,0) 9344 mysqld RET sigprocmask -65793/0xfffefeff 9344 mysqld CALL poll(0x50594000,0x2,0) ### This segment repeated 2768 times ### 9344 mysqld RET poll 0 9344 mysqld CALL sigreturn(0x476cf9b0) 9344 mysqld RET sigreturn JUSTRETURN 9344 mysqld PSIG SIGPROF caught handler=0x4e0ee9a0 mask=0x0 9344 mysqld CALL gettimeofday(0x4e2f4060,0) 9344 mysqld RET gettimeofday 0 9344 mysqld CALL sigprocmask(0x3,0) 9344 mysqld RET sigprocmask -65793/0xfffefeff 9344 mysqld CALL poll(0x50594000,0x2,0) ### end ### 9344 mysqld RET poll 0 9344 mysqld CALL sigreturn(0x476cf9b0) 9344 mysqld RET sigreturn JUSTRETURN . . .
