Aptitude update interminable

Support Debian
#1

Bonjour,

J’ai un serveur debian stable sur une cubieboard, (processeur arm A10, 1Go ddr2).
L’installation est une debian de base (sans x), il y a nginx, prosodi, mpd et postfix qui tournent dessus.

Lorsque je lance la commande aptitude update, c’est interminable, et ça me bloque complètement la machine (plus possible d’utiliser mutt ou vim) :

Le CPU est à 100% tout du long. Seuls 300 à 400 Mo de ram sont utilisés.

Lorsque je lance aptitude safe-upgrade ensuite, je n’ai pas de problèmes de lenteur, ni pour télécharger les paquets, ni pour leur installation / configuration :

Ça ne semble pas venir de la bande passante :

[code]# iperf -s 11 mars 14:03:08

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[ 4] local 192.168.1.101 port 5001 connected with 192.168.1.103 port 37098
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 78.4 MBytes 65.4 Mbits/sec[/code]

Voici mon /etc/apt/sources.list:

1 ## wheezy 2 deb http://ftp.fr.debian.org/debian/ wheezy main contrib 3 deb-src http://ftp.fr.debian.org/debian/ wheezy main contrib 4 5 deb http://security.debian.org/ wheezy/updates main contrib 6 deb-src http://security.debian.org/ wheezy/updates main contrib 7 8 # testing 9 deb http://ftp.fr.debian.org/debian/ testing main contrib non-free 10 deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free 11 12 13 # testing security 14 deb http://security.debian.org/ testing/updates main contrib non-free 15 deb-src http://security.debian.org/ testing/updates main contrib non-free 16 17 18 # sid 19 deb http://ftp.fr.debian.org/debian/ sid main contrib non-free 20 deb-src http://ftp.fr.debian.org/debian/ sid main contrib non-free

#2

[quote=“LAV-FRED”]Bonjour,

J’ai un serveur debian stable sur une

Voici mon /etc/apt/sources.list:
1 ## wheezy
2 deb ftp.fr.debian.org/debian/ wheezy main contrib
3 deb-src ftp.fr.debian.org/debian/ wheezy main contrib
4
5 deb security.debian.org/ wheezy/updates main contrib
6 deb-src security.debian.org/ wheezy/updates main contrib
7
8 # testing
9 deb ftp.fr.debian.org/debian/ testing main contrib non-free
10 deb-src ftp.fr.debian.org/debian/ testing main contrib non-free
11
12
13 # testing security
14 deb security.debian.org/ testing/updates main contrib non-free
15 deb-src security.debian.org/ testing/updates main contrib non-free
16
17
18 # sid
19 deb ftp.fr.debian.org/debian/ sid main contrib non-free
20 deb-src ftp.fr.debian.org/debian/ sid main contrib non-free
[/quote]

Tout est dans le gras.

#3

Si si c’est bien une stable, j’ai un fichier de préférences à côté de mon sources.list
et j’ai juste fait du pinning pour récupérer la dernière version de mpd.

Mais même si j’étais en sid, ça n’explique pas le fait que la commande aptitude update ait besoins de 40 minutes avec le processeur à fond pour télécharger 8 732 ko…
Surtout quand juste après aptitude safe-upgrade télécharge 13Mo en 12s, et installe tout sans manger plus de 50% de processeur.

#4

Ça peut venir des lignes deb-src et aussi de la date du dernier update : il y a alors téléchargement de nombreux fichiers diff puis recomposition de la base de donnée ce qui peut-être long et gourmand, en effet.

#5

Si si c’est bien une stable, j’ai un fichier de préférences à côté de mon sources.list
et j’ai juste fait du pinning pour récupérer la dernière version de mpd.

Mais même si j’étais en sid, ça n’explique pas le fait que la commande aptitude update ait besoins de 40 minutes avec le processeur à fond pour télécharger 8 732 ko…
Surtout quand juste après aptitude safe-upgrade télécharge 13Mo en 12s, et installe tout sans manger plus de 50% de processeur.[/quote]

Le processeur n’a rien à voir là dedans. Il y a un utilitaire dont le nom m’échappe qui teste le serveur le mieux à même de te servir. Sur quel dépot s’attarde apt-get?

#6

Donc il vaudrait mieux faire les mises à jour plus souvent pour qu’elles soient plus rapides.
En ce moment je dois mettre le serveur à jour toutes les 2 semaines environ.
C’est vrai que si je lance un aptitude update maintenant (soit quelques heures après celui qui a causé problème,
ça ne prend plus que :

ce qui est incomparable.
Sinon c’est le process /usr/lib/apt/methods/rred qui mange toute la puissance processeur (et c’est toujours le cas mais pendant 1 minute 40 c’est mieux :smiley:).

#7

Ça doit être apt-spy, je l’ai utilisé à une époque.
Je vais ré-essayer, mais ça ne bloque pas sur un dépôt en particulier, c’est l’ensemble qui est très lent.

Merci en tous cas :wink:

#8

J’ai limité le chargement en spécifiant des langues:

Acquire::Languages { "fr"; "en"; "none" }; Acquire::GzipIndexes "true";mais il faut nettoyer /var/lib/apt/lists

#9

Je vais essayer ça aussi merci,
mais j’ai vraiment l’impression que jcsm33 a raison: ça vient de la date de dernière update.
apt-spy trouve que le serveur que j’utilise est déjà le plus rapide, et si je lance un aptitude update
quelques heures après le premier c’est rapide, donc ce n’est vraiment pas la latence du serveur, mais bien
le processeur qui a du mal à calculer tous les diff.

Je marque le sujet comme résolu.

Merci à vous.