<div dir="ltr"><div>Hi Zak,</div><div><br></div><div>Thanks, yes, haha, I did notice the irony myself and was going to point it out, or change my first paragraph to put the emphasis on reducing CPU time spent, but I forgot! I noticed that powershell (on some versions of the PSclient) was using more CPU time than the process the server exists to run, which is clearly not a good situation.<br></div><div><br></div><div>So if I select UTF-8, it's not going to double the size of the messages sent to the Xymon server? I'll give it a go and see what happens.</div><div><br></div><div>I think being able to configure the scan interval for CPUs would be good.</div><div><br></div><div>The latest version of PSclient was not even completing one cycle before I was giving up and killing it, but I'll try UTF-8 and/or another server.<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<div style="TEXT-ALIGN:left"><span style="FONT-SIZE:12px"><span style="FONT-FAMILY:arial,helvetica,sans-serif">Kind regards,<br><br>SebA<br><br></span></span></div></div></div></div></div></div></div></span></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Jan 2019 at 11:59, Beck, Zak <<a href="mailto:zak.beck@accenture.com">zak.beck@accenture.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div class="gmail-m_4020181691486680702WordSection1">
<p class="MsoNormal"><span style="color:rgb(3,45,253)">Hi<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">Yes, there is no option for no encoding – I think the closest option to this is actually UTF-8 because it does not attempt to adjust the message body (remove diacritics and 0xa0 spaces)
before sending. That’s what is happening between your two log messages. Personally I don’t see that behaviour albeit with a 10x smaller data packet (I checked on several servers):<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">2019-01-29 11:43:06 Using ASCII encoding<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">2019-01-29 11:43:06 Connecting to host x.x.x.x<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">2019-01-29 11:43:06 Sent 100537 bytes to server<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">We can add a third option to do no encoding I guess.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">Detecting CPUs is entirely down to this WMI call: Get-WmiObject -Class Win32_Processor. Yes, it does take time. I have tried over the years to reduce the amount of WMI calls (I think
we’re down to 4) because they do seem to take a lot of time and on occasion are unreliable. Unfortunately I have not been able to find an alternative to this call. And I have 1000 VMs which can have CPUs hot added without reboot, so there is use case for checking
every time. The result of the WMI call is already cached so we could amend the script to optionally run only on slow scans (every 6 hours by default).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">It may be simpler to add regex processing for your filename issue, I can take a look.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">I had to chuckle, I hope you appreciate the irony of saying we’re suffering from feature bloat and then requesting more enhancements / features
</span><span style="font-family:"Segoe UI Emoji",sans-serif;color:rgb(3,45,253)">😉</span><span style="color:rgb(3,45,253)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)">Zak <u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(3,45,253)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Xymon <<a href="mailto:xymon-bounces@xymon.com" target="_blank">xymon-bounces@xymon.com</a>>
<b>On Behalf Of </b>SebA<br>
<b>Sent:</b> Monday, 28 January 2019 20:16<br>
<b>To:</b> Xymon Mailing List <<a href="mailto:xymon@xymon.com" target="_blank">xymon@xymon.com</a>><br>
<b>Subject:</b> [External] [Xymon] Xymon WinPSclient performance<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">It's great the way features have been added to Xymon WinPSclient, but I think it's started suffering from feature bloat now, illustrating the importance of making each feature optional like BBWin did very effectively. We are seeing memory
leaks on Windows 2012 R2 using version 2.28 (I started another thread about memory leaks a while back - I'll come back to this issue another time) and more and more CPU time being used up during each cycle.<br>
<br>
It seems that from version v2.21 a slow ASCII encoding conversion was added:<br>
<br>
myServer1 - : xymonclient.ps1 2.21 2017-04-28 <a href="mailto:zak.beck@accenture.com" target="_blank">
zak.beck@accenture.com</a><br>
2019-01-28 19:19:26 Sending to server<br>
2019-01-28 19:19:26 Using ASCII encoding<br>
2019-01-28 19:<b>20</b>:25 Connecting to host x.x.x.x <-- Yes, that took about
<b>1 minute of 100% processing of 1 of the 8 CPUs/Cores</b>.<br>
2019-01-28 19:20:26 Sent 2007850 bytes to server <-- OK, yes, that's rather a lot of data, but still it's not good.<br>
2019-01-28 19:20:26 Received 130 bytes from server<br>
<br>
Compare with:<br>
myServer1 - : xymonclient.ps1 2.19 2016-12-28 <a href="mailto:zak.beck@accenture.com" target="_blank">
zak.beck@accenture.com</a><br>
2019-01-28 19:15:59 Sending to server<br>
2019-01-28 19:15:59 Connecting to host x.x.x.x<br>
2019-01-28 19:15:59 Sent 2006765 bytes to server<br>
2019-01-28 19:16:00 Received 130 bytes from server<br>
<br>
Is it possible that converting to ASCII step introduced in v2.21 be made optional? In the latest version it is possible to send via UTF8, which was new in v2.21, or convert to ASCII, but it's not possible via configuration alone, I believe, to have the old
behaviour (from v2.19) that worked fine for us and was far faster.<br>
<br>
Another slow process is detecting the number of CPUs (on the same server):<br>
<br>
2019-01-28 19:29:05 XymonCollectInfo: Process info<br>
2019-01-28 19:29:05 XymonCollectInfo: calling XymonProcsCPUUtilisation<br>
2019-01-28 19:29:05 XymonCollectInfo: CPU info (WMI)<br>
2019-01-28 19:29:13 Found 8 CPUs, total of 0 cores<br>
2019-01-28 19:29:13 XymonCollectInfo: OS info (including memory) (WMI)<br>
2019-01-28 19:29:13 XymonCollectInfo: Service info (WMI)<br>
<br>
<b>8 seconds</b> for that. Why does it need to do this every time? The number of CPUs does not normally change without at least rebooting. It could do it just on the first cycle and cache it for future cycles.<br>
<br>
Another thing that would really speed up processing for us is being able to dynamically specify the filenames using special characters or something for the date, e.g. &DD &MM &YY<br>
We have files that rotate with new filesnames and if we could narrow down the filenames to process it would speed up processing by several more seconds.<br>
E.g. C:\Temp\myServerLog29-12-18.0.log<br>
<br>
In client-local.cfg:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Instead of:<br>
log:C:\Temp\myServerLog*.log:10240<br>
If we could to this, it would mean we process a small fraction of the number of files:<br>
log:C:\Temp\myServerLog&DD-&MM-&YY.*.log:10240<br>
<br>
<br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:9pt;font-family:"Arial",sans-serif">Kind regards,<br>
<br>
SebA</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<hr>
<font size="1" face="Arial" color="Gray"><br>
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by
you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of
internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement
at <a href="https://www.accenture.com/us-en/privacy-policy" target="_blank">https://www.accenture.com/us-en/privacy-policy</a>. <br>
______________________________________________________________________________________<br>
<br>
<a href="http://www.accenture.com" target="_blank">www.accenture.com</a><br>
</font>
</div>
</blockquote></div>