Salut
Maathuvu.
Retour du facétieux
macomaniac dans son emploi de commentateur des messages pointés par l'intermédiaire de liens - mais dans une configuration de '
neutralité bienveillante' cette fois
.
L'auteur du message
#16 évoqué, le nommé :
Bigua [qui s'excuse de ses maladresses dans la langue de
Shakespeare par le délicieux : «
sorry by my poor english -
ce qui me laisse imaginer qu'une demande d'excuse pour maladresse a d'autant mieux de chances d'être reçue que l'auteur l'exprime sous une forme grammaticalement incorrecte...], déclare qu'il a appliqué la préconisation qui lui a été faite par
cerberusss [
dont je me figure le pseudonyme valoir pour un Russ(ell) se prenant tellement pour un 'Cerbère' - interdisant la sortie d'on ne saura quel Enfer - qu'il emprunte à la triple tête légendaire de ce gardien le triplement final de sifflantes appariées à la serpentine crinière du susdit ] ; en suite de quoi, 6 jours après l'opération, le processus dévorateur de pourcentage
CPU n'a jamais repointé de bout de l'oreille.
♤
Avec un laconisme exemplaire, le dénommé
cerberusss déclarait :
Cerberusss a dit:
The systemstats process maintains a database in the folder /private/var/db/systemstat. Perhaps it's corrupted; you could try killing systemstat, removing that database (or better rename it) and reboot.
[Le processus 'systemstats' maintient une base-de-données dans le répertoire /private/var/db/systemstats. Il se peut qu'elle soit corrompue ; vous pourriez essayer de 'tuer' le processus 'systemstats', de supprimer cette base-de-données et de re-démarrer.]
ajoutant tout aussi laconiquement en guise d'explicitation pour un
bigua dont le préfixe nominal '
bi' proclame le besoin de s'entendre dire
deux fois les choses afin de les entendre
D) :
Cerberusss a dit:
If I had to guess, the .stats files are one-time snapshots captures of resource use (resources being memory, CPU, disk usage). And the snapshots.db is probably the database, the aggregation of the .stats files.
I'd just stop the process and then rename the folder itself. That way, after a reboot everything will be recreated, I'd hazard to guess.
[Simple supposition de ma part : les fichiers .stats sont des instantanés de l'utilisation de ressources (en mémoire, CPU, utilisation du disque). Et le fichier 'snapshots.db' est probablement la base-de-données : l'agrégation des fichiers '.stats'.
Je stopperais simplement le processus et renommerais le dossier lui-même. Ainsi, après re-démarrage, tout sera re-créé à neuf - du moins me le figuré-je.]
♢
Je me suis livré à plusieurs expérimentations - lequelles jamais n'empêchent le re-démarrage, la ré-ouverture normale de session ni n'affectent en quoi que ce soit la capacité de navigation graphique de l'usager, lequel peut donc toujours se raviser s'il y avait lieu :
- Suppression du contenu du répertoire : 'systemstats' (les fichiers et la base-de-données entre autres) ⇨ la structure de fichiers, allégée de l'accumulation surnuméraire des fichiers '.stats', est recréée à l'identique ;
- Renommage du répertoire 'systemstats' (sauvegardé par ailleurs 'au cas où') en 'system--stats' et suppression de son contenu ⇨ après re-démarrage, un nouveau répertoire 'systemstats' est créé à neuf, contenant la même structure de fichiers allégée que dans l'occurrence précédente où le contenu du répertoire natif 'systemstats' avait été supprimé [tandis que le répertoire renommé : 'system--stats', manifestement placé 'hors-circuit', reste vide d'écritures] ;
- Suppression pure et simple du répertoire 'systemstats' ⇨ après re-démarrage, un nouveau répertoire 'systemstats' est créé à neuf (comme dans l'occurrence immédiatement précédente) contenant la même structure de fichiers allégée que les deux fois précédentes.
- J'ai voulu tenter une manœuvre (toujours formellement dangereuse pour qui n'a pas de clone sur lequel re-démarrer en cas de blocage-système) de verrouillage carrément du répertoire 'systemstats' ⇨ l'option est indisponible, même en promouvant dans l'ACL l'utilisateur-admin à la co-propriété root du répertoire [Je n'ai pas insisté].
♡
☞ certes je n'ai pas pu tester l'efficacité du procédé (n'ayant pas de problème de processus '
systemstats' pesant sur l'emploi du
CPU), mais j'ai pu vérifier son innocuité-système en lui-même ⇨
Maathuvu pourrait donc essayer :
- de tuer le processus 'systemstats' dans le «Moniteur d'activité» ;
- d'aller à la barre de menus supérieure du Finder, menu : Aller, sous-menu de la fenêtre déroulante : Aller au dossier..., et dans la fenêtre rectangulaire de saisie textuelle qui s'affiche faire un copier-coller de :
et presser le bouton 'Aller'. Dans l'espace du répertoire 'db' (recelant toutes sortes de données de caches) qui s'affiche dans une fenêtre, repérer le dossier : 'systemstats' et le mettre à la corbeille tout entier (sans la vider - 'au cas où'). Re-démarrer. Constater les effets ou les non-effets.
☞ cette méthode de 'guérison' d'une base-de-données éventuellement corrompue n'apporte néanmoins pas de réponse à la question éventuelle : y a-t-il une application (de Tierce Partie ou seulement le «
Moniteur d'activité» activé en permanence) qui enfièvre, dans son usage du
binaire: '
systemstats' le processus éponyme? Ou bien n'y a-t-il là qu'un processus activé normalement
on launch qui souffrirait d'une base-de-données corrompue?
♧
bompi & François.
