The Antimalware Service, which runs on ZENworks Primary Servers, processes the Antimalware events data rolled up from managed devices and provides ZCC dashlet access (via the Antimalware Rest API) to the Antimalware database.
The Antimalware Service is a Spring Boot application. The following sections provide tuning information for the service:
Whenever a malware threat is detected, an ondemand malware scan occurs, or the ZENworks agent refreshes, one or more Antimalware event files is generated and rolled up via the Collection System to a Primary Server. The Antimalware Service then processes the data into the Antimalware database. The following sections describe settings you modify to tune event processing performance:
Event files are processed as a background activity in a multithreaded environment using ThreadPoolTaskExecutor. Generally the default settings are sufficient. However, if you find that the Antimalware Service’s CPU usage is too high you can reduce the number of available threads. Recognize that reducing the number of threads can slow down event file processing. Likewise, the number of threads in the pool could be increased if event files are accumulating in the queue and the server hardware supports the increase.
The thread pool settings are in the application.properties file:
Linux: /etc/opt/microfocus/antimalware/application.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\application.properties
|
Setting |
Description |
|---|---|
|
ameprocessor.threadpool.maxPoolSize |
The maximum number of threads that can ever be created to process event files. When a task is submitted, if queueCapacity is full and fewer than maxPoolSize threads are running, a new thread is created. The default is 10. |
|
ameprocessor.threadpool.corePoolSize |
The minimum number of worker threads to keep alive. When a task is submitted and fewer than corePoolSize threads are running, even if the threads exist but are idle, a new thread is created. The default is 5. |
|
ameprocessor.threadpool.queueCapacity |
The number of items that determine a full queue. New threads will only be created when queueCapacity is full. The default is 20. |
The Antimalware Service picks up event files in batches at a specified interval. Increasing the files per polling batch or the polling interval increases the number of files processed per hour but also increases the load on the Antimalware Service and Antimalware database.
The event polling settings are in the application.properties file:
Linux: /etc/opt/microfocus/antimalware/application.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\application.properties
|
Setting |
Description |
|---|---|
|
poller.maxMessagesPerPoll |
The maximum number of event files that can be picked up during one polling interval. The default is 100. |
|
poller.fequency |
The time, in milliseconds, between event polls. The default is 60000. |
|
poller.wait.beforeRelease |
The time, in milliseconds, the poller waits for the maxMessagesPerPoll number of events before processing the available events. The default is 100. |
|
retry.poller.frequency |
Event processing can fail in scenarios where the Antimalware database does not yet contain the parent information for the event files. For example, device data may not yet be synced from the ZENworks database to the Antimalware database or a parent event record has not yet arrived from a managed device. This setting determines the time, in milliseconds, between polls for files that have failed and need to be retried. The default is 300000 (5 minutes). The recommendation is to keep it above 4 minutes to give a failed database sync time to retry before the event processing retries. |
|
ame.retry.count |
The number of times that processing of failed files will be retried. The default is 3. |
After processing, event files are moved to success or failure directories. The following settings control how long the files are retained.
The event retention settings are in the application.properties file:
Linux: /etc/opt/microfocus/antimalware/application.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\application.properties
|
Setting |
Description |
|---|---|
|
success.retention.days |
The number of days that successfully processed event files are retained. The default is 1. |
|
failure.retention.days |
The number of days that event files that failed processing are retained. The default is 15. |
|
purge.lookup.schedule |
Allows you to schedule when the purge of the success and failure directories occurs. Cron format is used with the default being 0 0 0 * * * (midnight). |
Antimalware event files are processed together so that the benefits of jdbc batch and bulk copy are realized. The default setting values have been derived from scale tests run in the Micro Focus lab and, in general, should not require changes. The batch processing settings are in the amedatasource.properties file:
Linux: /etc/opt/microfocus/antimalware/amedatasource.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\amedatasource.properties
|
Setting |
Description |
|---|---|
|
ame.datasource.bulkcopy.batch.size |
The bulk copy batch size used for database persistence. The default is 10000. |
|
ame.datasource.jdbcbatch.batch.size |
The jdbc batch size used for database persistence. The default is 10000. |
The Antimalware Service uses embedded Tomcat. The table below lists the Tomcat settings that can be adjusted for performance tuning. These settings are in the application.properties file:
Linux: /etc/opt/microfocus/antimalware/application.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\application.properties
|
Setting |
Description |
|---|---|
|
server.tomcat.max-connections |
The maximum number of connections that the server accepts and processes at any given time. Once the limit has been reached, the operating system may still accept connections based on the "acceptCount" property. The default is 100. |
|
server.tomcat.accept-count |
The maximum queue length for incoming connection requests when all possible request processing threads are in use. The default is 10. |
|
server.connection-timeout |
Time (in seconds) that connectors wait for another HTTP request before closing the connection. The default is 10. |
|
server.tomcat.threads.max |
The maximum number of worker threads in server under top load. In other words, maximum number of simultaneous requests that can be handled. The default is 100. |
|
server.tomcat.min-spare-threads |
The minimum number of threads always kept running. This includes both active and idle threads. The default is 5. |
The Antimalware Service uses a C3p0 library to manage the database connections. The table below lists the c3p0 settings that can be adjusted for performance tuning. These settings are in the c3p0.properties file:
Linux: /etc/opt/microfocus/antimalware/c3p0.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\c3p0.properties
|
Setting |
Description |
|---|---|
|
spring.ame-datasource.min-poolsize |
The default is 6. |
|
spring.ame-datasource.max-poolsize |
The default is 100. |
|
spring.ame-datasource.num-helper-threads |
The default is 5. |
|
spring.ame-datasource.max-statements |
The default is 1000. |
|
spring.ame-datasource.max-statements-per-connection |
The default is 100. |
|
spring.ame-datasource.max-connection-age |
The default is 14400. |
|
spring.ame-datasource.max-idle-time |
The default is 3600. |
|
spring.ame-datasource.max-idle-time-excess-connections |
The default is 120. |
|
spring.ame-datasource.idle-connection-test-period |
The default is 600 |
Antimalware scan schedule settings are stored in the ZENworks database and synced to the Antimalware database. Once in the Antimalware database, a calculation is performed to determine a device’s Next Scan time. At that point, the device’s Next Scan time can be displayed in the Antimalware dashlets and ZCC pages that access the Antimalware database for data.
The Next Scan times are calculated and cached every two hours. This can be modified if ZENworks administrators are making frequent changes to scan schedules and want to reduce the time required for updated Next Scan times to be available in ZENworks Control Center.
The following setting controls how long the cached Next Scan times live before it is recalculated and recached. The setting is in the application.properties file:
Linux: /etc/opt/microfocus/antimalware/application.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\application.properties
|
Setting |
Description |
|---|---|
|
am.settings.cache.timetolive |
The time, in milliseconds, that the cached data lives before it is refreshed. The default is 7200 (2 hours). |
ZENworks Control Center uses a Rest API to the Antimalware service to query the Antimalware database for Antimalware data to display.
The ThreadPoolTaskExecutor helps execute simultaneous queries. Generally the default settings are sufficient. However, if you find that the Antimalware Service’s CPU usage is too high you can reduce the number of available threads. Recognize that reducing the number of threads can slow down query results. Likewise, the number of threads in the pool could be increased if queries are not being executed because of the load and the server hardware supports the increase.
The thread pool settings are in the application.properties file:
Linux: /etc/opt/microfocus/antimalware/application.properties
Windows: %ZENSERVER_HOME%\services\antimalware\conf\application.properties
|
Setting |
Description |
|---|---|
|
restapi.maximum.pool.size |
The maximum number of threads that can ever be created to process event files. When a task is submitted, if queue capacity is full and fewer than the maximum threads are running, a new thread is created. The default is 100. |
|
restapi.core.pool.size |
The minimum number of worker threads to keep alive without timing out. When a task is submitted and fewer than the minimum threads are running, even if the threads exist but are idle, a new thread is created. The default is 5. |
|
restapi.queue.capacity |
The number of items that determine a full queue. New threads will only be created when queue capacity is full. The default is 10. |
|
restapi.keep.alive.seconds |
The time, in seconds, for an idle worker thread to wait for more work before timing out. The default is 60. |
|
restapi.async.request.timeout.milliseconds |
The timeout period, in milliseconds for requests. The deault is 360000. |