Discussion :

[_Froggy_]

Hello tout le monde,

Actuellement j'ai le programme suivant :
1/ Un module déclenche une interruption
2/ L'interruption est détectée via GPIO.wait_for_edge
3/ Le raspberry pi zero récupère les données
4/ Le raspberry pi zero écrit les données dans une bdd SQLite sur sa carte SD

Le problème, c'est que cela prend grosso modo 60ms dont 50ms pour la partie 4 et potentiellement, le module peut balancer une interruption toutes les 20ms et actuellement, j'ai une probabilité de perdre des données.
Dit autrement, sur 1s, je peux avoir entre 50 données ou 0.

En gros mon idée, c'est de créer d'autres process qui ne feraient que de l'écriture en parallèle pour que la priorité reste à la récupération des données.

Mais pour le coup, entre threading & multiprocessing, j'ai un peu du mal à voir lequel utilisé. Sachant que comme c'est une BDD SQLite, si les threads/process pouvaient avoir une fonction lock, cela serait cool.

Question annexe (pour du multicore), est-ce qu'il est possible de dire à python de s'executer sur le core 2 par exemple ?

Merci

[tyrtamos]

Bonjour

A ma connaissance, sqlite3 n'étant pas un serveur, ne supporte pas les accès simultanés.

Threading et multiprocessing comportent des verrous. Pour multiprocessing, qui a été intelligemment construit de façon similaire à threading, les verrous sont ici: https://docs.python.org/fr/3.10/libr...rocessing.Lock. Il ne reste plus qu'à apprendre à s'en servir...

A ma connaissance aussi, python ne peut pas choisir un cœur du CPU: c'est l'OS qui le fait. A noter que si on parle d'une exécution multi-core du CPU, il faut choisir multiprocessing, et non threading qui ne s'exécute que sur un seul cœur.

[fred1599]

Bonjour,

Avec SQLite3 on peut faire de l'asynchronisme : aiosqlite

Ensuite, il n'y a pas 36 solutions, déjà faut savoir qu'il n'y a pas plus rapide que la RAM. Conclusion : Minimiser le temps d'accès à la base de données !

1. Stocker les données en mémoire dans une file d'attente.
2. Écrire toutes les données en une seule transaction dans la base de données (on appelle cela des transactions batch) avec une boucle for par exemple et une fois le bloc terminé, on commit l'insertion.

Autre solution: Passer par un serveur Redis, beaucoup plus efficace que SQLite3 en écriture, puis une fois toutes les données stockées, les transférer sur la base de données SQLite.

Peut-être qu'une solution moins simple que les précédentes comme un système de messagerie (kafka, RabbitMQ, ...) pourrait faire l'affaire, mais je pense que la complexité dépasse peut-être le besoin actuel.

[_Froggy_]

[*]Stocker les données en mémoire dans une file d'attente.

Dans ma tête, la création d'un autre thread/process faisait justement fonction de stockage temporaire en mémoire sans que j'ai à faire de gestion d'un buffer d'écriture. J'ai par ailleurs pas de nécessité d'écriture FIFO. Il est évident qu'une vraie gestion de buffer serait plus optimise. Je vois bien comment en faire un dans ma tête : un second process à qui je donne les données en écriture, mais je vois pas comment le concevoir en python autrement qu'avec un process "serveur".
Pour l'instant, le Pi Zero est un monocore au départ l'idée était d'utilisé un Pi Zero 2 4 core mais les prix sont encore totalement délirants.

Question annexe, si j'utilise threading, comment se réparti l'utilisation processeur ? C'est à dire que si j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
def ecriture_donnees():
 bdd.insert()
 bdd.commit()
 
try:
 while(true)
  gestion_interruption()
  threading (ecriture_donnees())

