请教一个mysql innodb故障信息怀疑是死锁引起的

black-hat

mysql> show processlist;
+-------+--------+---------------------+--------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| Id    | User   | Host                | db     | Command | Time | State        | Info                                                                                                 |
+-------+--------+---------------------+--------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
|   955 | cdn | 62.55.168.99:42065   | cdn | Query   |  292 | updating     | DELETE FROM tasklist WHERE target = '05lqgfm2pbu5ztk3qw3hu2lsjfr_29804 |
|   956 | cdn | 62.55.168.99:42066   | cdn | Query   |  292 | updating     | DELETE FROM tasklist WHERE target = '05lqgfm2pbu5ztk3qw3hu2lsjfr_29804|
|   957 | cdn | 62.55.168.99:42067   | cdn | Query   |  292 | updating     | DELETE FROM tasklist WHERE target = '05lqgfm2pbu5ztk3qw3hu2lsjfr_29804|
|   968 | cdn | 62.55.168.4:58026   | cdn | Query   |  292 | updating     | DELETE FROM tasklist WHERE target = '05lqgfm2pbu5ztk3qw3hu2lsjfr_29804|
|   969 | cdn | 62.55.168.4:58027   | cdn | Query   |  292 | updating     | DELETE FROM tasklist WHERE target = '05lqgfm2pbu5ztk3qw3hu2lsjfr_29804|
|   970 | cdn | 62.55.168.4:58028   | cdn | Query   |  292 | updating     | DELETE FROM tasklist WHERE target = '05lqgfm2pbu5ztk3qw3hu2lsjfr_29804|
|   981 | cdn | 62.55.168.16:34426  | cdn | Query   |  291 | updating     | DELETE FROM tasklist WHERE target = 05lqgfm2pbu5ztk3qw3hu2lsjfr_29804 |
|   982 | cdn | 62.55.168.16:34427  | cdn | Query   |  291 | updating     | DELETE FROM tasklist WHERE target = 05lqgfm2pbu5ztk3qw3hu2lsjfr_29804|

上面是服务器在故障时重启mysqld后登录进去查询到的部分数据，程序上每次启动了3个连接mysql的线程。
程序里面看的出来执行都是并发的，不知道这样会不会出现死锁情况。

系统环境： centos 5.3  x86_64
mysql 版本：mysql  Ver 14.12 Distrib 5.0.77, for redhat-linux-gnu (x86_64) using readline 5.1
使用的存储引擎：innodb
当时并发执行delete 的时候有45个。
下面是出现故障时查看到的mysql log数据。
110424  1:41:43InnoDB: Warning: difficult to find free blocks from
InnoDB: the buffer pool (1490 search iterations)! Consider
InnoDB: increasing the buffer pool size.
InnoDB: It is also possible that in your Unix version
InnoDB: fsync is very slow, or completely frozen inside
InnoDB: the OS kernel. Then upgrading to a newer version
InnoDB: of your operating system may help. Look at the
InnoDB: number of fsyncs in diagnostic info below.
InnoDB: Pending flushes (fsync) log: 0; buffer pool: 0
InnoDB: 804605 OS file reads, 101251 OS file writes, 52133 OS fsyncs
InnoDB: Starting InnoDB Monitor to print further
InnoDB: diagnostics to the standard output.
110424  1:41:43InnoDB: Warning: difficult to find free blocks from
InnoDB: the buffer pool (816 search iterations)! Consider
InnoDB: increasing the buffer pool size.
InnoDB: It is also possible that in your Unix version
InnoDB: fsync is very slow, or completely frozen inside
InnoDB: the OS kernel. Then upgrading to a newer version
InnoDB: of your operating system may help. Look at the
InnoDB: number of fsyncs in diagnostic info below.
InnoDB: Pending flushes (fsync) log: 0; buffer pool: 0
InnoDB: 804605 OS file reads, 101251 OS file writes, 52133 OS fsyncs
InnoDB: Starting InnoDB Monitor to print further
InnoDB: diagnostics to the standard output.

出现这类故障的时候数据库任何表都不能查，此时系统负载和MYSQLD CPU使用率都不高， 整体CPU使用率也不高基本在0左右，内存情况还有空闲空间，磁盘IO只有少量的读写，系统load 在0点几。
在系统压力不大的时候出现这类故障比较奇怪，请教各位大牛能帮我小弟分析一下。
从日志里面看的出来我的buffer 空间不足，这个我接下在优化一下，但是唯一比较奇怪的是执行少量的delete 会导致数据库阻塞觉得很奇怪。

love100

my.cnf贴出来
不能升级到的5.1？

justlooks

从innodb的代码来看，上述错误是由于innodb无法在LRU队列里无法找到可替换的page导致的，而又没有空闲的页面可以用，导致mysql一直卡在look for free page block的循环
InnoDB: the buffer pool (1490 search iterations)! ，但是目前MYSQL没有占用到磁盘资源

InnoDB: Pending flushes (fsync) log: 0; buffer pool: 0

最后说错了

你提供的信息有限，只能分析到这步了

贴下SHOW ENGINE INNODB STATUS

black-hat

谢谢几位兄弟的点评，由于当时只记录了这些信息，等下次在出现此类故障的时候在记录下innodb的状态。非常感谢。{:2_172:}