Discussion :

[troumad]

Bonjour

J'ai un serveur sur un PI 2. Je viens de changer sa carte mémoire par manque de place : je suis passé de 64 à 128Go. Lors de la mise à jour, je suis aussi passé de la version 8 à la version 9 de debian.
Maintenant, il est lent. Même la complétion (surtout la complétion même) est lente en ligne de commande.

Pour info, voici ma carte : https://www.kubii.fr/fr/carte-sd-et-...n+1+&results=1 . Il me semble bien que c'est du matériel rapide...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 $ df
Sys. de fichiers blocs de 1K  Utilisé Disponible Uti% Monté sur
/dev/root            7086396  1618388    5090124  25% /
devtmpfs              470184        0     470184   0% /dev
tmpfs                 474792        0     474792   0% /dev/shm
tmpfs                 474792     6512     468280   2% /run
tmpfs                   5120        4       5116   1% /run/lock
tmpfs                 474792        0     474792   0% /sys/fs/cgroup
/dev/mmcblk0p1         41853    21328      20525  51% /boot
/dev/mmcblk0p5      40050608  3466244   34520152  10% /home
/dev/mmcblk0p6       4969400   223568    4473684   5% /var/lib/mysql
/dev/mmcblk0p7      67895104 47159204   17243936  74% /usr/share/ampache/www/musique
tmpfs                  94956        0      94956   0% /run/user/1000

[troumad]

Bonjour

J'ai lancé une opération "retagage" des morceaux de musique à partir de la base de données d'ampache que j'avais nettoyée (scripts disponibles sur demande).
J'ai donc lancé l'opération sur mes 13000 morceaux. Plantage au bout de plusieurs heures : le raspberry ne répond plus. Si on a une console ouverte dessus, on a se type de réponse :

Code :

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

1
2
troumad@raspberrypi:~/sites/Troumad $ ll
-bash: /bin/ls: Aucun fichier ou dossier de ce type

Un appel par ssh, comme par http indique qu'il y a un serveur au bout, mais, il ne répond rien : pas de page web ou de connexion possible. Le PI fonctionne encore comme passerelle.

J'ai "splité" les 13000 lignes en paquet de 100 (l'instruction a été perdue dans les méandre du plantage : plus de trace dans l'historique). Voici une de mes 13000 lignes :

Code :

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

mid3v2 -a "Jacques Offenbach [1819-1880]" -A "Contes d\\\'Hoffmann cd2_2 [Gedda, Schwarzkopf, de los Angeles]" -t "Quatrième acte, Première scène / Entracte" -T 25/28 -g "Opera" -y 1965 "/usr/share/ampache/www/musique/classique/jacques_offenbach/les_contes_dhoffmann_cd22_gedda_schwarzkopf_de_los_angeles/25_quatrime_acte_premire_scne__entracte.ogg"

Et je les lance par paquet de 26 :

Code :

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

1
2
3
4
5
6
7
8
9
for fich in tag1.sql.d*
do
	echo "début $fich"
	date
	sh $fich 2>/dev/null
	rm -f $fich
	sleep 60
	echo "fin $fich"
done

Je rajoute un sleep pour que la carte SD ou le reste du PI se repose un peu et un date pour suivre un peu. Voici la fin du travail d'hier soir et le début de celui de ce matin :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
vendredi 26 janvier 2018, 23:07:54 (UTC+0100)
fin tag1.sql.cx
début tag1.sql.cy
vendredi 26 janvier 2018, 23:14:54 (UTC+0100)
fin tag1.sql.cy
début tag1.sql.cz
vendredi 26 janvier 2018, 23:21:04 (UTC+0100)
fin tag1.sql.cz
root@raspberrypi:/home/troumad/sites/Troumad # vi tag1.sh
root@raspberrypi:/home/troumad/sites/Troumad # sh tag1.sh
début tag1.sql.da
samedi 27 janvier 2018, 07:17:27 (UTC+0100)
fin tag1.sql.da
début tag1.sql.db
samedi 27 janvier 2018, 07:25:50 (UTC+0100)
fin tag1.sql.db
début tag1.sql.dc
samedi 27 janvier 2018, 07:33:30 (UTC+0100)
fin tag1.sql.dc
début tag1.sql.dd
samedi 27 janvier 2018, 07:41:25 (UTC+0100)
fin tag1.sql.dd
début tag1.sql.de
samedi 27 janvier 2018, 07:49:35 (UTC+0100)
fin tag1.sql.de
début tag1.sql.df
samedi 27 janvier 2018, 07:56:28 (UTC+0100)
fin tag1.sql.df
début tag1.sql.dg
samedi 27 janvier 2018, 08:02:54 (UTC+0100)
tag1.sh: 6: tag1.sh: rm: not found
tag1.sh: 7: tag1.sh: sleep: not found
fin tag1.sql.dg
début tag1.sql.dh

