Bonjour,
j'ai lancé un calcul sur python qui d'apres le rythme des premiers resultats devrait prendre entre 17 et 34 jours.
avant d'optimiser avec du jit, cython ou autres je voudrais eviter l'eccueil du plantage.
Or le processus a planté et les forums sur cette erreur ne semblent pas tres prolixes.
d'apres mon experience, la gestion des buffers peut etre tres consommatrice de ressources cpu/memoire et je ne sais pas trop comment python se debrouille de ce cote la.
du coup :
dans mon algo je read un fichier que je charge dans des liste
je fais les calculs sur les listes
jecris le fichier modifié à la fin.
est ce ok de faire comme ca si le fichier est gros (quelques centaines de Mo de texte)
y a t il une autre methode pr ecrire au fur et a mesure?
en java, les objets sont déchargés de la memoire à partir du moment où il n'ont plus de variable assigné si je me rapelle bien. est ce la meme chose en python?
si vous avez dautres suggestions pr amélioration générique des performances ou de la fiabilité des aglorithmes, je suis preneur
merci
# Moteur SQL
Posté par benja . Évalué à 1. Dernière modification le 08 octobre 2020 à 18:57.
Si ces données sont structurées, pourquoi ne pas importer tout cela dans un serveur sql qui saura correctement gérer la mémoire et travailler avec des fichiers d'échanges le cas nécessaire ?
Sinon pour répondre à tes questions, non python n'alloue pas des buffeurs énormes pour faire des I/O. Étant donné qu'il n'y a que deux fichiers (entrée et sortie), il est très peu probable que ceci soit la source de tes problèmes. Il est probable que la mémoire soit utilisée par tes listes justement, surtout si tu utilises beaucoup de listes intermédiaires. En ce qui concerne le ramasse-miette, python utilise également ce concept tout comme java, sauf qu'il se base sur le comptage de référence, là où java analyse le graphe des valeurs accessibles. Hormis cette différence d'implémentation, ceux-ci ont la même fonction. Il faut bien faire attention de ne pas garder de références sur les résultats intermédiaires plus longtemps que nécessaire, afin de permette la libération de la mémoire utilisée par ceux-ci.
Suggestions: utiliser les générateurs/itérateurs, activer plus de swap, calculer un l'ordre de grandeur de la mémoire nécessaire et vérifier la faisabilité, éviter de lire tout le fichier d'un coup (faire du ligne-à-ligne ou utiliser mmap).
[^] # Re: Moteur SQL
Posté par kr1p . Évalué à 1. Dernière modification le 09 octobre 2020 à 11:12.
En fait ce sont des données spatiales. Donc en sql, il faut indexer, en gist par exemple, ce qui permettrait effectivement de gagner du temps machine.
cependant, les glitch perpetuels que j'ai avec mes logiciels de gestion de bdd, que ce soit pgadmin ou dbeaver, me font préferer une traitement en pur python.
je n'ai pas encore vu les generateurs/iterateurs. est ce que cest la commande yield?
pr le swap, tu parles bien d'un reglage de l'os?
pr le calcul de la memoire necessaire, j'ai vu en java la taille des données de base (les int, les char, les string, etc) mais en python, on m'a dit sur un chat que les int sont en fait des bigint et pas necessairement plus rapide à traiter que les float. en outre je n'ai pas vu de doc sur le calcul de la memoire necessaire. est ce que tu as un lien vers de la doc que je peux lire à ce sujet?
pour "éviter de lire le fichier d'un coup", mon algo fait ca :
open fichier
charger chaque ligne du fichier dans une liste
decomposer chaque element de la liste(chaque ligne) en une sous liste
pour chaque element (chaque ligne du fichier initial) effectuer un calcul
ajouter le resultat du calcul à la liste initiale
ecrire dans fichier l'ajout des elements calculés
il y a donc bien une boucle qui fait un traitement "ligne à ligne".
si je comprend bien ta suggestion est ce que ce serait de faire :?
open fichier
charger la ligne i du fichier
faire le calcul
ecrire le resultat dans un fichier
[^] # Re: Moteur SQL
Posté par benja . Évalué à 3. Dernière modification le 09 octobre 2020 à 16:09.
Oui c'est exactement ça dont je parle, il y a un tuto ici https://realpython.com/introduction-to-python-generators/#example-1-reading-large-files
Dans ton cas, tu ne vas pas construire ta grande liste de petites liste en une fois, mais simplement tes petites listes au fur et à mesure que tu lis chaque ligne. Parfois cela impliquera de refaire un calcul (pour recommencer au début du fichier f, faire f.seek(0,SEEK_SET) cf. documentation), mais c'est un compromis nécessaire quand tu travailles avec de grosses données. Voir aussi la notion de fold/reduce pour le big-data, les algos pour calculer des moyennes cumulées, etc.
Oui cela permet d'augmenter virtuellement la mémoire disponible pour un programme au prix de très mauvaises performances, voir de problèmes de stabilité pour les autres programmes, à éviter donc. C'est défini par la taille de ta partition d'échange ou de fichier swap supplémentaires (comme sur windows). Dans ton cas, tu peux voir ton fichier comme un swap, c'est-à-dire de la mémoire stockée sur disque et chargée à la demande, pas besoin de le charger deux fois en "mémoire" donc.
Il ne s'agit pas de faire un calcul précis mais juste une approximation, bien que comme tu as l'air d'en être au courant avec beaucoup de recherche sur les types de datastructures utilisée par python il doit être possible d'être assez précis. Genre comptons au pif 10 octets par entiers, 16 octets d'overhead de la liste par valeur d'entier (2 pointeurs ?), 100 pour par liste en elle même (entête, stats, ref gc, etc. ??). et que dans ton fichier original tu utilise en moyenne 3 octets par valeurs, ca te fais 800*1M/3*26+100*2 octets, fin bref grosso-modo un facteur*10 en python… Bien sûr à cela tu vas devoir ajouter la mémoire utilisée pour faire ton traitement et tes résultas intermédiare, sauf si c'est négligeable (exemple: pour calculer la moyenne il te faut juste stocker une somme et un compte).
[^] # Re: Moteur SQL
Posté par Mikis . Évalué à 3.
Penser à utiliser zRam. D'autant que (si j'ai bien compris) ce sont des données textuelles et ça se compresse bien.
Et sinon (je suis assez fier d'avoir résisté 24h à poster ça) :
Tu as pensé à le faire avec excel ?
[^] # Re: Moteur SQL
Posté par kr1p . Évalué à 1.
non cest plus de 66000 lignes dans tous mes fichiers
[^] # Re: Moteur SQL
Posté par Mikis . Évalué à 2.
C'était juste une blague. Par contre, la limite des 66000 lignes a sauté depuis longtemps.
[^] # Re: Moteur SQL
Posté par Tonton Th (Mastodon) . Évalué à 2.
$ ulimit -a
# Beaucoup trop vague
Posté par _kaos_ . Évalué à 3.
Salut,
Quel est le problème ? Ne peux-tu pas le paralléliser (dépend de la question précédente) ?
Et bien non. Pour être précis, c'est à chaque tour de GC. Et il y en a plusieurs, certains plus agressifs que d'autres. Et même en déréférençant, ja jvm ne libère pas forcément la mémoire système qu'elle a alloué, pour pouvoir y stocker de nouveaux objets ;)
Matricule 23415
[^] # Re: Beaucoup trop vague
Posté par kr1p . Évalué à 1. Dernière modification le 09 octobre 2020 à 10:44.
paralelliser? cad utiliser plusieurs threads? je n'ai pas encore vu ce concept en python mais seulement en java où la documentation que j'ai lu semblait indiquer que l'ordre d'execution des threads et la priorité était difficile à déterminer soi meme (dire à la machine l'ordre de priorité).
Est ce qu'avec la généralisation des processeurs multicoeurs, l'utilisation de threads multiples permet de gagner en performance?
je vais lire le chapitre sur les threads pr python si cest de ca dont tu parles, je l'ajoute à mes pistes d'optimisation.
[^] # Re: Beaucoup trop vague
Posté par _kaos_ . Évalué à 2. Dernière modification le 11 octobre 2020 à 12:19.
Salut,
C'est toujours impossible de répondre à tes questions, c'est trop vague.
En plus je crois que tu mélange des notions : calcul parallèle vs ordonnancement.
Dès fois oui, dès fois non. Dépend du problème.
Matricule 23415
[^] # Re: Beaucoup trop vague
Posté par kr1p . Évalué à 1.
ben merci de distiller de nouvelles notions théoriques que je ne connais pas, ca me permet d'apprendre, mais si jai pas les tutos pr les appliquer en python ou avec des exemples je comprend moins bien.
désolé si cest flou mais le message d erreur ne me precise rien.
je fais simplement des boucles sur deux listes issues de deux fichiers distincts pour faire des calculs mathematiques simples entre des données numeriques.
[^] # Re: Beaucoup trop vague
Posté par _kaos_ . Évalué à 2. Dernière modification le 13 octobre 2020 à 08:48.
Salut,
Je ne parle pas de l'erreur, mais du problème que tu cherche à résoudre :)
Matricule 23415
[^] # Re: Beaucoup trop vague
Posté par YetiBarBar . Évalué à 1.
Bonjour,
L'erreur "Processus arrêté" est beaucoup trop vague pour qu'on puisse t'aider. Il faudrait un peu plus de matière pour trouver ce qui ne va pas!
Sans plus d'infos sur ce que tu fais, difficile de t'aider pour écarter toutes les pistes qui peuvent "mal se passer".
[^] # Re: Beaucoup trop vague
Posté par kr1p . Évalué à 1.
je n'ai rien de plus comme message d'erreur pour la raison du plantage.
j'ouvre un fichier de quelque centaines de Mo que je modifie à partir d'une dizaine d'autres fichiers de meme taille.
oui chaque fichier objet est bien fermé à chaque fois.
je charge un fichier csv dans une liste et un autre dans une autre liste et je fais des calculs entre les données de chaque liste par boucles recursives.
2500 niveaux d'appels récursifs ca veut dire quoi? mes boucles font bien plus que 2500 itérations.
# Pandas, Numpy, etc.
Posté par Atem18 (site web personnel) . Évalué à 3.
Si je comprends bien, on dirait du calcul scientifique.
Je regarderais du côté des Pandas pour optimiser facilement sans trop se fouler : https://scls.gitbooks.io/initiation-a-python-pour-le-traitement-de-donnees/content/04_pandas.html
En gros, tu charge un fichier csv avec tes données et ça va te créer un dataframe (en gros c'est une table sql en mémoire)
import pandas as pd
filename = 'chemin/vers/fichier.csv'
df = pd.read_csv(filename)
Et ensuite, tu peux appliquer des fonctions sur ce dataframe. Exemple:
def square(x):
return x ** 2
df.apply(square)
Un autre site pour l'exemple : http://www.python-simple.com/python-pandas/panda-intro.php
À noter que Pandas se base aussi sur Numpy, donc ça peut être une bonne chose de regarder après de ce côté là pour encore optimiser.
Enfin si tu veux lancer plusieurs calculs en même temps, tu as asyncio.
[^] # Re: Pandas, Numpy, etc.
Posté par kr1p . Évalué à 1.
merci pr la piste, je ne suis pas sur d'avoir le temps d'ingurgiter la doc de panda mais je le met sur ma liste des trucs à verifier
[^] # Re: Pandas, Numpy, etc.
Posté par Atem18 (site web personnel) . Évalué à 2.
Pas besoin, il suffit d'y aller étape par étape. Tu peux déjà commencé avec les quelques lignes que je t'ai donné, ça peut suffire pour ton besoin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.