Legacy Manual

Long term monitoring and auto-saving data

If you run PingPlotter 24 hours a day, 7 days a week, you're going to want to save your data (in case of power failure or other event), and you're also going to want to limit the memory footprint for PingPlotter. We talk about some best practices and recommendations here, although your needs may be different. For example, if you're using PingPlotter and monitoring a lot of targets, you'll probably want to keep fewer samples in memory for each target, otherwise the footprint of PingPlotter will be pretty big.

Setting up your memory footprint

PingPlotter defaults to keep 250,000 samples in memory. If you regularly do long term monitoring, though, you may want to understand this number so you can change it to fit your needs. In particular, if you keep too many samples in memory, you may run out of system memory at some point.

  • Determine how often you want to sample. 2.5 seconds (the default value in PingPlotter) gives a good amount of accuracy without too much data. Some people do use 10 seconds (although, anything much longer and you might miss problems).
  • We find that having 4 to 5 days of data in memory at a time works well. There are 86,400 seconds in a day, 432,000 seconds in 5 days. Divide this 432,000 by your trace interval. For 2.5 seconds, this gives us 172800 samples in 5 days.
  • In PingPlotter, go to "Edit" -> "Options" -> "Auto-save" section. Enter your calculated number in "Maximum samples to hold in memory". 172800 samples takes up roughly 10 to 15 megs of RAM in memory, which puts the PingPlotter memory footprint around 40 megs total (it keeps multiple copies of the data in RAM at some points, and general overhead). This is workable for just about any workstation, unless you're tracing to more than a handful of targets.
  • For PingPlotter Pro: If you're using multiple configurations, make sure you review the proper settings for each named configuration.
Setting up PingPlotter to save data

With 4 to 5 days of data in memory, each save of data will have all of this - which puts each save file around 1 to 3 megabytes. Having one file per day gives you easy access to a day's data, along with the previous 4 days for good analysis. We suggest saving every 30 to 60 minutes, with a file name like this: c:\ppdata\$dest\$dest $date.pp2

  • In PingPlotter, go to "Edit" -> "Options" -> "Auto-save" section.
  • Turn on "Auto-save data"
  • Set "Save Interval" for "30 minutes"
  • Set file name to "c:\ppdata\$dest\$dest $date.pp2". If you're currently tracing to a target, floating over the file name field will show you a hint of the file that would be actually saved.

Note: It's very important that you specify an absolute path for your save file name! If you're running as a Windows service and you get save files in your Win32\System directory (or some other unexpected directory), that's because you didn't set an absolute path here.

We set up "30 minutes" for a save interval. The file name controls how often we create a new save file. If the file already exists, then it will be overwritten to include the new data. You can include $hour in the save file name to get a new file every hour, but we don't recommend this for save data, since you'll get a new save file every hour and you may run out of hard drive space.

This will give you a new file each day with 5 days of data in it. Each day's file will be missing the last few minutes of the day as the 30 minute save interval may hit at 23:35 or 23:59, but that data will always be stored in the *next* day's file.

Feel free to tweak these settings however you want. This is just a discussion of some possible starting points.

Autosaving with a lot of targets

If you're using PingPlotter Pro and monitoring a lot of targets, you'll need to be cognizant of the impact of auto-saving a lot of targets. Each time the auto-save timer fires, PingPlotter completely overwrites each of your auto-save files. With a lot of data in memory and a lot of targets, this can take a few seconds. As you approach the memory limit of a machine, this can often mean memory swaps occur as well, to pull in the old samples and write them out to a file. On some machines, this can take a minute - during which time tracing can stop and the GUI can become unresponsive.

The best way to manage this is to limit the number of samples in memory - if you can keep just a couple of days in memory for each target you'll still have the history and you'll get better performance (and have more available memory on that machine).

**Some of the features listed in this topic are only available in PingPlotter Pro and/or PingPlotter Standard. See our product comparison page for more details**