Correction d'énormes tables SQL: WP_ActionScheduler_Actions & WP_ActionScheduler_logs [TIPS WOOCOMMERCE]

WooCommerce est devenu un module très utilisé magazine en ligne. Référencement, Gestion des produits, des stocks, du code propre et intuitif, une interface d'administration simple et des milliers de charrues développées pour WOO, ne sont que quelques-uns des arguments pour lesquels il mérite une chance lorsque vous envisagez de développer une boutique en ligne.

Comme tout CMS, ni Woo ne font pas des exceptions aux cotes qui peuvent se produire dans différents scénarios d'utilisation ou d'interaction avec d'autres plugins WordPress.
Sur un serveur avec des ressources matériel Assez généreux, j'ai remarqué que service de base de données (mysqld) commence à demander près de 80– 90% de la mémoire RAM. Un problème assez grave, car je ne comprenais tout simplement pas d'où vient l'erreur 110 de périodiquement (110: Connexion expirée).
À une vérification plus attentive des processus SQL, j'ai découvert qu'une base de données a deux tables de volume assez considérables: wp_actionscheduler_actions et wp_actionscheduler_logs.

Dans Mod Normal les actions prévues mais WooCommerce Action Scheduler Il doit être supprimé automatiquement après leur exécution. Cela ne se produit pas toujours, et ils restent bloqués dans WP_ActionSchedier_Actions avec le statut: échoué, annulé, en attente ou complet.

Dans l'image au-dessus des tables “wp_actionsScheduler” ils n'ont que Un peu plus de 15 Mo. Je suis désolé de ne pas avoir été inspiré à faire une capture d'écran quand ils avaient1,2 Go. Même ainsi, 15 Mo suffit pour une table qui contient les actions programmées de WooCommerce.
Ces tables “GONFLÉ” se traduit à cause de quoi WP-Cron ne supprime pas les entrées Statut de soin “échoué“, “annulé” et “complet“. Normalement, ces entrées doivent être automatiquement supprimées de la base de données.
Les actions programmées et leur état, nous pouvons le voir très facilement et dans WooCommerceStatutActions planifiées.

Comment nous nettoyons les insaltes “échoué“, “annulé” et “complet” DEPUISwp_actionscheduler_actions et wp_actionscheduler_logs

Nous accédons à la base de données via PhpMyAdmin, puis chez SQL, nous exécutons les lignes de commande:

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'canceled'
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'complete'
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'failed'

Une fois cette table nettoyée, cela ne signifie pas que le problème est résolu. Comme je l'ai dit ci-dessus, la principale cause est de désactiver pour diverses raisons du service WP-Chron. Ainsi les entrées avec les statuts “zombi” Ils ne peuvent plus être effacés.
Il est très important de savoir que si vous avez une boutique en ligne sur Wocommerce, et il est connecté aux magasins Facebook via le plugin “Facebook pour WooCommerce“, il synchronise automatiquement les produits WooCommerce avec votre compte Facebook Shops. Et cela dure environ 15 minutes. Ces entrées SQL si elles ne sont pas contrôlées, vous pouvez obtenir plusieurs centaines de mille lignes “wc_facebook_generate_feed” dans “wp_actionscheduler_actions“.

Cet intervalle est OK pour les magasins qui ont un grand nombre de commandes et il est nécessaire que le stock de magasins Facebook soit constamment mis à jour. Si vous considérez toujours ces synchronisation de Facebook et que votre magasin peut être effectué toutes les 24 heures, la ligne de code ci-dessous peut vous aider.

Ouvrez le fichier functions.php du thème WordPress / WooCommerce que votre magasin est en cours d'exécution et ajoute:

add_filter( 'wc_facebook_feed_generation_interval', function(){ return HOUR_IN_SECONDS * 24; } );

Ensuite, nous pouvons définir un intervalle d'une semaine pour le nettoyage automatique:

add_filter( 'action_scheduler_retention_period', 'wpb_action_scheduler_purge' );
function wpb_action_scheduler_purge() {
 return WEEK_IN_SECONDS;
}

Une fois enregistré ces modifications, vous n'aurez aucun problème avec les tables géantes “wp_actionscheduler_actions”.

Passionné par la technologie, j'écris avec plaisir sur Stealthsetts.com à partir de 2006. J'ai une riche expérience dans les systèmes d'exploitation: macOS, Windows et Linux, mais aussi dans les langages de programmation et les plateformes de blogs (WordPress) et pour les magasins en ligne (WooCommerce, Magento, Presashop).

Maison Votre source de tutoriels informatiques, des conseils et des nouvelles utiles. Correction d'énormes tables SQL: WP_ActionScheduler_Actions & WP_ActionScheduler_logs [TIPS WOOCOMMERCE]

1 pensé sur «Correction d'énormes tables SQL: WP_ActionScheduler_Actions & WP_ActionScheduler_logs [TIPS WOOCOMMERCE]”

  1. @Furtivité
    Merci pour l'aide. Vous sauvez ma journée et magasinez. J'ai d'abord découvert cela après un crash de mon boutique en ligne. De nombreux plugins ont commencé à vider leur sortie dans ce tableau et il remplit… La table de 9,2 Go a fait abandonner mon hôte à abandonner son temps PPP autrement fin. Maintenant, je coupe avec le code fin!
    Juste une question sur la chute de la corde cette table “wpb_action_scheduler_purge” Est-ce une valeur par défaut dans la base de données ou devrais-je éventuellement. Renommez-le à quelque chose dans mon (défaut est mon db pas 'wp_’ ) ou est-ce une fonctionnalité?
    Merci pour l'aide et le super bel article

    Salutation
    Netz

    Réponse
Laisser un commentaire