Question

我们遇到了Alfresco 4.0.e和mysql 5.5后端的一些性能问题。

通过性能监视器，我可以看到很多请求（不确定是什么触发这些请求）挂起数据库，响应时间接近100-200s。在极端情况下它是3000secs。

所有这些请求都是从露天应用程序本地发出的（不是我们在单独的服务器上共享的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 = ?

在这个查询上运行一个解释计划，其参数值似乎造成了最严重的破坏（~3000secs），这就是我所看到的 -

    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，我们如何优化它。

真的很感谢你的帮助。

Answer 1

我在Solaris上的4.0.d实例（使用MySQL）上遇到过类似的性能问题，结果发现MySQL版本的默认引擎性能很差！

一旦我将join / where子句中引用的每一列编入索引，问题就消失了，我获得了98％以上的性能提升！

Answer 2

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

与其他系统相比，mysql数据库的数据卷上的磁盘i / o要慢得多。我们使用sysbench random i / o test来验证它。
上面讨论的文件夹有几百万个文档似乎导致此查询变慢。
- 我们也无法从共享加载文件夹内容页面以显示任何内容（导致超时相关错误）。
- 我们计划重新构建此文件夹以包含更多子文件夹，以便限制每个文件夹中的文档。有迹象表明这会有所帮助，但做这样的事情听起来并不合适。对于将来可能会出现的其他类似案例，我们可能无法真正掌握这种控制权。
- 我想知道这是否仍然是新版Alfresco的限制说5.x

在alfresco中使用索引的mysql join查询速度很慢

2 个答案: