Il s'avère que le problème décrit est principalement dû à une utilisation inappropriée de SQLite. La conception précédente consistait à ouvrir une connexion jusqu'à ce que la vérification de tous les agents du pool d'agents soit terminée et qu'un certain nombre d'agents soient capturés avant de fermer la connexion. connexion, et à chaque fois Lors de l'ajout, de la modification ou de la suppression d'informations sur l'agent, des fichiers de données sont écrits, ce qui entraîne le verrouillage prolongé de SQLite à gros grains.

Après avoir découvert ce problème, nous l'avons optimisé. Après avoir lu l'agent d'inventaire au début de la nouvelle connexion, nous avons immédiatement fermé la connexion. Après cela, toutes les données nouvelles, mises à jour et supprimées de l'agent sont temporairement stockées dans des variables de classe jusqu'à ce que. tous les agents requis sont obtenus. Ensuite, ouvrez une nouvelle connexion, mettez à jour les données avec executemany, puis fermez la connexion, terminez la tâche planifiée et la vitesse augmentera.

Cependant, je n'arrive toujours pas à comprendre pourquoi dans la situation d'origine, le mécanisme de planification des threads permet au thread bloqué par la base de données d'occuper toujours des ressources au lieu de changer dans le temps ?

Votre fil de discussion est donc bloqué au niveau de l'écriture dans la base de données. Puisque vous utilisez sqlite, laissez-moi vous donner un autre pouvoir ancien pour accélérer l'opération d'écriture dans la base de données :

import sqlite3

...
conn = sqlite3.connect('xxx.db')
cur = conn.cursor()
cur.execute("CREATE TABLE xxx")  # 建个表
cur.execute("PRAGMA synchronous = OFF")  # 关闭磁盘同步
cur.execute("BEGIN TRANSACTION")  # 开始事务处理
cur.executemany("INSERT INTO names VALUES (?,?)", lst)  # 批量插入爬到的数据
conn.commit()
conn.close()
...

Trois méthodes sont utilisées pour accélérer la sqlitevitesse d'écriture

1. Désactiver la synchronisation des disques

2. Transactions SQLite

3. exécuter de nombreuses insertions par lots

PS : De plus, si vous disposez de suffisamment de mémoire, vous pouvez jeter le fichier de base de données dans le répertoire tmpfs, ce qui éliminera grandement l'impact des E/S disque (équivalent à une écriture directe en mémoire)