UnInvertedField.getUnInvertedField() 上的多个阻塞线程SegmentReader$CoreReaders.getTermsReader

发布于 2024-10-18 11:43:42 字数 5045 浏览 6 评论 0 原文

我们正在从 Solr 1.3 升级到 Solr 1.4.1。 在使用 Solr 1.3 时,我们在“org.apache.lucene.store.FSDirectory$FSIndexInput.readInternal()”上看到多个阻塞活动线程。

为了利用 NIO 的优势,在升级到 Solr 1.4.1 时,我们在“org.apache.solr.request.UnInvertedField.getUnInvertedField() &

SegmentReader$CoreReaders.getTermsReader”上看到其他类型的多阻塞线程。 因此,QTimes 从几百毫秒增加到几千毫秒……单个查询甚至达到 30-40 秒。

  • 在数千次查询后会出现多个阻塞线程。
  • 我们没有对同一字段进行分面和排序。
  • 我们的构面字段是多值文本字段,但不存在大文本值。
  • 索引大小 - 大约 10 GB
  • 我们没有在 schema.xml 中指定任何分面方法。
  • 我们的字段值缓存设置是:

有人可以告诉我们为什么我们会看到这些被阻止的线程吗?

另外,如果它们与我们的字段值缓存相关,那么大小为 175 的缓存将被很少的初始查询填满,之后我们应该会看到多个阻塞线程?

如果我们有“facet.method = enum”会有什么不同?

这一切都与 fieldValueCache 有关吗?还是我们需要设置一些其他配置来避免这些阻塞线程?

谢谢,

Rachita

缓存值示例:

facetField1_27443:
{field=facet1_27443,memSize=4214884,tindexSize=52,time=22,phase1=15,nTerms=4,bigTerms=0,termInstances=6,uses=1}

facetField1_70:
{field=facetField1_70,memSize=4223310,tindexSize=308,时间=28,phase1=21,nTerms=636,bigTerms=0,termInstances=14404,uses=1}

facetField2:{field=facetField2,memSize=4262644,tindexSize= 3156,time=273,phase1=267,nTerms=12188,bigTerms=0,termInstances=1255522,uses=7031}

“org.apache.solr.request.UnInvertedField.getUnInvertedField() - BLOCKED”的堆栈跟踪< /strong>

在 org.apache.solr.request.UnInvertedField.getUnInvertedField (UnInvertedField.java:837) 在 org.apache.solr.request.SimpleFacets.getTermCounts (SimpleFacets.java:250) 在 org.apache.solr.request.SimpleFacets.getFacetFieldCounts (SimpleFacets.java:283) 在 org.apache.solr.request.SimpleFacets.getFacetCounts (SimpleFacets.java:166) 在 org.apache.solr.handler.component.FacetComponent.process (FacetComponent.java:72) 在 org.apache.solr.handler.component.SearchHandler.handleRequestBody (SearchHandler.java:195) 在 org.apache.solr.handler.RequestHandlerBase.handleRequest (RequestHandlerBase.java:131) 在 org.apache.solr.core.SolrCore.execute (SolrCore.java:1316) 在 org.apache.solr.servlet.SolrDispatchFilter.execute (SolrDispatchFilter.java:338) 在 org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:241) 在 com.caucho.server.dispatch.FilterFilterChain.doFilter (FilterFilterChain.java:87) 在 com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.java:187) 在 com.caucho.server.dispatch.ServletInitation.service (ServletInitation.java:266) 在 com.caucho.server.http.HttpRequest.handleRequest (HttpRequest.java:270) 在 com.caucho.server.port.TcpConnection.run (TcpConnection.java:678) 在 com.caucho.util.ThreadPool$Item.runTasks (ThreadPool.java:721) 在 com.caucho.util.ThreadPool$Item.run (ThreadPool.java:643) 在 java.lang.Thread.run (Thread.java:595)

org.apache.lucene.index.SegmentReader$CoreReaders.getTermsReader() - 被阻止

