What is the ping latency?
If you run a continuous ping there must be at least some variation. You may want to review the following article to see if this helps:
Both machines have similar ping latency (16-17ms). Yes, there is some variation, but very little. Both machines are in the same vlan, same physical location, and are both virtualized.
Thanks for the article. Most of the items in there I have already tried, and really only apply if we were experiencing across the board slowness (which we are not). The exponentially slow scans only occur on a handful of machines. My guess is some configuration issue on the client we are scanning.
In regards to that article:
1. We are on the absolute latest version of vProtect (9.0.1 1163)
2. Console has 4 procs, 4GB RAM (meets recommended requirements)
3. Console does not have symantec installed (or any other antivirus) for testing purposes. Hosts we are scanning do, and have a policy that excludes the console machine from network threat protection
4. No known networking issues, and good boxes on same vlan, physical location, etc as bad boxes.
5. No database issues, as this would likely effect all scans, not selected boxes in test scans
6. VM contention is not occuring on servers.
Anybody seen any slow scanning on particular boxes? What were your solutions (if you had any)?
I would expect if it were WAN or vLAN related you would see both machines with the same speed issue. How about storage? Are they on different parts of your storage? Free space on each of the VMs the same? Different reserved memory or memory available on these machines?
1 of 1 people found this helpful
Joel, this may not be the source of the issue but I have had the same thing happen with machines on the same LAN 'talking' to the Shavlik server across a fiber WAN. I could find no explanation for the slowness until I checked the event logs on the target server. In one instance I found that the server had several events in the system event log that were event source: WSH. Specifically it boiled down to an invalid WMI namespace. This server happened to be a Citrix server as well. Running a rebuild on the target server database using WBEM commands fixed it partially. Further, Citrix had registered similar events pertaining to the WBEM namespace being invalid. Once I followed the directions in both cases to 'fix' the issue the server responded as did the others that were on that same LAN. If indeed you do have WMI errors, I can post the 'how-to' to fix it using the WBEMTEST app in Windows.
Thanks for the suggestions. Responses below. Unfortunately, it appears to be a bit of a moving target, which makes it difficult to troubleshoot. After a week and a half of slow scanning, I reinstalled the Shavlik software on a new server in a local LAN site and re-tested. This time, it went fast on the slow box. This would lead me to think it is WAN related, however this doesn't jive with how fast the new server scans on boxes at remote locations (fast).
I am going to probably have to just try and re-isolate a test case (if I can). I"ve been working w/ Shavlik support for over 2 months now and unfortunately it hasn't been particularly helpful.
DenJones, thanks for the detailed suggestion. I checked the system log of the slow target machine (the one with slow scans) and didn't see anything sourced by WSH. Also, this machine isn't a citrix server; it is actually a domain controller.
Chris, in answer to your post: Yes, I would agree that if it were WAN/LAN related then I should see similar behavior from the different machines. I tested on two machines with similar resource profiles (cpus, memory and both iSCSI to same back-end) within VMWare. I vMotioned. No change. I did a quick free space check on the OS and it has plenty of free space.