Questions sur l'installation et la configuration de Manjaro Linux.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#21Messageil y a 1 an

Bonjour, Smurf et rebonjour, papajoke.
Oui, le fil a dévié depuis le message #11 de papajoke.
Moi, systemd-analyze me donne :

Startup finished in 24.947s (firmware) + 5.544s (loader) + 4.203s (kernel) + 40.515s (userspace) = 1min 15.210s 
graphical.target reached after 40.209s in userspace
Ignace.
Dernière modification par ignace72il y a 1 an, modifié au total 1 fois.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#22Messageil y a 1 an

40.515s (userspace)
??? Rien à voir avec une config ssd (avec uniquement un dd c'est une valeur classique) ! Comme Smurf je suis sous les 3 secondes (avec mon petit i3)

graphical.target reached after 2.329s in userspace
Attention, une seule mesure ne signifie pas grand chose : nous avons des services qui se lancent de temps en temps et qui peuvent être très gourmands. Donc il est possible qu'à ton dernier boot, systemd ai lancé exceptionnellement un gros service (updatedb.timer par exemple).
Il faut donc mieux faire un reboot pour avoir la bonne valeur
si toujours énorme, créer un autre sujet, nous avons: systemd-analyze blame et systemd-analyze critical-chain), A voir aussi si tu ne montes pas des disques via le réseau...

edit: ton bios est aussi beaucoup trop long :?

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#23Messageil y a 1 an

Ben comme choses qui sont lancées au démarrage, il y a :
Mes deux fonds d'écrans, mes trois tableaux de bord, l'agent Connectix de Druide Antidote +, JDownloader 2, KeepassXC, GCstar avec 3285 fiches (1,1 Gio), Notes, Private Internet Access (mon VPN) (200 Mio), l'applet NetwordManager, VMware User Agent, QuiteRSS, Firefox avec plusieurs onglets (1,4 Gio), Thunderbird (784 Mio), KNutClient (119 Mio), 2 terminals, 3 fenêtres Thunar avec les miniatures activées, SMplayer, GKrellm et les greffons suivants : barre d'état, Horloge, Mise à jour météo, moniteur de la charge du système, moniteur de fréquence du processeur, PulseAudio, Chronomètre Xfce4.
Je n'ai pas de disque via le réseau.
Pour le BIOS, ben je ne sais pas je n'ai pas fouillé dedans, ce n'est pas moi qui ai monté la tour, c'est le magasin avec l'alimentation, mes 4 disques SATA, ma carte graphique passive et une carte fille PCI-E vers USB 3, 7 ports de mon ancienne tour et les 6 ports USB arrières de ma carte même sont utilisé (4 USB 2.0 et 2 USB 3) et 2 ports USB 3 de la carte fille sont utilisés.
Et puis au moins, avec un BIOS long, j'ai le temps d'appuyer sur F11 ou suppr.
Je testerais au prochain démarrage pour voir si le temps de chargement de l'espace de travail est aussi long.
Ignace.
Dernière modification par ignace72il y a 1 an, modifié au total 2 fois.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#24Messageil y a 1 an

Tu n'as pas compris, userspace s'arrête* lorsque le gestionnaire de connexion est chargé :wink: (sinon nous serions tous très très fort pour saisir notre mot de passe :rigole: )

s'arrête* : en fait, NON, un service en tache de fond peut encore tourner des minutes après l'affichage du gestionnaire de connexion (que l'on se log ou non ne change rien) par exemple man-db ou updatedb

userspace c'est toutes les unités systemd lancées au démarrage en dehors du noyau (notre bureau n'est pas lancé automatiquement par systemd)

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#25Messageil y a 1 an

D'accord, comme je suis le seul utilisateur de l'ordinateur, j'ai dit au gestionnaire de connexion de se connecter automatiquement d’où la confusion.
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#26Messageil y a 1 an

papajoke a écrit : il y a 1 an En effet, le sujet a débordé, ici, il utilise la commande trim uniquement pour montrer que maintenant le home est sur ssd.
Ah d'accord, j'aurais fait sans trim, :

dfc|grep home
/dev/sda2            [========------------]      37,6% 263,6G 422,5G /home                     0,01s
Partition /home sur /dev/sda.
/dev/sda est il un disque mécanique ? (0=non)

lsblk -o name,rota|grep sda 
sda       0
├─sda1    0
├─sda2    0
└─sda3    0
ignace72 a écrit : il y a 1 an Moi, systemd-analyze me donne :

Startup finished in 24.947s (firmware) + 5.544s (loader) + 4.203s (kernel) + 40.515s (userspace) = 1min 15.210s 
graphical.target reached after 40.209s in userspace
Ce n'est pas normal, à moins que tu aies eu une vérification de partition par fsck au démarrage, quand j'utilisais un disque dur mécanique, avec un i3-3220, j'étais dans les 30s.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#27Messageil y a 1 an

