“查询结束"在随机时间步长很长 [英] "query end" step very long at random times

问题描述

我正在对一个Web应用程序进行基准测试，大约有1％的查询出现了问题，大部分是UPDATES(但有时是INSERT).我对这些请求进行了分析，看来这是查询结束步骤需要花费很多时间.

I'm benchmarking a web application, and I have a problem that occurs on about 1% of my queries, mostly UPDATES (but also sometimes INSERT). I did a profiling on those requests and it seems it's the query end step that takes a lot of time.

starting  0.000029
checking permissions  0.000005
Opening tables    0.000017
System lock   0.000005
init  0.000032
Updating  0.000052
end   0.000030
**query end   1.825892**
closing tables    0.000025
freeing items 0.000020
logging slow query    0.000007
logging slow query    0.000029
cleaning up   0.000008

当我浏览文档时

end:这发生在结束但清除ALTER TABLE，CREATE VIEW，DELETE，INSERT，SELECT或UPDATE语句之前.

end : This occurs at the end but before the cleanup of ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT, or UPDATE statements.

查询结束:此状态在处理查询之后但在释放项目状态之前发生.

query end : This state occurs after processing a query but before the freeing items state.

那么这是否意味着我的UPDATE清理需要时间? 该步骤到底要做什么，我该如何提高性能?

So does this mean the cleanup of my UPDATE is taking time ? What does this step do exactly, how can I improve the performances ?

谢谢

推荐答案

添加问题已解决

innodb_flush_log_at_trx_commit = 0

/etc/my.cnf中的

in the /etc/my.cnf

当多个线程要同时写入文件时，存在一个互锁问题，这样日志将每秒刷新一次.

There is an interlocking problem when multiple threads want to write the file at the same time, this way the log will be flushed every second.

这篇关于“查询结束"在随机时间步长很长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！