PDQ Deploy and PDQ Inventory - Performance Setting Recommendations
Symptoms
- There's no specific behavior, but PDQ Deploy and/or PDQ Inventory seemed to have slowed down. Navigation within the software is sluggish.
- The GUI takes a while to load, sometimes crashes, and may take multiple attempts to successfully launch the program.
- Many deployments are queued and never actually deploy without needing to restart the PDQ services or reboot the PDQ server.
- After a reboot or restarting services, the PDQ server may work for a few hours and then slow down or lock up again.
- You have random errors with endpoints trying to complete an Inventory scan. A scan will fail once, then work perfectly fine the next time the endpoint is scanned.
- You may see errors within the product or in Windows Event Logs related to timeouts or integration errors. Integration errors are the result of PDQ Deploy and PDQ Inventory not being able to communicate with each other. This is usually an issue with credentials or performance settings causing communication issues. See here for more info: Create Event Viewer Log Files to Filter PDQ Events | PDQ Help Center
- When deploying to a PDQ Inventory collection, you may receive an error: "Unable to verify collection membership condition. Integration with PDQ Inventory has been closed"
Overview
PDQ Deploy and PDQ Inventory were designed to give System Administrators powerful tools to manage their environments. We error on the side of providing options rather than restricting configurations. Much like trying to install a jet engine into a lawnmower, customers can apply settings in good faith that appear to be beneficial but may cause unforeseen performance-related issues in other areas. We recommend the following settings to minimize and/or eliminate performance-related issues.
External Factors
PDQ Server Minimum and Recommended Specifications
- See our full hardware and OS System Requirements here: PDQ Deploy and Inventory - System Requirements
- Allow approximately 100-150 GB of storage for package repositories and product databases. This amount will vary per customer.
You should use the fastest disk storage available (NVME or SSD). If you have tiered storage in your datacenter, we recommend the fastest available to ensure the best possible read/write performance for the PDQ databases.
Security Products
Security products can cause communication issues between the PDQ server and endpoints. We strongly recommend making sure you've got the proper exemptions in place:
- Recommended Antivirus/Antimalware Exclusions for PDQ Deploy & Inventory
- Firewall Ports and External Exceptions
PDQ Deploy
All Schedules
When it comes to scheduling deployments, we recommend staggering Interval and Daily triggers at different times when possible. For example, if you have 4 deployments that you want to deploy every night, then we recommend changing the start times to be staggered at approximately 30 minute increments:
- 8:00pm Deployment 1
- 8:30pm Deployment 2
- 9:00pm Deployment 3
- 9:30pm Deployment 4
Options / Preferences / Deployments
As far as Deployment Cleanup, the default of 30 days should be fine for most environments. However, if you are seeing extended loading times for PDQ Deploy, you may consider changing this to a value of 7-14 days. (The lower the value, the better the performance.)
The Retry Queue is quickly becoming antiquated. If you are using PDQ Inventory, then we recommend NOT using the Retry Queue. Unless you only use PDQ Deploy alone, we recommend using deploy schedules targeting PDQ Inventory collections. See the following for more information:
- To Retry Queue or to not Retry Queue | PDQ Help Center
- When to use the retry queue vs. heartbeat triggers | PDQ Blog
PDQ Deploy: Options / Preferences / Performance
This is one of the more common things that we see in support. There's a temptation to increase the value for Concurrent Deployments beyond the default. This can quickly overwhelm the PDQ server with queued deployments and communication timeouts (integration errors) with PDQ Inventory. The idea is to reduce "burst" loads and have the PDQ server consistently working over time, rather than experiencing sudden and temporary resource demand that can lead to a range of issues.
Also, it's important to make sure you are using the right Copy Mode for your configuration. Use Push Copy Mode if you're hosting the package repository on the PDQ server itself, and Pull Copy Mode if you are using a network share. See the following for more information on Copy Modes:
- PDQ Deploy documentation - Performance Preferences Page
- What you need to know about PDQ Deploy Copy Mode | PDQ Blog
PDQ Inventory
Custom Variables
It's important to note that when you create a Custom Variable, even if the value is empty, it will create that field for every endpoint record you have in the database. Multiple created Custom Variables have the ability to quickly increase database size, potentially affecting performance.
Auto Reports
Just like deployments in PDQ Deploy, it's recommended to stagger the times that your Auto Reports run. Instead of 4 reports all running at 8:00am, schedule them to run a few minutes apart:
- Report A = 7:50am
- Report B = 8:00am
- Report C = 8:10am
- Report A = 8:20am
Options / Scan Profiles / Scheduling
When scheduling Scan Profiles, it's important to look at the run frequency of the scan as well as when you are running the scan. Scans that are constantly running or running at the same time can cause performance issues. What to change:
- Combine scans when possible
- Stagger the times of scans (Scan A at 9:00am, Scan B at 9:30am)
- Switch from an Interval Scan (Every x hours) to Scan Age (When scan age is x hours old) will help to spread out scanning times on endpoints and can improve overall performance.
Options / Scan Profiles
With regard to your custom Powershell and WMI scanners, It's important to be specific on the data you are looking for. A generic query can return a large amount of data and quickly increase the size of the database, affecting overall performance.
Options / Preferences / Active Directory
Active Directory scans can be very resource-intensive and we've seen some customers set the value far too low. In this case, it can lead to performance issues when AD-Sync runs too often. We recommend once a day or at a minimum every 4 hours.
Options / Preferences / Network
Auto Heartbeat is how often PDQ inventory attempts to check an endpoint to see if it's online. The default is 300 Seconds, but you can improve performance by increasing this number to something closer to the following values when you have lots of endpoints:
- 1000 endpoints = ~600 Seconds
- 2000 endpoints = ~900 Seconds
- 4000 endpoints = ~1500 Seconds
This reduces simultaneous connections which can increase overall performance.
Options / Preferences / PDQ Deploy
Another opportunity to reduce PDQ Inventory database size is to enable and delete deployment records older than 14 days. Unless you have additional retention requirements, this value should give you 2 weeks of deployment history to reference:
PDQ Inventory: Options / Preferences / Performance
Optimizing Databases
Once you've made any necessary changes, close PDQ Deploy and PDQ Inventory, open an elevated (Administrator) command prompt (or Powershell window), and run the following commands:
pdqdeploy optimizedatabase pdqinventory optimizedatabase
This will help clean up data that is no longer needed and reduce the size of your running databases, translating into improved performance on your PDQ server.