ignace72 a écrit : il y a 1 an D'accord, comme je suis le seul utilisateur de l'ordinateur, j'ai dit au gestionnaire de connexion de se connecter automatiquement d’où la confusion.
Ignace.
Bonjour.
En fait, ce n'est pas très exact. Pour schématiser root est l'utilisateur administrateur/système qui laisse quelques droits aux utilisateurs que nous sommes .
Le système se connecte d'abord à root, puis celui-ci nous invite dans notre espace personnel avec notre propre MP pour lancer l'interface graphique.
Les gestionnaires de connexion comme LightDm ne sont que des interfaces 'pré'-graphiques (pardon pour ce vilain néologisme) qui nous évitent de nous connecter en console et de devoir jouer du startx pour profiter de nos environnements de bureaux. Qu'on soit le seul être vivant a se servir de la machine ou plus, il y aura toujours à minima deux utilisateurs.
Bon, désolé, j'ai fais mon ch :censure: ur. :gsourire:

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#28Messageil y a 1 an

Quand je fais systemd-analyze blame, ça me donne dans les premières lignes ça :

    3min 40.756s pkgfile-update.service
         25.896s nut-driver.service
         13.629s man-db.service
         12.479s NetworkManager-wait-online.service
          7.390s updatedb.service
          2.150s upower.service
Les autres services sont sous la seconde.

Oui, j'avais oublié l'utilisateur root mais je l'oublie facilement, car je ne me connecte jamais en root, je passe toujours par sudo mais je suis conscient qu'il existe.
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#29Messageil y a 1 an

Donc tu as les coupables :gsourire: et bien sûr pas de rapport avec ssd

man-db et updatedb sont des timeurs : une fois par jour (perso j'ai passé man-db à la semaine). valeurs normale
pkgfile-update fait un pacman -Fy donc normal qu'il soit long si pas de fibre (c'est un truc pas cool avec la config zsh de manjaro qui donne le paquet à installer si commande non trouvée) Si tu n'utilises pas, tu peux dévalider le timer ou alors le passer à la semaine...
nut-driver :confus: ne connais pas
pour "upower" suis à 51ms :saispas:

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#30Messageil y a 1 an

Ben je veux bien moi, mais mon PC, je l’éteins rarement alors la vitesse de démarrage, je n'en ressens pas la gêne.
Il bosse 24h/24 à hauteur d'une charge CPU de 80 %.
Je n'ai pas la fibre, juste l'ADSL à 850 Kio/s.
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#31Messageil y a 1 an

papajoke a écrit : il y a 1 an man-db et updatedb sont des timeurs : une fois par jour (perso j'ai passé man-db à la semaine). valeurs normale
Je décalais de 10 à 15 minutes man-db et updatedb, pour que ça se passe bien après le boot et chargement du bureau. Je n'ai rien eu à faire sur ma nouvelle install, les timers utilisent RandomizedDelaySec=12h.
pkgfile-update fait un pacman -Fy donc normal qu'il soit long si pas de fibre (c'est un truc pas cool avec la config zsh de manjaro qui donne le paquet à installer si commande non trouvée) Si tu n'utilises pas, tu peux dévalider le timer ou alors le passer à la semaine...
Pkgfile a sa base de données à part et est indépendant de pacman, maintenant qu'il existe pacman -Fx, je suppose qu'on pourrait se passer de pkgfile qui est redondant, il faudrait réécrire le script command-not-found.
nut-driver :confus: ne connais pas
Pour gérer un onduleur.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#32Messageil y a 1 an

Bonjour à tous et à toutes.
Pour ne plus dévier du sujet originel du fil, j'ai créé un nouveau fil ici :
viewtopic.php?t=13687
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#33Messageil y a 1 an

papajoke a écrit : il y a 1 an:salut:
Suite ... :gsourire:

J'ai trouvé un petit script que j'ai transformé pour me donner une valeur Go/jour
smartctl donne un chiffre sur l'écriture (pas forcément exact :pleure: ) mais c'est bien la seule chose qui est mesurable
ma technique (en plus):
- Je récupère la date de création de notre système pour en déduire le nombre de jours entre aujourd'hui et la création
- Ce qui me permet d'afficher un Go/jour pour le comparer à notre quota journalier maxi calculé depuis TBW:

...
Bonjour, papajoke.
Il y a un problème avec ton script, c’est qu’il se base sur la date d’installation du système pour faire son calcul et le problème, c’est que j’ai réinstallé ma Manjaro donc le script est dans les choux.
Il me donne maintenant :

~/ bin/test-disque-ssd.sh                                  
[sudo] Mot de passe de ignace : 
------------------------------
 SSD Status:   /dev/sda