Ce qui m'inquiète, c'est que le PI est rapidement tombé de matin ! En moins de 50 min de travail...
Est-ce normal ? Il a des radiateurs collés sur les deux composants de dessus et d'un point de vu ventilation, il est dans la boite officielle du PI.

Il a tourné un an sans problème avec un carte sd 32GO et une clef USB 64GO, un an avec une carte SD 64GO. Et là, le passage à une carte SD 128GO pose problème. La carte pourrait-elle être à l'origine des plantages ? Mais, je ne me souviens pas avoir déjà lancé d'aussi gros travail sur ce PI.

[troumad]

Il m'a fallu 7 heures pour copier 47Go d'une carte SD dans le PI vers la carte que je suspecte lente dans un adaptateur.

[Auteur]

bonsoir Troumad,

il y a un point qui m'intrigue :

je suis passé de 64 à 128Go

.
D'après ce lien il y a peu de cartes de 128Go qui sont compatibles avec le Raspberry (j'ai dû compter une dizaine de modèles différents). Malheureusement le lien ne précise pas les versions du Pi.
Pour une carte par exemple :

Kingston ; SDX (type) ; 128Go ; 10 (classe) ; SDX10V/128GB (référence) ;
Must format it as FAT32. Took a very long time for Pi to install system.

Pour le Pi2, les cartes de 64Go fonctionnent (ici).

Peut-être un problème de carte ?

[troumad]

Bon...
Comme je l'avais acheté sur un site qui se revendique raspberry, je n'ai pas fait attention à ça ! En regardant, d'après ce site (j'ai mis le lien dans ma première intervention), la carte est approuvée pour les Raspberry Pi.

Pour info, il m'a fallut 2h20 pour faire le transfert de la micro SD à mon PC.
J'ai un PI2 et un PI3, si la carte est compatible avec un seul des deux, ce sera mon PI3 qui servira de serveur.

Autre remarque, le travail de tag qui prenait 6 min pour 100 lignes avec cette carte en a pris 1h20 avec la carte 64Go en 11000 ligne (80/110*60=44 secondes pour 100 lignes), donc 8 fois plus vite avec la carte 64 bits. Ceci dit, il y a des différences :
- La carte 64Go a une debian 8, le logiciel pour modifier les tags est eye3D
- La carte 128Go a une debian 9, le logiciel pour modifier les tag est mid3v2.

[troumad]

La manip qui durait 2h20 avec la carte "lente" en utilisant mid3v2 sur un PI3. Il va falloir que je fasse l'essai à nouveau sur le PI2.
J'ai en effet réinstallé le système et je me suis débrouillé pour ne pas reformater la partition racine : j'ai fait une partition pour mettre /var.

[troumad]

Pour un début à une fin à 17h06 => 9h pour une copie avec dd...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
$[root@localhost Documents]# dd bs=4M if=raspbian-stretch-lite.img  of=/dev/mmcblk0 status=progress conv=fsync
683671552 bytes (684 MB, 652 MiB) copied, 44 s, 15,5 MB/s
717225984 bytes (717 MB, 684 MiB) copied, 5138 s, 140 kB/s
830472192 bytes (830 MB, 792 MiB) copied, 7856 s, 106 kB/s
834666496 bytes (835 MB, 796 MiB) copied, 8256 s, 101 kB/s
1858076672 bytes (1,9 GB, 1,7 GiB) copied, 27014 s, 68,8 kB/s 
443+0*enregistrements lus
443+0*enregistrements écrits
1858076672 bytes (1,9 GB, 1,7 GiB) copied, 32017,7 s, 58,0 kB/s
$[root@localhost Documents]# date
sam. mars  3 17:06:28 CET 2018

Il m'a fallu 7 heures pour copier 47Go d'une carte SD dans le PI vers la carte que je suspecte lente dans un adaptateur.

Pour faire cette copie par réseau : de mon ancienne carte 64Go sur un PI2 vers la nouvelle carte sur un PI3, il m'a fallut 4 heures.
Cette fois, je n'ai pas retouché les partitions à la main.

[troumad]

Je recommence les essais avec une nouvelle carte.

Voici tout d'abord le code pour couper le fichier tag1.sql en paquet de 100 lignes :

Code :

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

split -l 100 tag1.sql coupe_

Les fichiers seront nommés : coupe_XX. Chez moi de coupe_aa à coupe_eh.

Avec la nouvelle carte, taguer 100 fichier se fait en moins de une minute au lieu des 5 à 6 minutes avec l'ancienne carte.