带有负载峰值的大型innodb数据库似乎在控制台中导致“任务挂起120秒”的随机崩溃。 在这些崩溃期间没有将日志写入系统。 innodb表是相当大的，存储20 +演出。
在Ubuntu 10.04上使用内核2.6.36和2.6.38-15 64位可能导致表碎片化，导致随机系统崩溃？
我们正在研究随机系统崩溃的问题，这些崩溃运行在“专用baremetal”vps托pipe服务器上托pipe的大型innodb表。
MySQL版本是5.1。
下面是结果：“SELECT data_length，index_length，（data_length + index_length）/ power（1024,3）GB FROM information_schema.tables WHERE ENGINE ='InnoDB'ORDER BY data_length + index_length DESC LIMIT 10;”：
+-------------+--------------+-------------------+ | data_length | index_length | GB | +-------------+--------------+-------------------+ | 14758707200 | 17220501504 | 29.782958984375 | | 9456762880 | 16465543168 | 24.1420288085938 | | 16983785472 | 6954041344 | 22.2938385009766 | | 5625610240 | 2997813248 | 8.03118896484375 | | 3694133248 | 1730150400 | 5.0517578125 | | 2031091712 | 35209216 | 1.92439270019531 | | 1357905920 | 706740224 | 1.9228515625 | | 1107312640 | 320356352 | 1.32962036132812 | | 637534208 | 760889344 | 1.30238342285156 | | 488636416 | 260620288 | 0.697799682617188 | +-------------+--------------+-------------------+ 打开文件= 300。
TIA
看起来你有巨大的桌子
如果你想对InnoDB表mydb.mytable进行碎片整理，只需运行以下命令：
ALTER TABLE mydb.mytable ENGINE=InnoDB;
根据这个问题，它会做到以下几点：
CREATE TABLE mydb.mytablenew LIKE mydb.mytable; INSERT INTO mydb.mytablenew SELECT * mydb.mytable; ALTER TABLE mydb.mytable RENAME mydb.mytableold; ALTER TABLE mydb.mytablenew RENAME mydb.mytable; DROP TABLE mydb.mytableold;
如果你想大规模碎片整理InnoDB表，运行这个：
echo "SET SQL_LOG_BIN = 0;" > /root/DefragInnoDB.sql MYSQL_USER=root MYSQL_PASS=rootpassword MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}" SQL="SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')" SQL="${SQL} FROM information_schema.tables WHERE engine='InnoDB'" mysql ${MYSQL_CONN} -ANe"${SQL}" >> /root/DefragInnoDB.sql mysql ${MYSQL_CONN} -A < /root/DefragInnoDB.sql
你可能不需要经常对InnoDB进行碎片整理。 查看我在DBA StackExchange上的post，以确定是否需要对任何一个InnoDB表进行碎片整理 。
在旁注中，一些表看起来像索引消耗的空间比数据要多。 在这些表上运行碎片整理后，返回查看每个表中的索引。 尝试确定是否有任何未使用的索引，并删除它们。
你有innodb_open_files 300。 你可以提高它，但不要把它设得太高
请参阅innodb_open_files中的以下文章
我还想build议你升级ro MySQL 5.5，在那里你可以提高innodb_read_io_threads和innodb_write_io_threads以提高InnoDB存储引擎的CPU利用率 。
有很多客户访问该数据库或只是几个同时连接？ 有足够的RAM或服务器交换？
您所描述的事情绝对会发生，但这意味着要么是非常繁忙的工作量，要么是非常慢/不可靠的I / O子系统。
你有没有试过bonnie++ ， iozone或其他基准testing工具会给你的服务器带来什么样的性能？