------------------------------
 On time:      3,526 hr
 Depuis:       2022-06-22 (soit 3 jours)
------------------------------
 Data written:
           MB: 1,763,461.511
           GB: 1,722.130
           TB: 1.681
------------------------------
 Mean write rate:
        MB/hr: 500.130
        Go/jour: 574
------------------------------
 Drive health: 99 %
------------------------------
Sauf que je n’ai pas arrêté de l’utiliser depuis le 10 février 2022, date à laquelle je l’ai reçu.
Que dois-je modifier dans ton script pour prendre cette date en compte ?
Merci.
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#34Messageil y a 1 an

salut

c'est cette ligne qui recherche la date du "fichier" /.

created=$(stat / | awk '/Créé/ {print $2}')
En effet, si ré-install, elle est fausse :cartonrouge:

Pas d'idée immédiate pour trouver la date du disque dur (smartctl --all n'a pas plus d'infos) ...
Au pire, tu peux mettre une date en dur (an-mois-jour)...

created="2023-02-10"

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#35Messageil y a 1 an

Merci beaucoup à toi, là, c’est beaucoup mieux (par-contre, j’ai mis 2022 au lieu de 2023) :

~/ bin/test-disque-ssd.sh                            
[sudo] Mot de passe de ignace : 
------------------------------
 SSD Status:   /dev/sda
------------------------------
 On time:      3,529 hr
 Depuis:       2022-02-10 (soit 135 jours)
------------------------------
 Data written:
           MB: 1,768,411.909
           GB: 1,726.964
           TB: 1.686
------------------------------
 Mean write rate:
        MB/hr: 501.108
        Go/jour: 12
------------------------------
 Drive health: 99 %
------------------------------
Par-contre, il doit y avoir un problème avec ton script sur la durée de vie du SSD. J’ai ça comme résultat. Je trouve que 137 ans, ça fait beaucoup, non ? :

~/ bin/duree-de-vie-SSD.sh
Nombre de jours dans une année ou nous utilisons notre pc ? (365) 365
TBW du ssd ? (600) 600
Nombre de Go écrits par jour ? 12

Année de:                 365 jours
TDW:                      600 (nombre total d'octets écrits en téraoctets - 1 To = 1000 Go)
Comsommation journalière: 12 Go

Durée du ssd peut-être de 137 ans
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#36Messageil y a 1 an

ignace72 a écrit : il y a 1 an Par-contre, il doit y avoir un problème avec ton script sur la durée de vie du SSD. J’ai ça comme résultat. Je trouve que 137 ans, ça fait beaucoup, non ? :
:lol: A bon, moi, je ne trouve pas cela excessif :lol:

premier script donne : 1.6To en 135 jours
soit : x3 = 5To par an (an de 135x3= 405 jours :ivre: )

donc ici:

 en 001 an, tu consommes : 5To
 en 010 an, tu consommes : 50To
 en 100 an, tu consommes : 500To
Avec tes 600To d'écritures de garantis, oui, on trouve plus de 100 ans :wink:

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#37Messageil y a 1 an

Ah, ok, désolé, donc mon SSD cramera d’une panne autre que la limite d’écriture avant qu’elle ne soit atteinte.
Quand je vois qu’un disque du même modèle (je ne connais pas la capacité) a atteint les 9 Po d’écriture…
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#38Messageil y a 1 an

Bonjour à tous et à toutes.
Bon, voilà le dernier test des deux scripts :

█▓▒░ignace@ignace-pc█▓▒░ dim. janv. 08 05:04:32 
~/ bin/test-disque-ssd.sh 
[sudo] Mot de passe de ignace : 
------------------------------
 SSD Status:   /dev/sda
------------------------------
 On time:      8,235 hr
 Depuis:       2022-02-10 (soit 332 jours)
------------------------------
 Data written:
           MB: 4,522,726.392
           GB: 4,416.724
           TB: 4.313
------------------------------
 Mean write rate:
        MB/hr: 549.207
        Go/jour: 13
------------------------------
 Drive health: 99 %
------------------------------
Et

█▓▒░ignace@ignace-pc█▓▒░ dim. janv. 08 05:04:52 
~/ bin/duree-de-vie-SSD.sh 
Nombre de jours dans une année où nous utilisons notre pc ? (365) 365
TBW du SSD ? (600) 600
Nombre de Go écrits par jour ? 13

Année de:                 365 jours
TDW:                      600 (nombre total d'octets écrits en téraoctets - 1 To = 1000 Go)
Consommation journalière: 13 Go

Durée du SSD peut-être de 126 ans
Ça reste cohérent.
Et j’ai corrigé les deux fautes du deuxième script. :gsourire:
Répondre