在 org.apache.lucene.index.SegmentReader$ CoreReaders.getTermsReader (SegmentReader.java:170) 位于 org.apache.lucene.index.SegmentTermDocs。 (SegmentTermDocs.java:52) 在 org.apache.lucene.index.SegmentReader.termDocs (SegmentReader.java:987) 在 org.apache.lucene.index.IndexReader.termDocs (IndexReader.java:1102) 在 org.apache.lucene.index.SegmentReader.termDocs (SegmentReader.java:981) 在 org.apache.solr.search.SolrIndexReader.termDocs (SolrIndexReader.java:320) 在 org.apache.solr.search.SolrIndexSearcher.getDocSetNC (SolrIndexSearcher.java:640) 在 org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet (SolrIndexSearcher.java:563) 在 org.apache.solr.search.SolrIndexSearcher.numDocs (SolrIndexSearcher.java:1422) 在 com.askme.solrenhancements.facet.ExtendedFacet.getCustomFacetCount (ExtendedFacet.java:132) 在 com.askme.solrenhancements.facet.ExtendedFacet.getCustomFacetCount (ExtendedFacet.java:92) 在 com.askme.solrenhancements.facet.ExtendedFacet.getFacetAdditionalInfo (ExtendedFacet.java:69) 在 com.askme.solrenhancements.facet.ExtendedFacet.getFacetInfo (ExtendedFacet.java:56) 在 com.askme.solrenhancements.facet.CustomFacetComponent.process (CustomFacetComponent.java:43) 在 org.apache.solr.handler.component.SearchHandler.handleRequestBody (SearchHandler.java:195) 在 org.apache.solr.handler.RequestHandlerBase.handleRequest (RequestHandlerBase.java:131) 在 org.apache.solr.core.SolrCore.execute (SolrCore.java:1316) 在 org.apache.solr.servlet.SolrDispatchFilter.execute (SolrDispatchFilter.java:338) 在 org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:241) 在 com.caucho.server.dispatch.FilterFilterChain.doFilter (FilterFilterChain.java:87) 在 com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.java:187) 在 com.caucho.server.dispatch.ServletInitation.service (ServletInitation.java:266) 在 com.caucho.server.http.HttpRequest.handleRequest (HttpRequest.java:270) 在 com.caucho.server.port.TcpConnection.run (TcpConnection.java:678) 在 com.caucho.util.ThreadPool$Item.runTasks (ThreadPool.java:721) 在 com.caucho.util.ThreadPool$Item.run (ThreadPool.java:643) 在 java.lang.Thread.run (Thread.java:595)

We are upgrading from Solr 1.3 to Solr 1.4.1.
While using Solr 1.3 , we were seeing multiple blocking active threads on "org.apache.lucene.store.FSDirectory$FSIndexInput.readInternal() ".

To utilize the benefits of NIO, on upgrading to Solr 1.4.1, we see other type of multiple blocking threads on "org.apache.solr.request.UnInvertedField.getUnInvertedField() &

SegmentReader$CoreReaders.getTermsReader".
Due to this, the QTimes shoots up from few hundreds to thousand of msec.. even going upto 30-40 secs for a single query.

  • The multiple blocking threads show up after few thousands of queries.
  • We do not have faceting and sorting on the same fields.
  • Our facet fields are multivalued text fields, but no large text values are present.
  • Index size - around 10 GB
  • We have not specified any method for faceting in our schema.xml.
  • Our field value cache settings are:

Can someone please tell us the why we are seeing these blocked threads ?

Also if they are related to our field value cache , then a cache of size 175 will be filled up with very few initial queries and right after that we should see multiple blocking threads ?

What difference it will make if we have "facet.method = enum" ?

Is this all related to fieldValueCache or is there some other configuration which we need to set to avoid these blocking threads?

Thanks,

Rachita

Cache values example:

facetField1_27443 :
{field=facet1_27443,memSize=4214884,tindexSize=52,time=22,phase1=15,nTerms=4,bigTerms=0,termInstances=6,uses=1}

facetField1_70 :
{field=facetField1_70,memSize=4223310,tindexSize=308,time=28,phase1=21,nTerms=636,bigTerms=0,termInstances=14404,uses=1}

facetField2 : {field=facetField2,memSize=4262644,tindexSize=3156,time=273,phase1=267,nTerms=12188,bigTerms=0,termInstances=1255522,uses=7031}

Stack trace for "org.apache.solr.request.UnInvertedField.getUnInvertedField() - BLOCKED"

at org.apache.solr.request.UnInvertedField.getUnInvertedField (UnInvertedField.java:837)
at org.apache.solr.request.SimpleFacets.getTermCounts (SimpleFacets.java:250)
at org.apache.solr.request.SimpleFacets.getFacetFieldCounts (SimpleFacets.java:283)
at org.apache.solr.request.SimpleFacets.getFacetCounts (SimpleFacets.java:166)
at org.apache.solr.handler.component.FacetComponent.process (FacetComponent.java:72)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody (SearchHandler.java:195)
at org.apache.solr.handler.RequestHandlerBase.handleRequest (RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute (SolrCore.java:1316)
at org.apache.solr.servlet.SolrDispatchFilter.execute (SolrDispatchFilter.java:338)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:241)
at com.caucho.server.dispatch.FilterFilterChain.doFilter (FilterFilterChain.java:87)
at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.java:187)
at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.java:266)
at com.caucho.server.http.HttpRequest.handleRequest (HttpRequest.java:270)
at com.caucho.server.port.TcpConnection.run (TcpConnection.java:678)
at com.caucho.util.ThreadPool$Item.runTasks (ThreadPool.java:721)
at com.caucho.util.ThreadPool$Item.run (ThreadPool.java:643)
at java.lang.Thread.run (Thread.java:595)

org.apache.lucene.index.SegmentReader$CoreReaders.getTermsReader() - BLOCKED

