High memory usage after script

Describe the bug

After running a script containing Set-ChannelProperty or Set-ObjectProperty there is very high memory usage and the server needs a reboot to recover from that. Is that a memory leak caused by PRTG API or PrtgAPI?

Steps to reproduce

$sensors = get-sensor -Tag wmidiskspacesensor

foreach($sensor in $sensors) {

    $sensor

    $properties = $sensor | get-objectproperty -Raw

    if($properties.limitpercent -eq 0){

        $sensor | Set-ObjectProperty -RawProperty limitpercent_ -RawValue 1 -Force
        $sensor | Set-ObjectProperty -RawProperty lowerlimitwarningpct_ -RawValue 5 -force
        $sensor | Set-ObjectProperty -RawProperty lowerlimiterrorpct_ -RawValue 3 -Force

    }else{

    Write-Host "$($sensor.id) Already applied"
    
    }

}




--------------------------------------------OR-------------------------------------
$allchannels = get-sensor -tags wmiuptimesensor | get-channel

$i = 1
foreach($channel in $channels){

    $channel
    $i
    
    #Error
    $ChannelValueSetting = "UpperErrorLimit"
    $ChannelMessageSetting = "ErrorLimitMessage"
    $LimitMessage = ""
    $Value = $null
    
    if($channel.LimitsEnabled){
    
        $channel | Set-ChannelProperty $ChannelMessageSetting $LimitMessage
    
        $channel = get-channel -SensorId $channel.SensorId
    
        $channel | Set-ChannelProperty $ChannelValueSetting $Value
    
    }
    
    #Warning
    $ChannelValueSetting = "UpperWarningLimit"
    $ChannelMessageSetting = "WarningLimitMessage"
    $Value = 15552000
    $LimitMessage = "Server has not been restartet for 180 days. Please take the necessary steps to restart the server."
    $channel = get-channel -SensorId $channel.SensorId
    $channel | Set-ChannelProperty $ChannelValueSetting $Value
    $channel = get-channel -SensorId $channel.SensorId
    $channel | Set-ChannelProperty $ChannelMessageSetting $LimitMessage

    start-sleep 5
    $i++

    $memory = (get-sensor -Id 1001 | get-channel -id 3).LastValue
    if($memory -lt 5624745984){

        Write-host "Memory less than 5 GB waiting 5 min"
        Start-Sleep 300

    }

}

What is the output of ‘Get-PrtgClient -Diagnostic’?

PSVersion      : 5.1.19041.1320
PSEdition      : Desktop
OS             : Microsoft Windows 10 Enterprise
PrtgAPIVersion : 0.9.13
Culture        : de-CH
CLRVersion     : 528372
PrtgVersion    : 21.3.71.1416
PrtgLanguage   : english.lng

Additional context

For me it happens after about 100-200 sensors.

Both Servers have 32 GB RAM and usually using about 7-8 GB. We have a quite large environment with two core servers. Server 1 -> 12’000 Sensors Server 2 -> 6’000 Sensors

First I thought maybe the requests are to fast and it will write it to memory before to disk. But the memory usage didn’t go down after a few days so I rebooted.

Also not using the newest PRTG Version. We gotta update.

EDIT Just did some more tests. If I run the script and let the memory almost fill up. Stop the script and reboot. All changes are gone because they are saved in the memory. I guess it will process them but the memory doesn’t go down and we don’t really now when they are applied.

[lordmilko]

Hi @noaboa97,

As noted in #253, #202, and #198, my perspective on this issue is that this is an issue with PRTG, rather than PrtgAPI. As mentioned in #253, Paessler recently alerted me to a secret setting that can potentially be included in Set-ObjectProperty / Set-ChannelProperty API requests that should help with memory usage; these changes will be present in the next release of PrtgAPI. Never-the-less, there’s no guarantee that this will actually help in all scenarios, and it is still ultimately PRTG’s responsibility to deal with its memory appropriately whether you call its API endpoints “correctly” or not.

Case in point /editsettings API endpoint is not a “public API”; the public API for modifying object properties is /api/setobjectproperty.htm. However the public API for modifying object properties doesn’t support all properties and can’t modify multiple properties at once. So it is no surprise you have forum posts from Paessler’s own employees telling people to use the “internal” API, despite the fact evidently anyone who tries to use that API call en masse will potentially cause a huge memory leak. Woops! Hence, this is an issue with PRTG, and Paessler needs to update it to deal with the scenario of people invoking API calls “they’re not supposed to” (which is clearly not an uncommon occurrence even ignoring PrtgAPI). IMO it is highly unlikely Paessler will properly fix these sorts of issues given they’re working on APIv2, but I guess you never know.

In any case, please see the linked posts for some of my recommendations for managing memory issues in PRTG; also note that if you want to modify multiple raw properties on a given object, you can do them all in one go via a single API call with a set of -RawParameters rather than a single RawProperty/ RawValue

Regards, lordmilko

[noaboa97]

Oops my bad. Thanks.