Search Our Database

Resolving dataskq high CPU usage in DirectAdmin

Last updated on |
by

Introduction

This article will guide you through the steps to troubleshoot and resolve issues when the dataskq process in DirectAdmin is causing 100% CPU usage. Dataskq handles tasks such as user tallying, processing logs, and updating statistics. If it is consuming too many system resources, it can severely impact server performance. This guide will help you debug and resolve the high load issue caused by dataskq.

 

Prerequisites

  • Access to the server with root or sudo privileges
  • Basic understanding of using command-line tools like top, killall, and tail
  • DirectAdmin installed on your server

 

Step-by-Step Guide

 

Step 1: Check for high load caused by dataskq

  • Start by checking the server’s load and identifying if dataskq is consuming excessive CPU resources. Use the top or htop command to monitor CPU usage:
top
  • If dataskq is at the top of the list and consuming a high percentage of CPU, it is the likely cause of the increased load.

 

Step 2: Check the system log for the nightly tally

  • A nightly tally in the context of DirectAdmin refers to an automated process that runs during off-peak hours (usually at night) to perform maintenance tasks and generate reports.
  • The dataskq process may be running a nightly tally, which is normal but can cause a temporary increase in system load. To check if the tally is running, examine the system log:
tail -n 20 /var/log/directadmin/system.log
  • If users are continuously being added to the log and the log is growing, this indicates the tally process is running normally. However, if the log is stuck on one user or not growing, further investigation is needed.

 

Step 3: Ask dataskq what it is processing

  • To check what dataskq is currently doing, send a signal to the process and check the output in the errortaskq.log:
  • This command will dump dataskq’s current process location into the errortaskq.log file.
killall -USR1 dataskq
tail -n 10 /var/log/directadmin/errortaskq.log
  • Review the output to understand what task dataskq is performing. The log output will help you determine the next step.
  • What this will do is dump the running dataskq’s current process location to the errortaskq.log. What that log output says will determine what to do next.

 

Step 4: Investigate oversized inboxes (Maildir reference)

  • If the log output mentions Maildir with a specific path, it is likely that a large inbox is causing the issue. You can manually check the specified inbox for large emails that may be overloading the process.
  • Navigate to the mentioned path and delete or archive old or oversized emails to free up space if the email user isn’t managing them.
  • This will help reduce the load caused by the email processing tasks

 

Step 5: Investigate brute force log entries

  • If the log references brute_force or related files, it indicates that dataskq is processing system logs with many brute force entries, which can lead to high CPU usage.
  • First, ensure you are using the latest version of DirectAdmin
  • Then, navigate to the admin directory and check the size of the brute force logs:
cd /usr/local/directadmin/data/admin
ls -lah brute_*
  • If the brute_log_entries.list file is large (e.g., over 1 MB), this can slow down the dataskq process. You can safely delete the brute_log_entries.list file as it’s not part of the Brute Force Monitor’s (BFM’s) counting:
rm -f brute_log_entries.list

 

Step 6: Monitor and restart services

  • After taking these steps, continue monitoring the server’s CPU usage to ensure the high load issue is resolved.
  • If dataskq is still causing high CPU usage, you may need to restart the DirectAdmin service:
systemctl restart directadmin

 

Conclusion

By following these steps, you can identify and resolve the issue of dataskq causing high CPU usage on your server. Clearing large logs, managing oversized inboxes, and adjusting brute force log settings are key actions to reduce the load. Regular monitoring of the server and system logs will help prevent this issue from recurring.

For additional assistance or if you encounter any issues, please contact our support team at support@ipserverone.com.