at org.apache.lucene.index.SegmentReader$CoreReaders.getTermsReader (SegmentReader.java:170)
at org.apache.lucene.index.SegmentTermDocs. (SegmentTermDocs.java:52)
at org.apache.lucene.index.SegmentReader.termDocs (SegmentReader.java:987)
at org.apache.lucene.index.IndexReader.termDocs (IndexReader.java:1102)
at org.apache.lucene.index.SegmentReader.termDocs (SegmentReader.java:981)
at org.apache.solr.search.SolrIndexReader.termDocs (SolrIndexReader.java:320)
at org.apache.solr.search.SolrIndexSearcher.getDocSetNC (SolrIndexSearcher.java:640)
at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet (SolrIndexSearcher.java:563)
at org.apache.solr.search.SolrIndexSearcher.numDocs (SolrIndexSearcher.java:1422)
at com.askme.solrenhancements.facet.ExtendedFacet.getCustomFacetCount (ExtendedFacet.java:132)
at com.askme.solrenhancements.facet.ExtendedFacet.getCustomFacetCount (ExtendedFacet.java:92)
at com.askme.solrenhancements.facet.ExtendedFacet.getFacetAdditionalInfo (ExtendedFacet.java:69)
at com.askme.solrenhancements.facet.ExtendedFacet.getFacetInfo (ExtendedFacet.java:56)
at com.askme.solrenhancements.facet.CustomFacetComponent.process (CustomFacetComponent.java:43)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody (SearchHandler.java:195)
at org.apache.solr.handler.RequestHandlerBase.handleRequest (RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute (SolrCore.java:1316)
at org.apache.solr.servlet.SolrDispatchFilter.execute (SolrDispatchFilter.java:338)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:241)
at com.caucho.server.dispatch.FilterFilterChain.doFilter (FilterFilterChain.java:87)
at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.java:187)
at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.java:266)
at com.caucho.server.http.HttpRequest.handleRequest (HttpRequest.java:270)
at com.caucho.server.port.TcpConnection.run (TcpConnection.java:678)
at com.caucho.util.ThreadPool$Item.runTasks (ThreadPool.java:721)
at com.caucho.util.ThreadPool$Item.run (ThreadPool.java:643)
at java.lang.Thread.run (Thread.java:595)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

断桥再见 2024-10-25 11:43:42

我在测试中也遇到了这个问题。我发现以下代码附近的块很有趣:

SimpleFSDirectory.readInternal

protected void readInternal(byte[] b, int offset, int len)
     throws IOException {
  synchronized (file) {
    long position = getFilePointer();
    if (position != file.position) {
      file.seek(position);
      file.position = position;
    }
    int total = 0;

    try {
      do {
        final int readLength;
        if (total + chunkSize > len) {
          readLength = len - total;
        } else {
          // LUCENE-1566 - work around JVM Bug by breaking very large reads into chunks
          readLength = chunkSize;
        }
        final int i = file.read(b, offset + total, readLength);
        if (i == -1) {
          throw new IOException("read past EOF");
        }
        file.position += i;
        total += i;
      } while (total < len);
    } catch (OutOfMemoryError e) {
      // propagate OOM up and add a hint for 32bit VM Users hitting the bug
      // with a large chunk size in the fast path.
      final OutOfMemoryError outOfMemoryError = new OutOfMemoryError(
          "OutOfMemoryError likely caused by the Sun VM Bug described in "
          + "https://issues.apache.org/jira/browse/LUCENE-1566; try calling FSDirectory.setReadChunkSize "
          + "with a a value smaller than the current chunks size (" + chunkSize + ")");
      outOfMemoryError.initCause(e);
      throw outOfMemoryError;
    }
  }
}

我猜你的 solr 是在 Windows 上构建的,就像我一样。您可以使用以下帖子中的“代码补丁”: 使用NIO位置读取以避免FSIndexInput中的同步

I have met this problem in my test as well. I found the block near following code is interesting:

SimpleFSDirectory.readInternal

protected void readInternal(byte[] b, int offset, int len)
     throws IOException {
  synchronized (file) {
    long position = getFilePointer();
    if (position != file.position) {
      file.seek(position);
      file.position = position;
    }
    int total = 0;

    try {
      do {
        final int readLength;
        if (total + chunkSize > len) {
          readLength = len - total;
        } else {
          // LUCENE-1566 - work around JVM Bug by breaking very large reads into chunks
          readLength = chunkSize;
        }
        final int i = file.read(b, offset + total, readLength);
        if (i == -1) {
          throw new IOException("read past EOF");
        }
        file.position += i;
        total += i;
      } while (total < len);
    } catch (OutOfMemoryError e) {
      // propagate OOM up and add a hint for 32bit VM Users hitting the bug
      // with a large chunk size in the fast path.
      final OutOfMemoryError outOfMemoryError = new OutOfMemoryError(
          "OutOfMemoryError likely caused by the Sun VM Bug described in "
          + "https://issues.apache.org/jira/browse/LUCENE-1566; try calling FSDirectory.setReadChunkSize "
          + "with a a value smaller than the current chunks size (" + chunkSize + ")");
      outOfMemoryError.initCause(e);
      throw outOfMemoryError;
    }
  }
}

I guess your solr is built at windows as I did. You can use the "code patch" in the following post: Use NIO positional read to avoid synchronization in FSIndexInput

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文