KNOWN ISSUE: Package Refresh (NS.Package Refresh) is taking over 24 hours to run

book

Article ID: 158941

calendar_today

Updated On:

Products

Management Platform (Formerly known as Notification Server)

Issue/Introduction

 The package refresh schedule on the Parent NS is taking more than 24 hours to complete and therefore in a perpetually running state.

Cause

There were some optimizations needed for some stored procedures and in the code.

CHANGES MADE

  • spGetAutoAssignInfoForPackage was 300ms, now around 220 ms
    Added new index to the SWDAdvertisement table on (_Latest, ProgramId) include AdvertisementId
    Added primary key (ResourceTargetGuid, FilterGuid) to #AdvResTargetsAndFilters temp table

  • spSetPackageServers was 65ms, now 24
    Installed vComputerResourceEx from 7.5 and updated references from vComputerResource to vComputerResourceEx

  • The original spGetAdvertisementsUsingPackagewas taking 65ms, modified spGetAdvertisementsUsingPackage takes 1ms. 
    The change was to eliminate all "lower()" function calls from this procedure

  •  Eliminating [Altiris.NS.StandardItems.SoftwareDelivery.SWDSupport : Void -> EnsurePackageShareVirtualDirectory()] call when not needed will cut several hours off the time

  •  [CreateFolderSnapshot(string packageLocation, string relativePackageLocation, out long totalSize, bool copyMapFile)] method in SWDSupport.cs is taking twice less time

  • Eliminating fileInfo.Length method double call in cycle (so access and cache the Length property value only once)

Resolution

Fixed as of  ITMS 7.5 SP1 and ITMS 7.1 SP2 MP1 Rollup v10 (HOWTO81832).

 
There is a pointfix available to be installed on top of ITMS 7.1 SP2 MP1 Rollup v7 that can be requested to Support. Please ask for "Pointfix_eTrack3401922_7.1_SP2_MP1_v7.zip" file.

Applies To

 ITMS 7.1 SP2 MP1 and later

Attachments

Pointfix_eTrack3401922_7.1_SP2_MP1_v7.zip get_app