gerrit show-queue命令在Index-Interactive标签下出现好多start:merged一直占用CPU的进程。

[黄zeal]

各位好：

       执行ssh -p 29418 xxxx  gerrit  show-queue -w -q命令的时候，在Queue: Index-Interactive标签下出现好多start:merged状态的进程，这些进程看着像是在做查询的动作，这样的一条进程就直接占用一个核CPU，当出现多个类似

进程的时候，服务器资源就很容易被消耗完。

      对接的jstack log如下：

      Index-Interactive-9

org.apache.lucene.util.PriorityQueue.downHeap(PriorityQueue.java:284)

org.apache.lucene.util.PriorityQueue.updateTop(PriorityQueue.java:211)

org.apache.lucene.search.TopFieldCollector.updateBottom(TopFieldCollector.java:523)

org.apache.lucene.search.TopFieldCollector$SimpleFieldCollector$2.collect(TopFieldCollector.java:243)

org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:221)

org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)

org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)

org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:821)

org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)

org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:744)

org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:729)

org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:671)

org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:577)

org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:627)

com.google.gerrit.lucene.LuceneChangeIndex$QuerySource.doRead(LuceneChangeIndex.java:345)

com.google.gerrit.lucene.LuceneChangeIndex$QuerySource.access$300(LuceneChangeIndex.java:279)

com.google.gerrit.lucene.LuceneChangeIndex$QuerySource$1.call(LuceneChangeIndex.java:325)

com.google.gerrit.lucene.LuceneChangeIndex$QuerySource$1.call(LuceneChangeIndex.java:322)

com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:108)

com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:41)

com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:77)

java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

java.util.concurrent.FutureTask.run(FutureTask.java:266)

java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)

java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)

com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:417)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

java.lang.Thread.run(Thread.java:748)

       

查看了LuceneChangeIndex类里doRead方法，发现是opt.start()  这个值特别大。  start()这个是抽象QueryOptions类里的抽象方法，但是在gerrit源码里没有查到哪个子类进程了增抽象类重写了这个抽象方法。

想从源码去解决这个问题难度有点大。

哪位大佬碰到过类似的问题不？谢谢。

[Chunlin Zhang]

没碰到过这种问题

就是cpu高负载,没有error?

--
您收到此邮件是因为您订阅了Google网上论坛上的“Git中文用户组”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+un...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/b11f5443-6853-46d7-9fc0-881f50228ad5%40googlegroups.com。

[黄zeal]

是的，进程占用CPU不释放，直接把资源全消耗完了。  就是下图这种情况

Chunlin Zhang於 2019年8月26日星期一 UTC+8下午5時17分14秒寫道：

没碰到过这种问题

就是cpu高负载,没有error?

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+unsubscribe@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/b11f5443-6853-46d7-9fc0-881f50228ad5%40googlegroups.com。

[Chunlin Zhang]

建议去gerrit那边报个bug然后在邮件列表里问问

另外可以另拷一份数据做测试环境,然后升个新版本看看能不能重现这个问题

Chunlin Zhang於 2019年8月26日星期一 UTC+8下午5時17分14秒寫道：

没碰到过这种问题

就是cpu高负载,没有error?

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+un...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/b11f5443-6853-46d7-9fc0-881f50228ad5%40googlegroups.com。

--
您收到此邮件是因为您订阅了Google网上论坛上的“Git中文用户组”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+un...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/a569dbbf-3f0a-4762-8e29-9226baba6424%40googlegroups.com。

[黄zeal]

好的

Chunlin Zhang於 2019年8月28日星期三 UTC+8上午9時46分39秒寫道：

建议去gerrit那边报个bug然后在邮件列表里问问

另外可以另拷一份数据做测试环境,然后升个新版本看看能不能重现这个问题

Chunlin Zhang於 2019年8月26日星期一 UTC+8下午5時17分14秒寫道：

没碰到过这种问题

就是cpu高负载,没有error?

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+unsubscribe@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/b11f5443-6853-46d7-9fc0-881f50228ad5%40googlegroups.com。

--
您收到此邮件是因为您订阅了Google网上论坛上的“Git中文用户组”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+unsubscribe@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/a569dbbf-3f0a-4762-8e29-9226baba6424%40googlegroups.com。

[xf zheng]

我们现在也碰到这个问题，可以通过加大内存内存，增加gerrit heaplimit和packedGitLimit来解决。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+un...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/b11f5443-6853-46d7-9fc0-881f50228ad5%40googlegroups.com。

--
您收到此邮件是因为您订阅了Google网上论坛上的“Git中文用户组”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到git123+un...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/a569dbbf-3f0a-4762-8e29-9226baba6424%40googlegroups.com。

[Chunlin Zhang]

发现我也碰上这个问题了，查了好久了还是没头绪，上面说的heapLimit和packedGitLimit已经很大了，但还是会发生。

HTTPS GET threads are not closed even after users close their review page 这个讨论说是lucene一直不返回结果导致的，感觉没有什么规避的办法。

楼上在repo-discuss发的 About the ssh cmd 'gerrit show-queue'这个贴里就一个人说减少index数量看看，估计也没用。

xf zheng <zheng...@gmail.com> 于2021年12月21日周二 09:55写道：

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/git123/13138900-e5f5-48ce-ac58-8076782fe726n%40googlegroups.com。