docprocservice和容器上的频繁GC

时间：2018-04-10 12:07:47

标签： vespa

我正在针对vespa运行性能测试，容器看起来很慢，无法处理传入的更多请求。看看vespa.log，有很多GC分配失败日志。但是，系统资源非常低（CPU <30％，内存<35％）。有优化配置吗？

顺便说一下，默认情况下docprocservice正在内容节点上运行，如何调整docprocservice的jvmargs？

1523361302.261056        24298   container       stdout  info    [GC (Allocation Failure)  3681916K->319796K(7969216K), 0.0521448 secs]
1523361302.772183        24301   docprocservice  stdout  info    [GC (Allocation Failure)  729622K->100400K(1494272K), 0.0058702 secs]
1523361306.478681        24301   docprocservice  stdout  info    [GC (Allocation Failure)  729648K->99337K(1494272K), 0.0071413 secs]
1523361308.275909        24298   container       stdout  info    [GC (Allocation Failure)  3675316K->325043K(7969216K), 0.0669859 secs]
1523361309.798619        24301   docprocservice  stdout  info    [GC (Allocation Failure)  728585K->100538K(1494272K), 0.0060528 secs]
1523361313.530767        24301   docprocservice  stdout  info    [GC (Allocation Failure)  729786K->100561K(1494272K), 0.0088941 secs]
1523361314.549254        24298   container       stdout  info    [GC (Allocation Failure)  3680563K->330211K(7969216K), 0.0531680 secs]
1523361317.571889        24301   docprocservice  stdout  info    [GC (Allocation Failure)  729809K->100551K(1494272K), 0.0062653 secs]
1523361320.736348        24298   container       stdout  info    [GC (Allocation Failure)  3685729K->316908K(7969216K), 0.0595787 secs]
1523361320.839502        24301   docprocservice  stdout  info    [GC (Allocation Failure)  729799K->99311K(1494272K), 0.0069882 secs]
1523361324.948995        24301   docprocservice  stdout  info    [GC (Allocation Failure)  728559K->99139K(1494272K), 0.0127939 secs]

services.xml:
<container id="container" version="1.0">                                                                                               
    <config name="container.handler.threadpool">                                                                                         
        <maxthreads>10000</maxthreads>                                                                                                   
    </config>                                                                                                                            

    <config name="config.docproc.docproc">                                                                                               
      <numthreads>500</numthreads>                                                                                                      
    </config>                                                                                                                            

    <config name="search.config.qr-start">                                                                                               
      <jvm>                                                                                                                              
        <heapSizeAsPercentageOfPhysicalMemory>60</heapSizeAsPercentageOfPhysicalMemory>                                                  
      </jvm>                                                                                                                             
    </config>                                                                                                                            
    <document-api />                                                                                                                     

    <search>                                                                                                                             
        <provider id="music" cluster="music" cachesize="64M" type="local" />                                                           
    </search>                                                                                                                            

    <nodes>                                                                                                                              
      <node hostalias="admin0" />                                                                                                        
      <node hostalias="node2" />                                                                                                         
    </nodes>                                                                                                                             
  </container>   

# free -lh
              total        used        free      shared  buff/cache   available
Mem:           125G         43G         18G        177M         63G         80G
Low:           125G        106G         18G
High:            0B          0B          0B
Swap:            0B          0B          0B

2 个答案:

答案 0 :(得分：2)

这些GC消息来自jvm并且是正常的而不是真正的故障。它只是JVM的工作方式，收集应用程序创建的垃圾，所有这些都是年轻一代的小集合。如果您开始看到完整的GC消息，则需要进行调整。

＆＃39; docprocservice＆＃39;不参与搜索服务，因此您可以安全地忽略那些服务测试。很可能你的瓶颈是底层内容层。那里的资源使用情况如何？  无论如何，使用10K maxthreads运行似乎过多，默认500就足够了 - 你使用什么样的基准测试客户端？

答案 1 :(得分：1)

通常，如果您提供

，它会更容易提供帮助
  • 设置和硬件配置（例如services.xml和文档架构）
  • 正在使用哪种类型的查询/排名配置文件，字段搜索等。文档总数以及使用自定义排名配置文件时，结果与使用内置“未排名”的排名相比如何？排名档案。
  • 返回的平均点击次数（＆amp; hits = x）参数和平均总点击次数
  • 资源使用情况（例如，当延迟开始超过目标延迟SLA（达到瓶颈/最大吞吐量）时，来自容器和内容节点的vmstat / top / network util
  • 与上面相同，但只有一个客户端（没有并发）。如果您已经超过目标延迟SLA /期望而没有并发，则可能必须检查正在使用的功能（示例将添加排名：过滤到未排名的字段，将快速搜索添加到查询中涉及的属性等）< / LI>
  • 对使用的客户进行基准测试（例如，使用的连接数和参数）。我们通常使用vespa-fbench工具。

关于基准测试的一些一般资源＆amp;剖析Vespa

相关问题
最新问题