Le bdd.commit() du thread me prend 50ms (temps d'écriture sur la SD je pense). Est-ce que pendant ces 50ms d'attente d'I/O, l'interpréteur python continue la boucle try: ?

Après relecture de la doc SQLite, il y a une gestion interne à SQLite de l'écriture en parallèle, donc pas besoin de gestion de lock par les threads/process.

Je pense qu'à terme, je ferais la gestion de l'IRQ en C, pour optimiser le bouzin en mode *boum* quand il y a une interruption, plus qu'un wait_for_edge

Autre solution: Passer par un serveur Redis, beaucoup plus efficace que SQLite3 en écriture, puis une fois toutes les données stockées, les transférer sur la base de données SQLite.

J'avais réfléchis à cela en version plus garbage, le fichier stocker sur la SD, copier dans une ramFS au démarrage et un crontab qui sauvegarde toutes les x minutes. Je connaissais pas Redis, je vais voir ça

Mais c'est la conception de votre application qu'il faut étudier: python n'a pas grand chose à faire là dedans sinon dans les détails de réalisation.

- W

Dans ma tête c'est plus ou moins claire, la question c'est comment le réaliser. Comme répondu au dessus, le mieux serait un second process qui ne gère que l'écriture. Donc s'il y a 3 trames de données pendant une écriture, à l'écriture suivante, il écrit les 3 trames d'un coup. Mais je ne vois pas comment l'écrire.

------

Merci pour vos réponses

[wiztricks]

Le bdd.commit() du thread me prend 50ms (temps d'écriture sur la SD je pense). Est-ce que pendant ces 50ms d'attente d'I/O, l'interpréteur python continue la boucle try: ?

Ce sera une mixture d'entrées sorties (ou le thread perd le CPU pour faire avancer l'autre) et de CPU pour les effectuer.
Maintenant, vous n'allez pas démarrer un thread à chaque fois mais mettre un tampon/buffer entre les deux.

Dans ma tête c'est plus ou moins claire, la question c'est comment le réaliser. Comme répondu au dessus, le mieux serait un second process qui ne gère que l'écriture. Donc s'il y a 3 trames de données pendant une écriture, à l'écriture suivante, il écrit les 3 trames d'un coup. Mais je ne vois pas comment l'écrire.

Comme vous n'avez qu'un CPU, il va falloir faire avec threads ou asyncio. Et si vous faites avec des threads, il y a Queue pour créer ce tampon. Ceci dit comme vous ne contrôlez pas grand chose, ça ne marchera peut être pas (et Python n'est pas forcément adapté pour être réactif).

- W

[umfred]

Est-ce que tu as testé de mettre ta base sur une clé USB plutôt que sur la SD ? Il me semble que c'est plus rapide.

[wiztricks]

En gros mon idée, c'est de créer d'autres process qui ne feraient que de l'écriture en parallèle pour que la priorité reste à la récupération des données.

C'est une bonne idée. Mais côté réalisation, çà veut dire déconnecter le temps mis pour récupérer les données avec celui pris pour les écrire via un "buffer" qu'on peut remplir aussi vite que nécessaire et regrouper les écritures pour qu'elles prennent un minimum de temps (histoire que le buffer ait le temps de se vider).
note: on ne parallélise pas les écritures, on les regroupe pour que çà prenne le moins de temps possible: s'il faut une seconde pour recevoir 5 messages toutes les 20ms, on espère pouvoir qu'écrire ces 5 messages d'un seul coup prendra (beaucoup moins).

Reste à savoir quelle devra être la nature du "buffer": ce peut être de multiples fichiers séquentiels, des sockets (on expédie ce qu'il y a à écrire à un serveur), de la mémoire partagée (entre threads ou entre process).

Mais c'est la conception de votre application qu'il faut étudier: python n'a pas grand chose à faire là dedans sinon dans les détails de réalisation.

- W

[fred1599]

Hello,

@wiztricks,

Je comprends où tu veux en venir, sur le fait que le GIL ne change pas les fondements de la programmation concurrente et parallèle.

[tyrtamos]

Bonjour

Je lis avec intérêt, tout en ne comprenant pas toutes les subtilités techniques du GIL. Je peux cependant témoigner, pour l'avoir utilisé de nombreuses fois, que le calcul parallèle exploitant les CPU multicores fonctionne très bien. Avec quelques exemples, on montre facilement qu'avec un tel CPU avec 4 cœurs et l'option processus (ProcessPoolExecutor) du module concurrent.futures, on divise par au moins 3 le temps de calcul. Cela n'est pas vrai, bien sûr, avec les threads.

[_Froggy_]

Merci pour les réponses.
Bon, j'ai testé dans un premier temps uniquement via python et au bout de quelques heures, le script ou le GPIO ne répond plus aux interruptions (peut être un bug que j'ai loupé).

J'ai commencé à presque arrêter de faire ma feignasse pour une version C (pour la détection des interruptions) en faisant mon dev (c) google + system("python") pour avoir quelque chose de presque fonctionnel. Cela a fonctionné un premier temps, puis au re-lancement du programme pour une raison inconnue, plus de détection des interruptions. Il faut que j'explore, savoir si c'est le raspberry qui déconne, mon programme, l'appel des int ou les trois.

(oui c'est sale ^^)

----------

Pour préciser, j'écris à chaque int, dans 2 tables, une de log et une de data, ce qui représente pas grand chose (100o/table environ)

[wiztricks]

Il faut que j'explore, savoir si c'est le raspberry qui déconne, mon programme, l'appel des int ou les trois.

Si le programme doit tourner en permanence, il devrait pouvoir sauvegarder des informations sur son état dans un journal, histoire de comprendre ce qui s'est passé après coup.... puis éventuellement essayer de redémarrer.

En fait, lire des données et les écrire, est la partie la plus facile...

- W

[fred1599]

Le code ci-dessous est déjà un problème de performance, d'où mon intervention en faisant de l'insertion "batch"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def ecriture_donnees(): 
    bdd.insert()
    bdd.commit()

ce que je proposerai serait plutôt du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
def ecriture_donnees(donnees):
    for donnee in donnees:
        bdd.insert(...)
    bdd.commit()

donnees est l'ensemble des données en mémoire (par exemple une liste ou un ensemble (set) python), ça implique une seule écriture en base, plutôt que de multiples comme tu le proposes.

Perso, avant de voir du côté du C, je pense qu'il faut faire des essais et voir ce que ça donne, mais des essais optimisés en python, car même en C, si tes idées sont présentées de la même manière que ce que tu fais en python, tu feras du C non optimisé.

[wiztricks]

donnees est l'ensemble des données en mémoire (par exemple une liste ou un ensemble (set) python), ça implique une seule écriture en base, plutôt que de multiples comme tu le proposes.

L’intérêt d'un "bulk" insert est de remplacer la boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
   for donnee in donnees:
        bdd.insert(...)

par:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

   bdd.bulk_insert(données)

note: avec sqlite, bulk_insert = executemany.

On réduit le temps CPU en remplaçant N appels au SGDB par un seul et on permet au SGDB d'optimiser les écritures disques (un SGDB est un peu plus compliqué qu'un fichier séquentiel).

- W

[fred1599]

L’intérêt d'un "bulk" insert est de...

Exactement c'est le principe que je voulais montrer, je connais pas assez SQLite, je suis plutôt PostgreSQL, mais executemany est bien la solution adéquate pour SQLite.

On réduit le temps CPU en remplaçant N appels au SGDB par un seul et on permet au SGDB d'optimiser les écritures disques (un SGDB est un peu plus compliqué qu'un fichier séquentiel).

Tout à fait !

[wiztricks]

Exactement c'est le principe que je voulais montrer, je connais pas assez SQLite, je suis plutôt PostgreSQL, mais executemany est bien la solution adéquate pour SQLite.

Avec postgresql, ça dépend de l'interface offerte par le pilote. pyscopg2 étant le plus populaire connaît executemany et execute_values (beaucoup plus rapide).
Ceci dit, reste le soucis SQLIte vs. accès concurrents car si on y écrit des choses, il va bien falloir les relire de temps en temps.

- W

[jurassic pork]

Hello,
A lire ceci aussi : Optimizing SQLite on Raspberry Pi

dont la conclusion est :

If your goal is to improve performance using SQLite, definitely try to group as many operations as you can into a single transaction.

ce qui rejoint ce que propose fred1599.

Ami calmant, J.P

[fred1599]

Avec postgresql, ça dépend de l'interface offerte par le pilote. pyscopg2 étant le plus populaire connaît executemany et execute_values (beaucoup plus rapide).

Je passe par un intermédiaire, plus précisément l'ORM Django

[fred1599]

Hello,

@wiztricks,

Ok pour la solution, mais me vient une question sur le choix de concevoir ce type de solution.

Pourquoi utiliser les threads et non les tâches asynchrones par exemple ? Il me semble avoir déjà lu que les threads sont assez consommateurs mémoire, sachant qu'on est sur un support mémoire limité (Raspberry Pi Zero).

[wiztricks]

Pourquoi utiliser les threads et non les tâches asynchrones par exemple ? Il me semble avoir déjà lu que les threads sont assez consommateurs mémoire, sachant qu'on est sur un support mémoire limité ([/SIZE]Raspberry Pi Zero).

Pour que çà ait un réel avantage, il faudrait avoir à multiplexer un tas d'entrées sorties. Ici, on a juste la lecture du port GPIO (qui chez moi est simulé par un time.sleep et l'ajout d'un tuple dans le buffer) et l'écriture "bulk" dans la base de donnée. Par contre, çà a des inconvénients: utiliser une bibliothèque externe pour sqlite3, je ne sais pas ce qu'on peut faire côté GPIO, un style de programmation différent (on passe de séquentiel à évènementiel plus ardu),...

Si on veut faire mieux côté PiZero, je n'écrirais pas en BDD locale mais me contenterai de pousser les données sur le réseau et de les récupérer sur un serveur. On pourra aussi les regrouper si nécessaire, mais côté process, on attend le temps d'une copie mémoire: pas évident qu'il soit nécessaire d'avoir un asynchronisme explicite (dans le code): une boucle avec des conditions...

- W

[fred1599]

Super, merci !

J'aime bien ton principe KISS... le fait de donner une solution simple avant de rentrer dans des considérations plus complexes.

Externaliser le stockage me semble une excellente idée aussi !

Dans la complexité des tâches asynchrones qui sont faut avouer, plus sur la partie apprentissage, on pourrait aussi dire que les threads peuvent être complexes sur leur gestion (problème de concurrences).

Aussi le GIL est une partie importante à ne pas prendre à la légère, on a pas un vrai parallélisme, car un seul thread à la fois sera utilisé sur le processus, ce qui veut dire qu'on pourrait complexifier en ajoutant des modules tels que multiprocessing par exemple.
Malgré le fait que le GIL n'affecte pas autant les tâches qui sont I/O bound, c'est un point que l'on ne devrait pas négliger.