Salut
grantom.
Je vois que tu remontes ce fil où
le pisse-copie l'
Accro_à_MacGé macomaniac avait gribouillé sur le sujet du
com.apple.IconServices...
Il me semble que le processus :
com.apple.IconServicesAgent soit une innovation de l'OS «
Mavericks» - vu que je ne l'avais jamais noté en activité auparavant sous aucun OS antérieur. Pour continuer à filer le brin ténu de mes conjectures : ce processus inédit, donc, me paraît faire corps avec la façon dont «
Mavericks» gère l'
affichage graphique dans les sessions utilisateurs ouvertes. Si je regarde l'effet produit --> aux adresses contiguës :
/private/var/folders/tf/xxxxx/T/com.apple.IconServices &
/private/var/folders/tf/xxxxx/C/com.apple.IconServices, se produit une génération continue de fichiers à l'extension :
.iscachebmp, qui s'interprètent comme des fichiers caches iconservices au format bitmap. Ce constat (que je n'avais jamais fait sous les OS antérieurs) me laisse penser que, sous «
Mavericks», il y a une mise en cache continue d'espèces de 'clichés momentanés' du dispositif graphique global des sessions d'utilisateurs, dépendant soit d'une règle temporelle - toutes les x secondes/minutes - soit d'une règle spatiale - à chaque variation du dispositif graphique.
Ce gonflement du nombre des fichiers_caches
.iscachebmp dans les dossiers d'accueil
com.apple.IconServices n'est pas indéfini : lesdits dossiers me paraissent subir, notamment, une purge des caches lors de l'extinction-redémarrage du Mac. Mais ça fait quand même une belle collection une fois la session d'utilisateur bien lancée (et encore plus en cas de sessions ouvertes en parallèle) : plusieurs milliers de fichiers allègrement, avec un poids des dossiers se chiffrant par centaines de Mo.
J'avais noté des plaintes sur le net concernant une relation entre ce processus
com.apple.IconServicesAgent générateur de caches d'affichage graphique et un enfièvrement de la
CPU, mais il me paraît que ce problème était dû à une absence, dans le répertoire :
/private/var/folders/tf/xxxxx/T ou C d'un dossier d'accueil :
com.apple.IconServices de ces fichiers caches que le processus
com.apple.IconServicesAgent avait mission de générer en continu --> en l'absence d'un espace de destination, le processeur devenait 'fou' en quelque sorte. La re-création volontaire de tels dossiers d'accueil
com.apple.IconServices aux emplacements attendus 'soulageait' miraculeusement le processeur et les fichiers caches d'affichage graphiques pouvaient s'empiler tranquillement aux emplacements d'accueil requis.
Mes petits bouts de prose humoristique (bien que longuette
) dans ce fil n'abordaient pas du tout cette question, qui relevait d'une anomalie 'topique', si je puis dire. Non, c'était la pression sur la RAM induite par ce processus inédit :
com.apple.IconServicesAgent qui m'avait interpelé, parce que, à mes débuts avec «
Mavericks», je constatais régulièrement que ce processus allait jusqu'à prendre autant et plus que la
kernel_task, soit plus de 1 Go de RAM une fois la session d'utilisateur bien lancée et spécialement si plusieurs sessions d'utilisateurs étaient ouvertes en parallèle. Il m'avait paru qu'il y avait un lien direct avec la prise en charge en RAM des 2 dossiers de caches d'affichage graphique :
com.apple.IconServices en train de gonfler en cours de session.
Le test de purger manuellement ces 2 dossiers de leurs fichiers
.iscachebmp (procédé sans effet problématique pour le fonctionnement graphique de la session) et de re-démarrer ramenait immanquablement la pression sur la RAM du processus
com.apple.IconServicesAgent à une valeur minimale d'environ 100 Mo - valeur qui, néanmoins, regrimpait inexorablement en cours de session. J'en ai tiré la conclusion qu'il n'y a pas là une anomalie de fonctionnement découlant d'applications de tierce partie, mais une règle de fonctionnement spécifique de «
Mavericks» qui est doté d'un processus de mise en cache 'clichant' en continu le dispositif d'affichage graphique dans les sessions d'utilisateurs (c'est secondairement que des applications de tierce partie qui auraient des effets sur cet affichage graphique - un logiciel de 'thèmes' comme «
Flavours» peut-être? - seraient susceptibles d'augmenter la charge de cette mise en cache).
Je crois me souvenir m'être amusé naguère, en guise de test, à supprimer manuellement le dossier :
folders dans
/private/var --> alors là
⛔︎ !
--> je ne recommande pas ce type d'expérience si l'on ne possède pas un Système démarrable indépendant, à partir duquel on peut monter les fichiers de l'OS affecté par cette manip afin de rétablir la situation, car le
Finder plante instantanément dans sa capacité d'affichage graphique et sauf à recopier un équivalent du dossier en question avec ses multiples composants, c'est fichu...
Ayant il y a quelques mois changé le disque interne de mon
MacBook Pro_Early 2011, en remplaçant son HDD par un SSD, j'ai par contre constaté curieusement un effet direct concernant la pression exercée sur la RAM par le processus
com.apple.IconServicesAgent : il semble qu'il se stabilise à un maximum d'environ 400 Mo désormais avec le SSD, là où auparavant il grimpait jusqu'à plus de 1 Go avec un HDD, soit moins de la moitié de la
kernel_task - ce qui m'a conduit à la mise-en-sommeil de mes interrogations sur le sujet
(tant il est vrai que la 'souffrance' est la mère de la connaissance, et l'ignorance la fille de la 'quiétude', d'où l'expression classique d'«imbécile_heureux»... ).