Rails 2.2.2 Performance Problem/Bug - mysql

I recently upgraded one of my applications to Rails 2.2.2. Having done that, I've encountered a strange performance bug that has caused renders that used to complete in a fraction of a second to take up to 10 seconds.
I've profiled the issue, and here are the results I've come up with. It looks like the issue is in the real_connect method of the Mysql class. My understanding is that the Ruby real_connect method is a wrapper around the C mysql_real_connect() function. This would lead me to believe that the issue must be with the database, since I've encountered the same problem when running the code on Windows and Linux (the database server is a separate system). I don't, however, believe this is the case, because when I roll back to a previous version (pre Rails 2.2.2) from my subversion repository, the performance issue goes away. This would seem the indicate that there is some kind of bug in ActiveRecord.
How do I go about identifying and fixing this bug? Does anyone have any insight? Is there something I'm missing?
Update: I just created a small profiler script to test the Mysql.real_connect method, and it appears that the problem isn't in Rails, but in the MySQL gem or the database server itself.
Upon running the following code:
result = RubyProf.profile do
5.times do
begin
# connect to the MySQL server
dbh = Mysql.real_connect(ip, user, pass, db)
# get server version string and display it
puts "Server version: " + dbh.get_server_info
rescue Mysql::Error => e
puts "Error code: #{e.errno}"
puts "Error message: #{e.error}"
puts "Error SQLSTATE: #{e.sqlstate}" if e.respond_to?("sqlstate")
ensure
# disconnect from server
dbh.close if dbh
end
end
end
printer = RubyProf::FlatPrinter.new(result)
printer.print(STDOUT, 0)
I came up with this performance result:
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Thread ID: 18998180
Total: 50.402000
%self total self wait child calls name
99.99 50.40 50.40 0.00 0.00 5 <Class::Mysql>#real_connect (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 10 IO#write (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 Mysql#get_server_info (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 Kernel#puts (ruby_runtime: 0}
0.00 0.00 0.00 0.00 0.00 5 String#+ (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 Mysql#initialize (ruby_runtime:0}
0.00 50.40 0.00 0.00 50.40 1 Integer#times (ruby_runtime:0}
0.00 50.40 0.00 0.00 50.40 1 Global#[No method] (tmp/mysql_test/test.rb:12}
0.00 0.00 0.00 0.00 0.00 5 Mysql#close (ruby_runtime: 0}
It seems as though the problem isn't in ActiveRecord, it's either in the MySQL gem or in the database. Where do I go from here?

I was able to track down the problem. I started by connecting to the host using the MySQL command from my development machine using the command mysql --host=ip --user=user --password=password db. This was very slow, so I ssh'ed into the server, and connected from there using the same command. This was also slow.
I changed the command to mysql --host=localhost --user=user --password=password db and I was able to connect instantaneously. I added an entry for my development system in the /etc/hosts file, and was able to connect instantaneously from that as well. Apparently the MySQL server was attempting to perform a reverse dns lookup to resolve the host name associated with the IP address, as is listed in the MySQL Manual, and was timing out.
I added the --skip-name-resolve option to the start section of the /etc/init.d/mysql script, so that this check is skipped, and restarted the server. When I run the profile script I created earlier, I get the following result:
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Server version: 5.0.32-Debian_7etch3-log
Thread ID: 52978590
Total: 0.016000
%self total self wait child calls name
87.50 0.01 0.01 0.00 0.00 5 <Class::Mysql>#real_connect (ruby_runtime:0}
6.25 0.00 0.00 0.00 0.00 10 IO#write (ruby_runtime:0}
6.25 0.00 0.00 0.00 0.00 5 Mysql#close (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 Kernel#puts (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 Mysql#initialize (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 String#+ (ruby_runtime:0}
0.00 0.02 0.00 0.00 0.02 1 Global#[No method] (tmp/mysql_test/test.rb:12}
0.00 0.02 0.00 0.00 0.02 1 Integer#times (ruby_runtime:0}
0.00 0.00 0.00 0.00 0.00 5 Mysql#get_server_info (ruby_runtime:0}

