too many wc-admin_import_orders
-
I am having problems with my Scheduled actions. I see there are lots of “wc-admin_import_orders” pending. These are running every few seconds and I think it’s filling up the logs in my DB. My “wlv_actionscheduler_actions” is about 590 MB now in size, and there are probably a few thousand logs from “wc-admin_import_orders” .
The page I need help with: [log in to see the link]
-
How do I enable cron jobs?
To enable the cron job, locate the
wp-config.php
file in your root folder and check for the following line of code:define('DISABLE_WP_CRON', true);
If this line exists, change
true
tofalse
to enable the cron job. If the line is not present, add it at the end of thewp-config.php
file, ensuring to set the value tofalse
, then save the file.Alternatively, you can contact your hosting provider if the cron is disabled at the server level for further assistance.
Hi Cron jobs are enabled and I do see lots of “wc-admin_import_orders” . I stoped the imports and tried to change it to only 7 days and was getting error “There was a problem rebuilding your report data”
https://snipboard.io/dWfPcX.jpg
This had to enabled at server side.
-
This reply was modified 1 month ago by
meatface888.
After refreshing the page it went back to importing All. I have disabled WooCommerce Analytics for now so as not to use up CPU cycles.
How do check to see if “wp_1_wc_privacy_cleanup persists” is still generating requests like these:
https://pastebin.com/3Pbrr9iZIt is also running every 20 sec even when set to run every 5 min.
How can I check to see if these are still occurring?
-
This reply was modified 1 month ago by
meatface888.
Hello meatface888,
Thank you for your reply.
Before we dive into the details, I’d like to revisit your note: “This had to be enabled at server side.” Could you please clarify what exactly was enabled on the server side?
If server-side cron jobs are overriding the default WP-Cron behavior, we may need to take a different approach to identify and resolve the issue effectively. Your confirmation will help guide the next steps.
Looking forward to your response. 🙂
This is how they enabled the Cron Jobs:
baseos | 3dlabtech.ca | u941-8295xnm8sqt8@giowm1141.siteground.biz:~/www/staging2.3dlabtech.ca/public_html$ wp cron test Success: WP-Cron spawning is working as expected. baseos | 3dlabtech.ca | u941-8295xnm8sqt8@giowm1141.siteground.biz:~/www/staging2.3dlabtech.ca/public_html$
I did not see define(‘DISABLE_WP_CRON’, true); on staging site wp-config.php file.
-
This reply was modified 1 month ago by
meatface888.
Hello meatface888.
Thank you for your reply.
These lines are used to test whether WP-CRON is active or not. In this case, the output is Success. Which means it is working fine.
I’ve gone through all the previous messages to refresh my memory and better understand the situation.
You previously mentioned that after creating the staging site, the CPU usage remained low even with all plugins active, and the “Import historical data” process was not running indefinitely. Could you please confirm if this is still the case after enabling WP-CRON on the staging site?
Let’s focus on the staging site for now to avoid mixing up troubleshooting steps between the production and staging environments.
Looking forward to your response. 🙂
Hi Siteground said it was very low but that was before they told me they had Cron Jobs turned off. I am not sure how to check CPU usage of just the staging site. Do you know how I might do this or is this something only Siteground will be able to see?
Hi @meatface888,
I recommend contacting SiteGround support to have them take another look, as their hosting panel appears different and does not use cPanel. You can ask them to check the staging site since you now have Cron enabled there.
Please update us once you receive their feedback.
According to Siteground there is no way to track CPU usage of just the staging site but they want us to track the number of logs generated by “wp_1_wc_privacy_cleanup”. These logs are generated excessively and is what is causing the high CPU usage.
Resource utilization is tracked through Site Tools, and there are no separate statistics available in your Client Area under Services -> Hosting -> Settings -> Statistics.
However, you can monitor the execution of each website – the production site and the staging site by checking for excessive instances of wp_1_wc_privacy_cleanup in Site Tools -> Statistics -> Access Logs. Since the issue is related to an excessive number of executions, you can determine if it has been resolved by checking if the staging or production site is still generating a large number of similar requests.
Please note that the Access Logs section provides the most recent logs for both the staging and production websites. If you need historical data for previous days, you can obtain the RAW access logs for your website as described in the tutorial below:
https://siteground.com/kb/find-website-raw-access-logs/The log right now is filled with instances from”wp_1_wc_privacy_cleanup”
Hi @meatface888,
Thank you for the detailed explanation and for getting back to us. Apologies for the delayed response—this was due to additional time spent assessing the issue on our end.
To ensure we have all the necessary details and stay aligned on the core problem, I’d appreciate some clarification:
Are you experiencing the exact same issue on both the live site and the staging site?
If not, what exactly are you seeing on the staging site?
I ask because it looks like both environments have been used interchangeably in our conversation, which can cause confusion. For now, let’s focus solely on the staging site.
After creating the staging site, enabling CRON, and installing the WP Monitor plugin—using only the WooCommerce plugin and a default theme like Storefront or Twenty Twenty-Five—are you still able to replicate the issue exactly as it appears on the live site?
The link above that I sent is from the staging site. This is with all plugins turned off except for WooCommerce, and the theme is set to Twenty Five. I think the Staging site is running WooCommerce 9.8.5 and production is running 9.8.4. After the update, the issues did not go away.
35.206.97.3 http://www.staging2.3dlabtech.ca – [19/May/2025:21:52:11 +0000] “POST /wp-admin/admin-ajax.php?action=wp_1_wc_privacy_cleanup&nonce=194fa71109 HTTP/1.1″ 499 0 “-” “WordPress/6.8.1; https://www.staging2.3dlabtech.ca” | TLSv1.3 | – 0.979 0.979 – d NC:000000 UP:-DT
Yes this is the same as seen on the production site
35.206.84.21 http://www.3dlabtech.ca – [21/May/2025:18:21:52 +0000] “POST /wp-admin/admin-ajax.php?action=wp_1_wc_privacy_cleanup&nonce=86f0480446 HTTP/1.1″ 499 0 “-” “WordPress/6.8.1; https://www.3dlabtech.ca” | TLSv1.3 | – 0.982 0.982 – 0 NC:000000 UP:-DT cdnreq
Hi @meatface888,
Thank you for getting back to us and for sharing both log entries. From what you’ve shared, these appear to be normal entries.
To better understand where we currently stand with the original issue — you initially mentioned that:
“I’m having problems with my Scheduled Actions. I see a lot of wc-admin_import_orders pending, running every few seconds, and possibly filling up the logs in my database.”
Are you still seeing a high number of wc-admin_import_orders pending and firing every few seconds on the staging site as well? That seems to be the main concern you originally raised.
I just want to confirm if we’re still troubleshooting the same issue you originally mentioned, and whether it’s also occurring on the staging environment. Or are you now seeing wp_1_wc_privacy_cleanup filling up your database instead of wc-admin_import_orders? Just trying to make sure we’re aligned on the current problem.
The wp_1_wc_privacy_cleanup entries are normal, but they occur every 20 seconds even when it is set to run every 5 minutes.
wc-admin_import_orders I am seeing because I think Import historical data is running indefinitely and never stops. It also runs very frequently. In a time frame of about 30 min I see 90,000 completed in Schedualed Actions.
Both of these are running constantly and has crippled the server CPU.
Both of these issues have been replicated on the staging site. I have disabled WooCommerce Analytics for now to save on CPU usage. As I have said before, I am already overusing this server, and if it continues, they will shut down the site entirely.
-
This reply was modified 1 month ago by
- You must be logged in to reply to this topic.