Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/solr/3.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
mysql连接查询在露天很慢,但使用索引_Mysql_Solr_Alfresco - Fatal编程技术网

mysql连接查询在露天很慢,但使用索引

mysql连接查询在露天很慢,但使用索引,mysql,solr,alfresco,Mysql,Solr,Alfresco,Alfresco 4.0.e和mysql 5.5后端出现了一些性能问题 通过性能监视器,我可以看到很多请求(不确定是什么触发了这些请求)在DB上挂起,响应时间接近100-200秒。在极端情况下是3000秒 所有这些请求都来自本地alfresco应用程序(而不是我们在单独的服务器上共享的gui)。客户端ip显示127.0.0.1。 URL=/alfresco/service/api/solr/metadata 进一步深入研究后,似乎有两个查询需要100多秒的时间,如下所示- select

Alfresco 4.0.e和mysql 5.5后端出现了一些性能问题

通过性能监视器,我可以看到很多请求(不确定是什么触发了这些请求)在DB上挂起,响应时间接近100-200秒。在极端情况下是3000秒

所有这些请求都来自本地alfresco应用程序(而不是我们在单独的服务器上共享的gui)。客户端ip显示127.0.0.1。 URL=/alfresco/service/api/solr/metadata 进一步深入研究后,似乎有两个查询需要100多秒的时间,如下所示-

select
        assoc.id                    as id,
        parentNode.id               as parentNodeId,
        parentNode.version          as parentNodeVersion,
        parentStore.protocol        as parentNodeProtocol,
        parentStore.identifier      as parentNodeIdentifier,
        parentNode.uuid             as parentNodeUuid,
        childNode.id                as childNodeId,
        childNode.version           as childNodeVersion,
        childStore.protocol         as childNodeProtocol,
        childStore.identifier       as childNodeIdentifier,
        childNode.uuid              as childNodeUuid,
        assoc.type_qname_id         as type_qname_id,
        assoc.child_node_name_crc   as child_node_name_crc,
        assoc.child_node_name       as child_node_name,
        assoc.qname_ns_id           as qname_ns_id,
        assoc.qname_localname       as qname_localname,
        assoc.is_primary            as is_primary,
        assoc.assoc_index           as assoc_index
    from
        alf_child_assoc assoc
        join alf_node parentNode on (parentNode.id = assoc.parent_node_id)
        join alf_store parentStore on (parentStore.id = parentNode.store_id)
        join alf_node childNode on (childNode.id = assoc.child_node_id)
        join alf_store childStore on (childStore.id = childNode.store_id)

    where
        parentNode.id = ?
在这个查询上运行一个解释计划,其参数值似乎造成了最大的破坏(~3000秒),下面是我看到的-

    select_type table       type    possible_keys                       key               key_len   ref                       rows  Extra
    SIMPLE      parentNode  const   PRIMARY,store_id,fk_alf_node_store  PRIMARY           8         const                     1 
    SIMPLE      parentStore const   PRIMARY                             PRIMARY           8         const                     1 
    SIMPLE      childStore  index   PRIMARY                             protocol          454       NULL                      6     Using index
    SIMPLE      childNode   ref     PRIMARY,store_id,fk_alf_node_store  store_id          8         alfrescomgr.childStore.id 162579    
    SIMPLE      assoc       ref     parent_node_id,fk_alf_cass_pnode,   fk_alf_cass_cnode 8         alfrescomgr.childNode.id  1     Using where
                                    fk_alf_cass_cnode  
请注意,行数=162k。 对于两个这样的查询,父节点似乎指向一个存储数千个小尺寸报价文档的文件夹

我们的应用程序通过一些元数据属性(如客户id)推送文档并查询它们。我们使用apache chemistry cmis api进行交互

  • 您认为触发solr查询的是什么。它试图在所有子节点上加载信息
  • 如果我们不能控制solr块,我们如何优化它

  • 非常感谢您的帮助。

    不久前,我在Solaris上的一个4.0.d实例(使用MySQL)上遇到了类似的性能问题,结果证明,MySQL版本的默认引擎性能很差


    一旦我为join/where子句中引用的每一列编制了索引,问题就消失了,我获得了98%以上的性能提升

    不久前,我在Solaris上的一个4.0.d实例(使用MySQL)上遇到过类似的性能问题,结果证明我之前使用的MySQL版本的默认引擎性能很差


    一旦我为join/where子句中引用的每一列编制了索引,问题就消失了,我获得了98%以上的性能提升

    我们发现了缓慢背后的两个原因

    • mysql数据库数据卷上的磁盘i/o比其他系统慢得多。我们使用sysbench随机i/o测试来验证这一点
    • 上面讨论的文件夹中有数百万个文档,这似乎导致此查询速度变慢。
      • 我们也不能从共享加载文件夹内容页以显示任何内容(导致与超时相关的错误)
      • 我们计划重新构造此文件夹,使其具有更多子文件夹,以限制每个文件夹中的文档。有迹象表明这会有所帮助,但这样做听起来并不正确。对于将来可能出现的其他类似情况,我们可能无法真正控制
      • 我想知道这是否仍然是Alfresco新版本(比如5.x)的一个限制

    我们发现了缓慢背后的两个原因

    • mysql数据库数据卷上的磁盘i/o比其他系统慢得多。我们使用sysbench随机i/o测试来验证这一点
    • 上面讨论的文件夹中有数百万个文档,这似乎导致此查询速度变慢。
      • 我们也不能从共享加载文件夹内容页以显示任何内容(导致与超时相关的错误)
      • 我们计划重新构造此文件夹,使其具有更多子文件夹,以限制每个文件夹中的文档。有迹象表明这会有所帮助,但这样做听起来并不正确。对于将来可能出现的其他类似情况,我们可能无法真正控制
      • 我想知道这是否仍然是Alfresco新版本(比如5.x)的一个限制

    一般不建议将数千个文件放在Alfresco的一个文件夹中。如果您将文件分到子目录,那么每个分片文件夹中只有几百个文件,会发生什么?而且,现在有点晚了,但是PostGreSQL通常比MySQL工作得更好!谢谢你的意见。子目录是我们正在考虑的事情,但需要找到一种方法,能够将这些文件移动到适当的文件夹中,而不会在生产中造成性能噩梦。我想知道极光会如何工作,尤其是看露天表演。他们在aws论文中发布的基准测试。我想知道社区版是否适合Aurora。如果您从4.0升级到5.0(甚至可能是5.1预览版),您将在不需要移动的情况下获得相当多的性能改进。自从4.0 4年前问世以来,已经做了很多工作!通常不建议将数千个文件放在Alfresco的一个文件夹中。如果您将文件分到子目录,那么每个分片文件夹中只有几百个文件,会发生什么?而且,现在有点晚了,但是PostGreSQL通常比MySQL工作得更好!谢谢你的意见。子目录是我们正在考虑的事情,但需要找到一种方法,能够将这些文件移动到适当的文件夹中,而不会在生产中造成性能噩梦。我想知道极光会如何工作,尤其是看露天表演。他们在aws论文中发布的基准测试。我想知道社区版是否适合Aurora。如果您从4.0升级到5.0(甚至可能是5.1预览版),您将在不需要移动的情况下获得相当多的性能改进。自从4.0 4年前问世以来,已经做了很多工作!您可以共享您创建的索引吗?谢谢。我不记得列的列表,但它们都是外键,并且由于某些原因默认情况下没有索引。您能共享您创建的索引吗?谢谢。我不记得列的列表,但是它们都是外键,并且由于某种原因,它们在默认情况下没有索引。