Related

Why mysql import tablespace so slow with insert/update sql pressure?

I have schema A and B in my mysql,when I do a pressure test on schema A which include lots of concurrent batch insert and update sql operation and import many tablespace from files which was exported by xtrabackup on schema B.I found the import operation is very slow and cost lots of time (more than one hour). If I don't do pressure test on schema A and the import operation just cost 20 seconds nearly.
show processlist:
856 guest 10.142.90.17:51671 pinc_0002 Query 733 Table lock alter table bill import tablespace 0
857 guest 10.142.90.17:51700 pinc_0002 Query 733 Table lock alter table company import tablespace 0
858 guest 10.142.90.17:51731 pinc_0002 Query 733 Table lock alter table car_new import tablespace 0
859 guest 10.142.90.17:51758 pinc_0002 Query 733 Table lock alter table dialing_his import tablespace 0
860 guest 10.142.90.17:51799 pinc_0002 Query 733 Table lock alter table car import tablespace 0
861 guest 10.142.90.17:51846 pinc_0002 Query 732 Table lock alter table employee_his_new import tablespace 0
862 guest 10.142.90.17:51869 pinc_0002 Query 732 Table lock alter table book import tablespace 0
863 guest 10.142.90.17:51914 pinc_0002 Query 732 Table lock alter table goods import tablespace 0
864 guest 10.142.90.17:51975 pinc_0002 Query 732 Table lock alter table order_details import tablespace 0
result of SHOW ENGINE INNODB STATUS
select * from information_schema.INNODB_LOCKS:
115155367:9417:4:2 115155367 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
115153055:9417:4:2 115153055 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
115150974:9417:4:2 115150974 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
115148337:9417:4:2 115148337 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
result of select * from information_schema.INNODB_TRX
top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
54996 apps 20 0 111g 71g 8664 S 1794.7 14.2 2254:20 mysqld
iostat -dxm:
```
[apps#cs1n3 ~]$ iostat -dxm 2
Linux 2.6.32-358.el6.x86_64 (cs1n3) 02/08/2017 _x86_64_ (64 CPU)
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.04 485.19 8.12 76.89 0.19 2.43 63.20 0.19 2.25 0.16 1.38
sdb 0.00 8.14 0.03 2.44 0.00 0.04 35.10 0.01 4.51 0.14 0.04
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 841.50 0.00 7003.50 0.00 63.91 18.69 3.13 0.45 0.13 94.20
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
```
```
iostat -dxm
Linux 2.6.32-358.el6.x86_64 (cs1n3) 02/08/2017 _x86_64_ (64 CPU)
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.04 485.19 8.12 76.89 0.19 2.43 63.20 0.19 2.25 0.16 1.38
sdb 0.00 8.14 0.03 2.44 0.00 0.04 35.10 0.01 4.51 0.14 0.04
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 841.50 0.00 7003.50 0.00 63.91 18.69 3.13 0.45 0.13 94.20
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
```
Maybe answer is in your table architecture. If you have PRIMARY_KEY in yours tables, your database has B-Tree structure, but if you have tables without PRIMARY_KEY, your database has table structure. So, maybe you have table structure in your database, so operation add/update costs more than B-Tree structure.

How to solve MySQL innodb "Waiting for table metadata lock" on TRUNCATE TABLE?

