升级Liferay6.1到6.2 GA4，DMS需要很长时间才能升级

Question

我正在尝试将我的实时门户从LR6.1升级到LR6.2CE-GA4。一切都很好，除了Liferay升级DMS需要30多个小时，

在6.1中，我的DMS已经在dl.store.impl=com.liferay.portlet.documentlibrary.store.AdvancedFileSystemStore上了

大小为29 GB

是的，它提供了一些异常，即没有找到特定的文件，但最终会进行升级。痛点是升级DMS所需的时间。由于门户是实时的，客户不能等待这么长时间的升级。请提出解决办法/解决方案。

提前感谢

Answer 1

请检查是否有任何文件丢失(同时升级日志将报告)，如果有，那么我已经编写了以下方法，首先删除那些悬挂的文件，然后启动升级过程。

  public void cleanDMS(){
    List <DLFileEntry> fileEntries = null;
    fileEntryId = 0L;
    try {
        fileEntries = DLFileEntryLocalServiceUtil.getDLFileEntries(0, DLFileEntryLocalServiceUtil.getDLFileEntriesCount());
        System.out.println("Total file entries in system   "+ fileEntries.size());
        for (DLFileEntry dlFileEntry : fileEntries) {

            getFileAsStream(dlFileEntry.getUserId(), dlFileEntry.getFileEntryId(), dlFileEntry.getVersion());
            //System.out.println("Legal File found ");
        }
        System.out.println("###################################################################################################################");
        System.out.println("total dangling entries found  and deleted are "+ entries.size());
        System.out.println("###################################################################################################################");

    } catch (SystemException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    } 
}

public void getFileAsStream(long userId, long fileEntryIdsss, String version){
    try {
        fileEntryId = fileEntryIdsss;
        DLFileEntryLocalServiceUtil.getFileAsStream( userId, fileEntryIdsss, version);

    }catch (NoSuchFileException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
            try {
                //DLFileEntryLocalServiceUtil.deleteDLFileEntry(fileEntryId);
                DLAppLocalServiceUtil.deleteFileEntry(fileEntryId);
            } catch (PortalException e1) {
                // TODO Auto-generated catch block
                e1.printStackTrace();
            } catch (SystemException e1) {
                // TODO Auto-generated catch block
                e1.printStackTrace();
            }
            System.out.println("No such file Exception caught for this ");
            entries.add(fileEntryId);
    } catch (PortalException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    } catch (SystemException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

Answer 2

您必须找出问题的根源--您提到DMS中有29G的数据，但它可能与此无关:监视升级过程，看看它实际上在做什么，瓶颈在哪里:是否只有缓慢的NAS才能将数据传输给Liferay？当门户运行其升级例程时，CPU是否已耗尽？您的数据库能处理元数据的更新吗？是否有需要但在更新期间无法获取的外部资源？(例如DTD文档、预览中包含的外部图像)

此外:虽然它可能是DMS，但也可能是完全不同的东西。

另一个测试(如果DMS正在运行很长时间)可能是值得的，就是暂时将Document迁移到另一个存储，进行升级并迁移回来。如果运行速度要快得多，那么您就会更好，即使没有解决根本原因也是如此。

听起来像是一个常规的性能调优工作，只是这一次的一次操作。性能调优的算法是：

1. 识别瓶颈#1 (度量！)
2. 修好它

现在瓶颈2得到了升级到新的#1 -漂洗和重复，直到性能令人满意。千万不要没有测量步骤，因为你可能会从瓶颈开始#3，投入大量的工作，但只得到5%的表现，而不是你从第一获得的50%