Ça serait bien d'intégré le classement par date d'entrée et de mise à jours des paquets! je pense que ça ne doit être bien compliqué à faire!
Analyse des performances de YUM
D'intégrer dans quoi? dans le gestionnaire de dépendances avancées? Les interfaces graphiques fournissent quelques éléments... Cependant:
=> date de construction du paquetage
=> interrogation des paquetages installés et classement par date d'installation
# rpm -q --qf "%{NAME}\t%{INSTALLTIME:date}\n" nom_du_paquetage
# rpm -q --qf "%{NAME}\t%{BUILDTIME:date}\n" nom_du_paquetage
rpm -q --last liste_de_paquetage=> date de construction du paquetage
=> interrogation des paquetages installés et classement par date d'installation
@remi : quel base de donnée? yum utilise un fichier xml present sur le depot !(non?)
@Sat : quand je suis arrivé de kubuntu(oui je sais mais y a un debut a tout) la premiere chose que je me suis dit c'est : "oula c'est lent leur yum"
et c'est pas une question de 1 seconde quand tu as tout tes softs a installer.
mais je reconnais que pour optimiser l'algorithmique python est plus pratique.
pour faire une update vide 13 secondes ... c'est pire ! ca serait pas possible de juste verifier si les xml ont été modifiés?(je suis surement a coté de la plaque mais au moin j'apprendrais quelque chose!)
@Sat : quand je suis arrivé de kubuntu(oui je sais mais y a un debut a tout) la premiere chose que je me suis dit c'est : "oula c'est lent leur yum"
et c'est pas une question de 1 seconde quand tu as tout tes softs a installer.
mais je reconnais que pour optimiser l'algorithmique python est plus pratique.
pour faire une update vide 13 secondes ... c'est pire ! ca serait pas possible de juste verifier si les xml ont été modifiés?(je suis surement a coté de la plaque mais au moin j'apprendrais quelque chose!)
- Modifié
le dossier /var/lib/rpm est une base de données Berkeley DB
les fichiers /var/cache/yum/*/*.sqlite sont des bases de données SQLite V3
A+
les fichiers /var/cache/yum/*/*.sqlite sont des bases de données SQLite V3
A+
dans les outils graphique! style yumex!
Mon avis perso sur les perf, ben il est plutot négatif à la vue de ce papier.
En tout cas par rapport au temps d'execution (3eme tableau)
Les grosses maj sont améliorées très significativement, pas contre les petites (au final, celles de tous les jours) sont plutot en baisse.
En tout cas, à plus long terme, il semble que la réécriture du moteur de traitement des dépendances soit prometeuse.
Pour ceux qui ne parlerait pas du tout anglais, l'auteur compare trois versions de yum :
- celle présente dans FC6 (yum 3.0.3) (1ere colonne des tableaux)
- celle de la branche devel - ie celle qui sera présente (à peu pres) dans F7 (2eme colonne)
- et une version qui n'utilise plus rpm mais une reécriture complete (pyrpmyum) qui est en test en ce moment et qu'ils espèrent intégrer dans F8 (Colonne 3)
Plusieurs tests sont fait :
INSTALL
- installation normale (856 paquets)
- installation complete (6057 paquets) - ce qui implique beaucoup d'exclusion de paquets pour résoudre toutes les dépendances
- Grosse installation "[a-k]*" (3052 paquets en comptant les dependances)
UPDATE
- tentative de maj sans maj disponible
- Grosse update
- Dist upgrade (mise à jour de FC5 à FC6)
SUPPRESSION
- suppression de glibc (828 paquets)
Ceci selon 3 criteres dévaluation
- maximum de mémoire allouée (1er tableau)
- total de memoire allouée (2eme tableau)
- temps d'exécution en secondes (3eme tableau)
Voilà, tout devrait etre clair maintenant.
En tout cas par rapport au temps d'execution (3eme tableau)
Les grosses maj sont améliorées très significativement, pas contre les petites (au final, celles de tous les jours) sont plutot en baisse.
En tout cas, à plus long terme, il semble que la réécriture du moteur de traitement des dépendances soit prometeuse.
Pour ceux qui ne parlerait pas du tout anglais, l'auteur compare trois versions de yum :
- celle présente dans FC6 (yum 3.0.3) (1ere colonne des tableaux)
- celle de la branche devel - ie celle qui sera présente (à peu pres) dans F7 (2eme colonne)
- et une version qui n'utilise plus rpm mais une reécriture complete (pyrpmyum) qui est en test en ce moment et qu'ils espèrent intégrer dans F8 (Colonne 3)
Plusieurs tests sont fait :
INSTALL
- installation normale (856 paquets)
- installation complete (6057 paquets) - ce qui implique beaucoup d'exclusion de paquets pour résoudre toutes les dépendances
- Grosse installation "[a-k]*" (3052 paquets en comptant les dependances)
UPDATE
- tentative de maj sans maj disponible
- Grosse update
- Dist upgrade (mise à jour de FC5 à FC6)
SUPPRESSION
- suppression de glibc (828 paquets)
Ceci selon 3 criteres dévaluation
- maximum de mémoire allouée (1er tableau)
- total de memoire allouée (2eme tableau)
- temps d'exécution en secondes (3eme tableau)
Voilà, tout devrait etre clair maintenant.
Je me suis dit la même chose que pingoomax 😉
(par contre moi, la patience ... je l'ai apprise hein ... source oblige ^^)
(par contre moi, la patience ... je l'ai apprise hein ... source oblige ^^)
Un changement de bibliothèque ne va pas accélérer un outil graphique comme Yumex de manière impressionnante…
Pour un outil graphique comme Yumex, la lenteur se fait surtout sentir lors de la mise à jour de la liste des paquets dispos pour chaque dépôt.
Il y a sans doute une meilleure solution que celle qui consiste à rapatrier la liste complète des paquets puis de mettre à jour la base de donnée des paquets disponibles, installés et à mettre à jour.
Je pense qu'il ne devrait pas être nécessaire de rapatrier la liste complète (des milliers de descriptions de paquets) à chaque fois).
Une bonne solution, à mon avis, serait de pouvoir récupérer rapidement d'une manière ou d'une autre, la liste des paquets proposant une mise à jour ou ajoutés depuis le dernier démarrage de Yumex (depuis une date donnée). Ainsi, si on rapatrie uniquement ce qui est nouveau depuis le dernier lancement de l'application et pas 10000 descriptions de paquets.
Pour un outil graphique comme Yumex, la lenteur se fait surtout sentir lors de la mise à jour de la liste des paquets dispos pour chaque dépôt.
Il y a sans doute une meilleure solution que celle qui consiste à rapatrier la liste complète des paquets puis de mettre à jour la base de donnée des paquets disponibles, installés et à mettre à jour.
Je pense qu'il ne devrait pas être nécessaire de rapatrier la liste complète (des milliers de descriptions de paquets) à chaque fois).
Une bonne solution, à mon avis, serait de pouvoir récupérer rapidement d'une manière ou d'une autre, la liste des paquets proposant une mise à jour ou ajoutés depuis le dernier démarrage de Yumex (depuis une date donnée). Ainsi, si on rapatrie uniquement ce qui est nouveau depuis le dernier lancement de l'application et pas 10000 descriptions de paquets.
Yumex n'est qu'une interface graphique qui appelle yum.
Donc améliorer yumex se limite à améliorer l'interface.
Ton idée de mise à jour différentielle est déjà en cours de développement.
Enfin c'est un truc plus compliqué que ce dont tu parles.
Cf : https://hosted.fedoraproject.org/projects/presto
Donc améliorer yumex se limite à améliorer l'interface.
Ton idée de mise à jour différentielle est déjà en cours de développement.
Enfin c'est un truc plus compliqué que ce dont tu parles.
Cf : https://hosted.fedoraproject.org/projects/presto
Vraiment parfois on touche le fond.baptistoux wrote:Il était temps qu'il s'occupe un peu d'accelerer 'yum', car ça lenteur par rapport a d'autres outils du meme types sur d'autre distrib est une critique récurrente.
Tu devrais installer toutes les Fedora depuis le début, une part une et dans l'ordre, et te rendre compte à quel yum s'est amélioré de version en version.
@yohann : la recuperation de la liste des paquets dispo est tributaire de la vitesse des serveurs,
non pas de la gui qui mise a part demander plus de ressource pour mettre a jours les widjets n'intervient pas sur le telechargement.elle ne devient un poid qu'au moment de la resolution des dependances qui demande deja a elle seule beaucoup de ressource.donc changer le moteur de dependance pour un plus rapide(moin de temp processeur) ameliore l'ensemble des performances de l'outil graphique.
dans ton idée c'est sutout les depots qu'il faudrait former differrament.splitter la liste en plusieur morceau et un petit fichier qui tiendrait compte des changements des ces morceaux.
non pas de la gui qui mise a part demander plus de ressource pour mettre a jours les widjets n'intervient pas sur le telechargement.elle ne devient un poid qu'au moment de la resolution des dependances qui demande deja a elle seule beaucoup de ressource.donc changer le moteur de dependance pour un plus rapide(moin de temp processeur) ameliore l'ensemble des performances de l'outil graphique.
dans ton idée c'est sutout les depots qu'il faudrait former differrament.splitter la liste en plusieur morceau et un petit fichier qui tiendrait compte des changements des ces morceaux.
@pingoomax :
pas tout a fait non plus yumex est basé sur la lib de yum mais ne se contente pas d'executer des batchs
pas tout a fait non plus yumex est basé sur la lib de yum mais ne se contente pas d'executer des batchs
- Modifié
Oui, je sais bien.pingoomax wrote:Yumex n'est qu'une interface graphique qui appelle yum.
Donc améliorer yumex se limite à améliorer l'interface.
Ton idée de mise à jour différentielle est déjà en cours de développement.
Mais la particularité de Yumex, c'est qu'il doit afficher la liste complète des paquets, afin que l'utilisateur puisse faire son choix dans cette liste (et pour ça il utilise effectivement yum, c'est ça le pb, car yum gere ça très mal). Quand j'utilise yum en ligne de commande, je fait d'abord un yum search (si je ne sais pas si le paquet est dispo) puis un yum update, ce qui est bien plus rapide.
Donc, en attendant un yum qui gère ça, Yumex pourrait très bien gérer ça tout seul (en proposant une sorte de « serveur proxy » permettant de ne renvoyer que ce qui est nécessaire :
Application Yumex (1) <--> Serveur Yumex (2) <--> Serveur de dépôt (3)
- (2) interroge (3) périodiquement pour mettre à jour sa propre base.
- (1) interroge (2) avec la date du dernier acces.
- (2) renvoie à (1) la liste des nouvelles descriptions de paquets (ou mises à jour) qu'il a obtenu de (3) depuis cette date.
En effet, c'est un peu lourd (au niveau archi et infrastructure à mettre en place). Une meilleure solution à terme serait effectivement une réorganisation des dépôts à la base comme tu le suggère :
Et bien sûr, c'est une bonne chose d'améliorer l'algo de gestion des dépendances, mais c'est un autre problème de perf.ded wrote:c'est surtout les dépôts qu'il faudrait former différemment. splitter la liste en plusieurs morceau et un petit fichier qui tiendrait compte des changements des ces morceaux.
Bonjour,
On ne parle pas de smart ni de smart-gui, je l'utilise, il est plus rapide que yum et gère bien les dépendances. Mais je ne suis pas suffisamment compétent pour comparer ces deux outils, aussi, pourrais-je avoir quelques précisions sur l'intérêt de l'un ou de l'autre ?
cymru
On ne parle pas de smart ni de smart-gui, je l'utilise, il est plus rapide que yum et gère bien les dépendances. Mais je ne suis pas suffisamment compétent pour comparer ces deux outils, aussi, pourrais-je avoir quelques précisions sur l'intérêt de l'un ou de l'autre ?
cymru
Smart et son interface graphique relève du même champ fonctionnel général que Yum-Ymex (ou autres environnements graphiques) : ils sont tous deux des gestionnaires de dépendances avancés (ils permettent d'installer, supprimer, mettre à jour des paquetages en résolvant toutes les dépendances à l'aide de dépôts).
Smart et Smart-gui présentent cependant quelques avantages significatifs:
1- ils savent très correctement gérer les retours arrière (revenir à une version précédente d'un rpm en traitant toutes les dépendances avancées) et permettent ainsi de régler quelques douloureux cas liés à des mélanges de dépôts ...
2- les téléchargements sont réalisés en parallèle; en d'autres termes, quand plusieurs dépôts sont attaqués, les téléchargements sont parallélisés en sorte que le blocage d'un dépôt n'entraîne pas le blocage complet (ce qui est le cas de Yum);
3- ils disposent de fonctionnalités de traitement des anomalies (ils permettent de détecter les rpm pour lesquels des dépendances ne peuvent être réglées par exemple ... et fixent certaines petites anomalies);
4- ils supportent sans aucun préalable des dépôts locaux (sur disque dur par exemple), au contraire de Yum qui réclame un utilitaire particulier (createrepo) et demande que cet utilitaire soit passé systématiquement à chaque modification du dépôt local; à noter aussi qu'ils supportent tous les supports amovibles possibles;
5- ils gèrent différents formats de dépôts (le format de dépôt de Yum, soit MetaData rpm, mais aussi d'autres formats dont URPMI, apt etc ....); dès lors Smart - Smart-gui sont des outils 'multi canaux'.
Je ne discute pas là l'interface graphique; à ce titre, je suggère que Smart-gui est bien supérieur à Yumex en permettant une description profonde et simple des différentes dépendances d'un paquetage (dépendances amont et dépendances aval) mais ce dernier thème va sans doute susciter du blabla alors que l'essentiel n'est pas là mais dans les 5 points précédents ...
On l'aura compris, je suis un utilisateur fidèle de Smart. Certains diront que les performances de Smart ne sont pas celles d'apt ou de yum mais de très fondé n'est avancé et il convient de relativiser le propos en tenant compte des fonctionnalités apportées:
* le téléchargement en parallèle amène des gains significatifs (pourvu que la liaison soit de bonne capacité)
* la constitution d'une méta représentation des différents paquetages, systématique à chaque mise à jour, consomme effectivement du temps mais elle est la contre partie de la volonté de Smart de gérer plusieurs formats de dépôts dont le fameux dépôt local (un répertoire de rpm par exemple ...), ce que Yum ne sait pas faire.
Je ne doute pas que la question des performances soit aussi un sujet de blabla, alors que l'essentiel n'est pas vraiment là.
Smart et Smart-gui présentent cependant quelques avantages significatifs:
1- ils savent très correctement gérer les retours arrière (revenir à une version précédente d'un rpm en traitant toutes les dépendances avancées) et permettent ainsi de régler quelques douloureux cas liés à des mélanges de dépôts ...
2- les téléchargements sont réalisés en parallèle; en d'autres termes, quand plusieurs dépôts sont attaqués, les téléchargements sont parallélisés en sorte que le blocage d'un dépôt n'entraîne pas le blocage complet (ce qui est le cas de Yum);
3- ils disposent de fonctionnalités de traitement des anomalies (ils permettent de détecter les rpm pour lesquels des dépendances ne peuvent être réglées par exemple ... et fixent certaines petites anomalies);
4- ils supportent sans aucun préalable des dépôts locaux (sur disque dur par exemple), au contraire de Yum qui réclame un utilitaire particulier (createrepo) et demande que cet utilitaire soit passé systématiquement à chaque modification du dépôt local; à noter aussi qu'ils supportent tous les supports amovibles possibles;
5- ils gèrent différents formats de dépôts (le format de dépôt de Yum, soit MetaData rpm, mais aussi d'autres formats dont URPMI, apt etc ....); dès lors Smart - Smart-gui sont des outils 'multi canaux'.
Je ne discute pas là l'interface graphique; à ce titre, je suggère que Smart-gui est bien supérieur à Yumex en permettant une description profonde et simple des différentes dépendances d'un paquetage (dépendances amont et dépendances aval) mais ce dernier thème va sans doute susciter du blabla alors que l'essentiel n'est pas là mais dans les 5 points précédents ...
On l'aura compris, je suis un utilisateur fidèle de Smart. Certains diront que les performances de Smart ne sont pas celles d'apt ou de yum mais de très fondé n'est avancé et il convient de relativiser le propos en tenant compte des fonctionnalités apportées:
* le téléchargement en parallèle amène des gains significatifs (pourvu que la liaison soit de bonne capacité)
* la constitution d'une méta représentation des différents paquetages, systématique à chaque mise à jour, consomme effectivement du temps mais elle est la contre partie de la volonté de Smart de gérer plusieurs formats de dépôts dont le fameux dépôt local (un répertoire de rpm par exemple ...), ce que Yum ne sait pas faire.
Je ne doute pas que la question des performances soit aussi un sujet de blabla, alors que l'essentiel n'est pas vraiment là.
Merci herrib, toujours aussi clair, net, précis et concis.
cymru
cymru
pour smart tout a fait daccord c'est un super outil, smart-gui par contre m'agace: tout le temp en train de mettre a jour le cache,de l'enregister ce qui bloque l'utilisateur
moi qui préfere les gui en general, j'ai adopté la cli pour smart et yum
moi qui préfere les gui en general, j'ai adopté la cli pour smart et yum
Effectivement, Smart est une alternative plus que crédible à Yum pour l'utilisateur mais pas pour le projet Fedora. Fedora a besoin d'un gestionnaire de dépendances fortement intégré à la distribution que ce soit dans l'installeur, le système de build, l'outils de génération d'images isos .... etc bref, ce que ne permet pas Smart.
Après, depuis que apt4rpm, smart et yum reconnaissent le même format de dépôt, ce n'est plus vraiment un souci, les utilisateurs peuvent utiliser ce qu'ils veulent, c'est leur droit.
PS: Yum gère désormais les downgrades via un plugin ...
Après, depuis que apt4rpm, smart et yum reconnaissent le même format de dépôt, ce n'est plus vraiment un souci, les utilisateurs peuvent utiliser ce qu'ils veulent, c'est leur droit.
PS: Yum gère désormais les downgrades via un plugin ...