Running a test suite with hundreds of application unit tests in a GitLab CI server. After ran 10 tests in, somehow it always gets stuck on Waiting for table metadata lock on TRUNCATE TABLE, which is a tearDown step.
I am aware of the SHOW ENGINE INNODB STATUS command . Here are some diagnostic logs:
mysql> \s
--------------
mysql Ver 14.14 Distrib 5.6.30, for Linux (x86_64) using EditLine wrapper
Connection id: 190
Current database:
Current user: root#localhost
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 5.6.30 MySQL Community Server (GPL)
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: utf8mb4
Db characterset: utf8mb4
Client characterset: utf8mb4
Conn. characterset: utf8mb4
UNIX socket: /var/run/mysqld/mysqld.sock
Uptime: 51 min 28 sec
Threads: 4 Questions: 3859 Slow queries: 0 Opens: 715 Flush tables: 1 Open tables: 131 Queries per second avg: 1.249
--------------
mysql> show processlist;
+-----+------+----------------+------------+---------+------+---------------------------------+-----------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+----------------+------------+---------+------+---------------------------------+-----------------------------+
| 1 | root | 10.0.2.1:52773 | test_3926 | Query | 2961 | Waiting for table metadata lock | TRUNCATE TABLE `capability` |
| 188 | root | 10.0.2.1:53658 | test_3926 | Sleep | 2962 | | NULL |
| 189 | root | 10.0.2.1:53660 | test_3926 | Sleep | 2962 | | NULL |
| 190 | root | localhost | NULL | Query | 0 | init | show processlist |
+-----+------+----------------+------------+---------+------+---------------------------------+-----------------------------+
4 rows in set (0.00 sec)
2016-05-18 16:10:37 7f03be9ba700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 7 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 126 srv_active, 0 srv_shutdown, 3047 srv_idle
srv_master_thread log flush and writes: 3173
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 2408
OS WAIT ARRAY INFO: signal count 2525
Mutex spin waits 988, rounds 24557, OS waits 747
RW-shared spins 1339, rounds 45580, OS waits 1518
RW-excl spins 3, rounds 5283, OS waits 113
Spin rounds per wait: 24.86 mutex, 34.04 RW-shared, 1761.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 7574
Purge done for trx's n:o < 7493 undo n:o < 0 state: running but idle
History list length 778
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 190, OS thread handle 0x7f03be9ba700, query id 3941 localhost root init
SHOW ENGINE INNODB STATUS
---TRANSACTION 7489, not started
MySQL thread id 188, OS thread handle 0x7f03bea3c700, query id 3824 10.0.2.1 root cleaning up
---TRANSACTION 7548, not started
MySQL thread id 1, OS thread handle 0x7f03bea7d700, query id 3855 10.0.2.1 root Waiting for table metadata lock
TRUNCATE TABLE `capability`
---TRANSACTION 7490, ACTIVE 3047 sec
MySQL thread id 189, OS thread handle 0x7f03be9fb700, query id 3840 10.0.2.1 root cleaning up
Trx read view will not see trx with id >= 7491, sees < 7491
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
173 OS file reads, 6858 OS file writes, 6022 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276671, node heap has 2 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 10549488
Log flushed up to 10549488
Pages flushed up to 10549488
Last checkpoint at 10549488
0 pending log writes, 0 pending chkp writes
2555 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 545426
Buffer pool size 8191
Free buffers 7354
Database pages 835
Old database pages 288
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 4257, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 160, created 4341, written 863
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 835, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 1, id 139654053570304, state: sleeping
Number of rows inserted 1187, updated 37, deleted 0, read 650
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
Now my question is, why TRUNCATE table would get stuck on table metalock? And how can this be resolved?
The problem here seems straightforward enough.
---TRANSACTION 7490, ACTIVE 3047 sec
MySQL thread id 189, OS thread handle 0x7f03be9fb700, query id 3840 10.0.2.1 root cleaning up
Trx read view will not see trx with id >= 7491, sees < 7491
---
Thread 189 (a client connection) is idle, and as been for a while, but it has left a transaction running. This is probably a bug in the code that's using the database, since it doesn't make sense to leave a running transaction going for almost an hour.
mysql> KILL 189;
That should release the metadata lock... but you need to find out why this is happening. Bad Things™ will happen if an application doesn't behave better than this.
Also... your application should not be connecting as root. Not related to the problem, but not good, if that's what this is.
The question is already well answered by #Michael - sqlbot but I want to add some additional details. You can look through it why thread id 189 is waiting for this long.
The Waiting for table metadata lock may occur when we DELETE or CREATE an index and modify the table’s structure.
It can also occur when we perform maintenance operations on tables, DELETE tables, or try to access the WRITE lock on table-level (using this query LOCK TABLE table_name WRITE;).
Different types of active transactions can lead to metadata lock waits. Some cases are listed below where the metadata lock wait can occur.
Query to a table that has been present for a long period.
Failed to COMMIT or ROLLBACK the transaction opened implicitly or explicitly.
When we have an unsuccessful query transaction on a table.
Truncate lock bug can also occur if you have a large buffer pool, you may have noticed a complete server lock-up or stall of multiple seconds. You can find more information how this bug occur in this MySQL troubleshooting article.

Slow update/delete on InnoDB table

There is an InnoDB table:
id PRIMARY AI
id2 INDEX varchar
data LONGTEXT - contains 100k to 5 MB of text
mark_for_delete TINYINT
NUM ROWS = approx. 25000
SIZE=1.7G
MySQL 5.5
UPDATE table SET data='longtext here' WHERE id2=5
works fast
UPDATE table SET mark_for_delete=1 WHERE id2=5
works for 40 seconds
DELETE FROM table WHERE id2=5
works for 40 seconds
Deleting several rows takes the same time.
The disk reads data at a rate of 40Mb/s while executing last two queries.
How can I speed up updates and deletes?
Added from comment:
CREATE TABLE b.table (
id INT( 11 ) NOT NULL AUTO_INCREMENT ,
TradeCardId VARCHAR( 255 ) NOT NULL ,
TradeCardHTML LONGTEXT NOT NULL ,
MarkForDelete TINYINT( 4 ) NOT NULL DEFAULT '0',
PRIMARY KEY ( id ) ,
KEY TradeCardId ( TradeCardId )
) ENGINE = INNODB DEFAULT CHARSET = utf8;
INNODB SHOW STATUS while running a slow query:
=====================================
150712 4:51:15 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 28 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 1172 1_second, 1172 sleeps, 113 10_second, 56 background, 56 flush
srv_master_thread log flush and writes: 1224
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 921, signal count 923
Mutex spin waits 1470, rounds 11716, OS waits 206
RW-shared spins 645, rounds 18932, OS waits 569
RW-excl spins 5, rounds 4309, OS waits 142
Spin rounds per wait: 7.97 mutex, 29.35 RW-shared, 861.80 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 7B100A
Purge done for trx's n:o < 7B1006 undo n:o < 0
History list length 2752
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 411, OS thread handle 0x29fc, query id 62926 localhost 127.0.0.1 root
SHOW ENGINE INNODB STATUS
---TRANSACTION 7B05CE, not started
MySQL thread id 269, OS thread handle 0xf6c, query id 58184 localhost 127.0.0.1 root
---TRANSACTION 7AEA37, not started
MySQL thread id 268, OS thread handle 0x142c, query id 45581 localhost 127.0.0.1 root
---TRANSACTION 7B0FF6, not started
MySQL thread id 267, OS thread handle 0x1cc, query id 62861 localhost 127.0.0.1 root
---TRANSACTION 7AE808, not started
MySQL thread id 266, OS thread handle 0xa84, query id 44520 localhost 127.0.0.1 root
---TRANSACTION 7AEBF1, not started
MySQL thread id 133, OS thread handle 0x24ac, query id 46431 localhost 127.0.0.1 root
---TRANSACTION 7ACEE4, not started
MySQL thread id 116, OS thread handle 0x1970, query id 32435 localhost 127.0.0.1 root
---TRANSACTION 7AD73D, not started
MySQL thread id 85, OS thread handle 0xfb8, query id 36383 localhost 127.0.0.1 root
---TRANSACTION 7AEA14, not started
MySQL thread id 84, OS thread handle 0x2b10, query id 45519 localhost 127.0.0.1 root
---TRANSACTION 7ACEC0, not started
MySQL thread id 83, OS thread handle 0x17e8, query id 32180 localhost 127.0.0.1 root
---TRANSACTION 7AD7A5, not started
MySQL thread id 81, OS thread handle 0x2900, query id 36585 localhost 127.0.0.1 root
---TRANSACTION 7AF77F, not started
MySQL thread id 56, OS thread handle 0x1a1c, query id 51611 localhost 127.0.0.1 root
---TRANSACTION 7ACEA2, not started
MySQL thread id 3, OS thread handle 0x2080, query id 31915 localhost 127.0.0.1 root
---TRANSACTION 7B069A, not started
MySQL thread id 2, OS thread handle 0x2a2c, query id 58548 localhost 127.0.0.1 root
---TRANSACTION 7A5300, not started
MySQL thread id 1, OS thread handle 0x2188, query id 3 localhost 127.0.0.1 root
---TRANSACTION 7B1009, ACTIVE 42 sec fetching rows
mysql tables in use 1, locked 1
277 lock struct(s), heap size 27968, 5127 row lock(s)
MySQL thread id 82, OS thread handle 0x21c8, query id 62893 localhost 127.0.0.1 root updating
DELETE FROM `tradecards_raw` WHERE `TradeCardId`=430931
--------
FILE I/O
--------
I/O thread 0 state: wait Windows aio (insert buffer thread)
I/O thread 1 state: wait Windows aio (log thread)
I/O thread 2 state: wait Windows aio (read thread)
I/O thread 3 state: wait Windows aio (read thread)
I/O thread 4 state: wait Windows aio (read thread)
I/O thread 5 state: wait Windows aio (read thread)
I/O thread 6 state: wait Windows aio (write thread)
I/O thread 7 state: wait Windows aio (write thread)
I/O thread 8 state: wait Windows aio (write thread)
I/O thread 9 state: wait Windows aio (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 1
Pending flushes (fsync) log: 0; buffer pool: 0
295450 OS file reads, 69254 OS file writes, 3663 OS fsyncs
375.38 reads/s, 16384 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 5, seg size 7, 4 merges
merged operations:
insert 29, delete mark 2, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 4425293, node heap has 1 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 16969722405
Log flushed up to 16969722405
Last checkpoint at 16969722405
0 pending log writes, 0 pending chkp writes
41513 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 1087897600; in additional pool allocated 0
Dictionary memory allocated 28146
Buffer pool size 65536
Free buffers 0
Database pages 65534
Old database pages 24171
Modified db pages 0
Pending reads 1
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 261024, not young 0
375.34 youngs/s, 0.00 non-youngs/s
Pages read 295310, created 13003, written 26379
375.34 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 555 / 1000, young-making rate 445 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 370.24/s, Random read ahead 0.00/s
LRU len: 65534, unzip_LRU len: 0
I/O sum[20617]:cur[77], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread id 2256, state: waiting for server activity
Number of rows inserted 37683, updated 2503, deleted 65762, read 18023414
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 92.46 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
Which ENGINE? (Please provide full SHOW CREATE TABLE.) It sounds like you are using MyISAM. If so read on. (If InnoDB, I am surprised at the 40 seconds.)
This may be a case where you should use "vertical partitioning". That is, put the LONGTEXT in a parallel table with the same primary key. When SELECTing data..., use a JOIN. When marking for delete, you don't need to touch the second table. The other two queries would need a JOIN, but still might be faster.
Edit
Since id2 is VARCHAR, change id2=5 to id2="5" to keep it from converting to numeric.

Mysql - query is slow when IO on linux server wait is high

Slow query when IO wait is high.
Show from iotop command
-- TID -- PRIO -- USER -- DISK READ -- DISK WRITE -- SWAPIN -- IO> -- COMMAND
-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.25% -- mysql~l.sock
-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.25% -- mysql~l.sock
-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.24% -- mysql~l.sock
High IO wait start when 6:13:28 PM - 6:13:29 PM (sar command)
--------------------- CPU -- %usr -- %nice -- %sys -- %iowait -- %steal
-- 6:13:28 PM --- all ----- 2.53 --- 0.00 ---- 2.02 ----- 39.39 ------ 0.00
-- 6:13:29 PM --- all ----- 1.99 --- 0.00 ---- 1.00 ----- 49.25 ------ 0.00
Got slow query between that time
Time: 130329 18:13:29
User#Host: wdwdwd[wdwdwd] # localhost []
Query_time: 2.007902 Lock_time: 0.000025 Rows_sent: 0 Rows_examined: 1 SET timestamp=1364555609;
UPDATE log_product SET credit=credit+1 WHERE id_product='349721228' and id_user='2021841' LIMIT 1;
## Question are How to fix this process. What the real cause ? ##
Do you have an index on the "Log_Product" table by (id_user, id_product) as a single index, not TWO indexes, one by each column. Also, if the fields are numeric, you don't need quotes...

SELECT ... FOR UPDATE locking trouble when applied on date range

I'm having following table structure.
reservation: (InnoDB)
------------------------------------------
id INT,
date DATE,
item_id INT,
slot VARCHAR(50);
PRIMARY KEY(id), UNIQUE KEY(item_id,date).
Now i'm trying to use SELECT.....FOR UPDATE on reservation table inside a transaction to lock specific rows within date range(eg:2012-06-15 to 2012-06-16) of a particular item_id.
SELECT availability FROM reservation WHERE item_id={$item_id} AND (date>='{$to_date}' AND date<='{$from_date}') FOR UPDATE
NOW when i use the above statement, it is blocking all the rows of particular item_id even beyond the date range.I'm also using this UNIQUE KEY(item_id,date).
How to lock only particular date range of a specific item_id?
regards,
ravi.
ADDED:
|
=====================================
120615 20:14:13 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 24 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 12, signal count 12
Mutex spin waits 0, rounds 180, OS waits 4
RW-shared spins 10, OS waits 5; RW-excl spins 2, OS waits 2
------------
TRANSACTIONS
------------
Trx id counter 0 15147
Purge done for trx's n:o < 0 15136 undo n:o < 0 0
History list length 2
Total number of lock structs in row lock hash table 2
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, OS thread id 2940
MySQL thread id 76, query id 1487 localhost 127.0.0.1 root
SHOW innodb status
---TRANSACTION 0 15143, not started, OS thread id 2588
MySQL thread id 10, query id 578 localhost 127.0.0.1 root
---TRANSACTION 0 15144, ACTIVE 11526 sec, OS thread id 2740
3 lock struct(s), heap size 320
MySQL thread id 11, query id 577 localhost 127.0.0.1 root
--------
FILE I/O
--------
I/O thread 0 state: wait Windows aio (insert buffer thread)
I/O thread 1 state: wait Windows aio (log thread)
I/O thread 2 state: wait Windows aio (read thread)
I/O thread 3 state: wait Windows aio (write thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
187 OS file reads, 75 OS file writes, 29 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 62383, used cells 0, node heap has 1 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 0 8287163
Log flushed up to 0 8287163
Last checkpoint at 0 8287163
0 pending log writes, 0 pending chkp writes
24 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 23277934; in additional pool allocated 1430400
Buffer pool size 960
Free buffers 895
Database pages 64
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 64, created 0, written 51
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread id 1544, state: waiting for server activity
Number of rows inserted 10, updated 0, deleted 0, read 66
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
|