L’utilisation du processeur Python tombe à 0%, reprend après la frappe au cours de l’exécution du script

mon problème est presque identique à celui publié ici:

Python dort jusqu’à la frappe

Ce fil de discussion est inactif depuis des années et s’il existe un protocole différent pour “ré-ouvrir”, veuillez nous en informer.

Je ne peux pas poster le code, mais voici quelques détails que je peux partager: j’exécute un script contenant de nombreuses instructions d’impression générées de manière itérative pour suivre les progrès réalisés pendant les nombreuses heures d’exécution du script. Tout en surveillant l’utilisation de mon processeur dans le Gestionnaire des tâches, je peux voir que l’utilisation tombe régulièrement à 0% et ne reprend que lorsque j’entre un type de trait de clé dans l’invite de commande réelle du script.

C’est arrivé sur mon ordinateur portable et sur le serveur sur lequel j’ai essayé d’exécuter le script. Les systèmes d’exploitation sont Windows 8.1 et Windows Server 2012r2, j’utilise Anaconda 2.2 avec Python 3.4.3. Les seules bibliothèques de python non standard que j’utilise sont les pandas 0.15.2, numpy 1.9.2, statsmodels 0.6.1 et scikit-learn 0.16.1.

Je ne sais pas si je peux déterminer si cela se produit toujours sur une ligne spécifique, mais j’essaierai – potentiellement, je peux le retrouver dans un paquet particulier que j’utilise si je peux le faire? Si quelqu’un a des idées sur ce qui pourrait causer quelque chose comme ceci, veuillez les partager, sinon des conseils sur la façon de résoudre ce problème par vous-même seraient grandement appréciés.

MISE À JOUR: J’ai exécuté le code suivant pour essayer de reproduire l’erreur:

import pandas as pd import numpy as np import matplotlib.pyplot as plt import statsmodels.api as sm from sklearn.linear_model import LogisticRegression from datetime import datetime num_rows = 1000 i = 1 t_init = datetime.now() while True: with open('temp_stage_1.txt','w') as file: file.write('current stage 1 iteration number: %d' % i) X = np.random.randint(2, size=(num_rows,25)) y = np.random.randint(2, size=num_rows) with open('temp_stage_2.txt','w') as file: file.write('current stage 2 iteration number: %d' % i) clf = LogisticRegression() clf.fit(X,y) clf.score(X,y) with open('temp_stage_3.txt','w') as file: file.write('current stage 3 iteration number: %d' % i) logit = sm.Logit(y,X) results = logit.fit(disp=False) with open('temp_stage_4.txt','w') as file: file.write('current stage 4 iteration number: %d' % i) for j in range(10000): waste_time_str = 'wasting some time' if i % 1000 == 0: t_now = datetime.now() t_delta = (t_now-t_init).seconds t_init = t_now print(t_delta) print(i) i += 1

J’ai pu reproduire l’erreur et en ouvrant les fichiers temporaires créés, j’ai pu constater que l’erreur s’était produite après la mise à jour du quasortingème fichier temporaire à la 26 000e itération. Je l’ai exécuté une seconde fois, l’erreur s’est produite sur un autre multiple de 1000 selon le 4ème fichier temporaire. Une autre observation intéressante est que, après avoir appuyé sur une touche et que l’exécution reprend, le delta de temps imprimé reflète le temps passé en attente. Ceci est également cohérent avec le script d’origine avec lequel j’ai vu cette erreur, cependant, dans ce cas, il n’a imprimé que ce qui semblait être des plages horaires normales, donc je sais que l’erreur s’est produite après que les valeurs de temps ont été atsortingbuées. Dans les deux cas, il semble que l’erreur se produise à l’une des instructions d’impression.

Il est fort probable que vous accédiez au “Mode d’édition rapide” par accident (en sélectionnant du texte dans le terminal Windows). Le mode d’édition rapide bloque toute impression sur la console jusqu’à ce que vous la quittiez (en appuyant sur une touche), ce qui est cohérent avec le fait que l’erreur se produit dans l’une des instructions d’impression.

Voir cet article (pas spécifique à python) pour plus de détails.