Hi all,

I'm a bit surprised by the effect that probkup online seems to be having on the buffer pool hit rate in OE11.5 and 11.7, as seen in the dashboard. Two customers run a full online backup and I see the hit rate drop to 20% and 30% respectively around the time of the backup. A third customer runs an incremental online backup, and their hit rate drops to 0.5% around the time of the backup. This pattern repeats over several consecutive days. On all sites, backups occur during the night when there is no other activity.

All other things being equal, I would have expected the incremental backup site to experience less of a drop, because fewer blocks are being backed up. I know that each data block has its backup counter read during an incremental backup, to see if it should be included in the backup. Does that mean then that every data block comes into the buffer pool even for an incremental backup? Although the throughput in all 3 systems is broadly similar, the customer doing the incremental backup has a substantially larger database than the other two, and I guess that's why their hit rate is dropping so low.

FWIW, we're using -bp 10 and -com.

TIA
Nick

@mlb3820 Thanks Mark. That's fixed it.

Hmm... looking here (https://github.com/influxdata/telegraf/issues/10162) it sounds like the config file for Windows might include entries that are Linux-specific, and so when Telegraf says "not supported" it is really only complaining about the "inputs.processes" section which should not be there.

In fact, if I comment that section then I don't get the "not supported" error. However, I'm still not getting any stats in my server dashboard. Could someone post a telegraf.conf file from a working Windows setup, so that I can make my file has everything it needs?

Hi all,

Does anyone have Telegraf running successfully on Windows? I installed v1.22.0 today for my Protop 319 installation on Windows 10, but it isn't playing nicely - I'm not getting any server stats in my dashboard.

1. Download and unpack to c:\program files\telegraf

2. Set outputs.influxdb in telegraf.conf:
   urls = ["http://dashboard.protop.com.au/data-z6418"]

3. Set logfile in telegraf.conf:
   logfile = "c:/temp/telegraf.log"

4. Install Telegraf as a service and start the Telegraf service. Telegraf.log now contains the following, in addition to the usual database creation error:

2022-03-29T04:11:00Z I! Starting Telegraf 1.22.0
2022-03-29T04:11:00Z I! Loaded inputs: cpu disk diskio kernel mem processes swap system
2022-03-29T04:11:00Z I! Loaded aggregators:
2022-03-29T04:11:00Z I! Loaded processors:
2022-03-29T04:11:00Z I! Loaded outputs: influxdb
2022-03-29T04:11:00Z I! Tags enabled: host=NWILLIAMSON01
2022-03-29T04:11:00Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"NWILLIAMSON01", Flush Interval:10s
2022-03-29T04:11:00Z W! [inputs.processes] Current platform is not supported

5. Run the test: telegraf.exe --test --config "C:\Program Files\Telegraf\Telegraf.conf"

I get this on the screen:

system,host=NWILLIAMSON01 load1=0,load15=0,load5=0,n_cpus=8i 1648527210000000000
system,host=NWILLIAMSON01 uptime=77784i 1648527210000000000
system,host=NWILLIAMSON01 uptime_format="21:36" 1648527210000000000
mem,host=NWILLIAMSON01 available=17890078720i,available_percent=52.51187941814987,total=34068631552i,used=16178552832i,used_percent=47.48812058185013 1648527210000000000
diskio,host=NWILLIAMSON01,name=C: io_time=0i,iops_in_progress=0i,merged_reads=0i,merged_writes=0i,read_bytes=13601218048i,read_time=92i,reads=403038i,weighted_io_time=0i,write_bytes=57326195200i,write_time=247i,writes=4991371i 1648527210000000000
disk,device=C:,fstype=NTFS,host=NWILLIAMSON01,mode=rw,path=\C: free=740135219200i,inodes_free=0i,inodes_total=0i,inodes_used=0i,total=1021206048768i,used=281070829568i,used_percent=27.523419970640457 1648527210000000000
swap,host=NWILLIAMSON01 free=51582259200i,total=68428369920i,used=16846110720i,used_percent=24.61860590818528 1648527210000000000
swap,host=NWILLIAMSON01 in=0i,out=0i 1648527210000000000
cpu,cpu=cpu0,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=96.96969696969697,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=0,usage_user=3.0303030303030303 1648527210000000000
cpu,cpu=cpu1,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=96.96969696969697,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=3.0303030303030303,usage_user=0 1648527210000000000
cpu,cpu=cpu2,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=63.63636363636363,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=33.333333333333336,usage_user=3.0303030303030303 1648527210000000000
cpu,cpu=cpu3,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=90.9090909090909,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=6.0606060606060606,usage_user=3.0303030303030303 1648527210000000000
cpu,cpu=cpu4,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=96.96969696969697,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=3.0303030303030303,usage_user=0 1648527210000000000
cpu,cpu=cpu5,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=84.84848484848484,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=15.151515151515152,usage_user=0 1648527210000000000
cpu,cpu=cpu6,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=87.87878787878788,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=12.121212121212121,usage_user=0 1648527210000000000
cpu,cpu=cpu7,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=96.96969696969697,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=3.0303030303030303,usage_user=0 1648527210000000000
cpu,cpu=cpu-total,host=NWILLIAMSON01 usage_guest=0,usage_guest_nice=0,usage_idle=89.39393939393939,usage_iowait=0,usage_irq=0,usage_nice=0,usage_softirq=0,usage_steal=0,usage_system=9.469696969696969,usage_user=1.1363636363636365 1648527210000000000

...and this in telegraf.log:

2022-03-29T04:13:29Z I! Starting Telegraf 1.22.0
2022-03-29T04:13:29Z I! Loaded inputs: cpu disk diskio kernel mem processes swap system
2022-03-29T04:13:29Z I! Loaded aggregators:
2022-03-29T04:13:29Z I! Loaded processors:
2022-03-29T04:13:29Z W! Outputs are not used in testing mode!
2022-03-29T04:13:29Z I! Tags enabled: host=NWILLIAMSON01
2022-03-29T04:13:29Z W! [inputs.processes] Current platform is not supported

Googling, I see some posts about the "not supported" error in various forums and I see people commenting that Telegraf is only experimental on Windows, although the vendor's website says they do support Telegraf - but no other products - on Windows.

TIA
Nick

Thanks Paul. I updated to to the latest build this morning and I still see the error, but the stats are uploading just fine so I'll ignore it.

Cheers,
Nick

Should have mentioned... by adding some debug output to the BAT file, I know the command it is invoking is:

start /b _progres -b -p util/zippyng.p -db pms -S 4013 -H localhost -param nick.lh -basekey "INI" -ininame etc\protop.ini -pf etc\protop.pf -T C:\Garradin\Application\ProTop\tmp

I don't have a nick.lh file anywhere. BTW, I have also added zippyng.bat back into the scheduler, and it behaves the same as it does from the command line - the LH stats upload successfully, and I get the errors in tmp\zippyng.nick.lh.err.

Hi all,

ProTop 319 on Windows 10 with OE 11.7.13 64-bit.

ProTop is working fine and I see my dashboards in the portal. It has been uploading user experience data for shared memory connections by default, and I'm trying to get it working for localhost as well. I got some errors when I set it up in the scheduler so I undid that and tried to simplify things by just running zippyng.bat from inside a ProEnv shell in my ProTop folder, like this:

bin\zippyng.bat nick lh 4013

nick is the friendly name for my local database, real name pms. I can connect to it from the same ProEnv without any errors:

prowin pms -H localhost -S 4013 -N tcp

When I run zippyng.bat as shown, it seems to work OK - I get a log\zippyng.nick.lh.log with entries like this:

28/03/2022 17:59:49.149+11:00 270000
28/03/2022 18:00:49.789+11:00 190000
28/03/2022 18:01:50.348+11:00 150000

...and there's nothing nasty in log\dbmonitor.log:

2022/03/28 18:02:58.166+11:00 starting: nick waiting to start yes C:\Garradin\Work\v12.1\app\OE117\db\pms
2022/03/28 18:02:58.174+11:00 startWaiting, launched: _progres -b -p util\pt3agent.p -pf etc\protop.pf -param nick -T C:\Garradin\Application\ProTop\tmp -basekey "INI" -ininame etc\protop.ini C:\Garradin\Work\v12.1\app\OE117\db\pms -errorstack -clientlog C:\Garradin\Application\ProTop\tmp\pt3agent.nick.debug
2022/03/28 18:02:58.817+11:00 lgDate: 70/01/01 skipping ahead to: 22/03/28
2022/03/28 18:02:58.818+11:00 sendAlert( dashboard.protop.com.au, logMessage794, info, "" )

The LH stats are uploading to the Bogomips dashboard correctly, but I get a tmp\zippyng.nick.lh.err containing these entries:

The system cannot find the drive specified.
28/03/2022 17:59:49.087+11:00 Unable to find dbanalys: or pms
28/03/2022 17:59:49.094+11:00 Creating new flag file: C:\Garradin\Application\ProTop\tmp/zippyng.nick.lh.flg 10488

There is an up-to-date dbanalys - I did it from inside Protop RT today. Do I need to worry about the error messages?

TIA
Nick