Bonjour (et bonne année).
Sur mon système, libpepflashplayer.so s'amuse à poncer mon disque dur (iotop indique quelque chose comme 850M en quelques minutes…).
J'aimerai bien savoir si il y à un moyen pour savoir où vont ces écritures, de sorte à pouvoir tenter de résoudre le problème…
[edit]
Bon, il semblerait que vider le cache du navigateur ait résolu le problème… pourquoi, par contre, je n'en sais rien…
# Est ce que
Posté par TheBreton . Évalué à 2.
lsof -p PID
te donne des infos utiles?
[^] # Re: Est ce que
Posté par freem . Évalué à 2.
C'est… très verbeux pour le coup. Vu que libpepflashplayer.so est utilisé par vivaldi (browser fermé basé sur chromium, avec un pléthore de threads…). Ce que je ne comprend pas, c'est pourquoi cette lib tourne alors qu'aucune page ouverte ne contiens de flash player…
M'enfin, vais creuser un peu du côté de ces infos. Il n'y aurais pas moyen d'avoir la même chose, mais pour les threads? Ça dégrossirai sûrement pas mal le boulot: là j'ai quand même 419 lignes…
[^] # Re: Est ce que
Posté par NeoX . Évalué à 3.
en es-tu sur ?
tu as fait une recherche sur le code de la page pour voir s'il ne contient pas une "publicité" en flash ?
[^] # Re: Est ce que
Posté par freem . Évalué à 2.
Bien vu, je n'avais pas pensé aux contenus cachés. Je viens de virer les plugins que j'avais ajoutés, au cas où, et je n'ai plus que linuxfr d'ouvert, je vais laisser tourner un peu pour voir, vu que le problème semble se déclencher au bout de plusieurs minutes.
[^] # Re: Est ce que
Posté par freem . Évalué à 2.
Bon, il semble vraiment qu'il y ait une merde quelque part. Soit un bug du browser, soit un truc malveillant qui s'est glissé je ne sais où. Vais relancer avec un profil vierge, pour voir.
En moins de 10 mins, iotop indique plus de 600M écrits sur le disque, mais assez peu de données envoyées (~330K). Normalement, les données envoyées devraient avoir été nulles, mais vu le ratio j'ai tendance à plus penser à un bug qu'a un comportement malveillant. À voir.
[^] # Re: Est ce que
Posté par NeoX . Évalué à 3.
Je ne connais pas ce browser, qu'apporte -t-il que les autres browser n'ont pas ?
pourquoi alors ne pas essayé directement avec chromium ?
[^] # Re: Est ce que
Posté par freem . Évalué à 2.
En bref: c'est le futur successeur d'Opera 12.
Je dis bien futur, parce qu'il est encore en bêta, et que par rapport à O12 il manque encore énormément de fonctionnalités (une qui me manque particulièrement est le paramétrage site par site accessible rapidement, mais il manque aussi l'activation/désactivation du JS (potentiellement site par site) et de… flash player, justement).
En plus détaillé: un browser avec, par défaut (et actuellement, je ne parle pas des plans futurs):
En fait, je trouve qu'actuellement, il s'agit d'un de ceux qui cherchent à se démarquer. Contrairement aux ténors qui ne font que se copier les uns les autres. Ouvrir firefox, chrome et vivaldi côte à côte, et basculer de l'un à l'autre, j'ai l'impression de n'avoir que 2 navigateurs: vivaldi et un autre.
Après, c'est une question de goûts (et je me doute que la majorité ne partage pas les miens), mais perso j'ai du mal à voir l'intérêt d'avoir tous les browsers qui se ressemblent comme c'est le cas actuellement: tout pour le minimalisme, ça conviens sûrement à beaucoup de gens mais pas à tout le monde. Et je préfère ne devoir faire confiance qu'a un seul tiers plutôt qu'à un tiers pour le navigateur + 1 tiers par plug-in nécessaire pour avoir une utilisation confortable.
C'est sûr, ce serait mieux si c'était libre (je pourrais lancer gdb et lire le source pour voir d'où viens ce problème) mais je n'ai pas le courage d'aller coder un navigateur (je sais qu'il en existe un libre qui veut aussi remplacer O12, et la dernière fois que j'ai regardé, il avait implémenté des fonctionnalités qui me manquent de o12, mais il manquait celles en rapport avec le confort d'utilisation… impossible de me rapeller le nom, mais je fais la recherche tous les 2-3 mois pour voir ou ça en est, dès fois que…).
# "Résolu"...
Posté par freem . Évalué à 2.
Bon, je ne sais toujours pas trouver le fichier qui se fait mettre à jour par un thread précis, mais le problème d'origine (squat de la bp du disque) ayant été résolu par une suppression du cache, je suppose que je n'ai qu'à m'estimer content…
[^] # Re: "Résolu"...
Posté par mrlem (site web personnel) . Évalué à 2.
Sinon prendre le problème dans le sens inverse et regarder quels répertoires grossissent ? 600 Mo ça ne devrait pas passer inaperçu si tu fais un truc genre
find . -maxdepth 1 -type d \( ! -iname "." ! -iname ".." \) -exec du -sh {} \;J'imagine que ces mystérieuses écritures se produisent soit sur ton /home soit sur ton /tmp. Donc tu exécutes la commande, puis de nouveau une minute après, et tu regardes quel dossier a augmenté significativement, tu cd dedans, tu répètes l'opération jusqu'à trouver le dossier final, dans lequel tu devrais voir le fichier qui grossit, qui te donnera peut être un indice de ce qui se passe.
C'est un peu brutal, mais ça devrait marcher ;)
Bon courage !
[^] # Re: "Résolu"...
Posté par Yth (Mastodon) . Évalué à 4.
Euh, ça serait probablement plus simple d'écrire
du -hd 1, oudu -h --max-depth=1si la première ligne ne fonctionne pas (selon les versions de du).Là ça ressemble à un uuof (useless use of find).
Yth.
[^] # Re: "Résolu"...
Posté par mrlem (site web personnel) . Évalué à 1.
Effectivement, je ne connaissais pas d'autre moyen de passer à
dules fichiers, y compris cachés. C'est plus élégant, concis, et rapide à l'exécution : merci, je me coucherai moins bête ;)[^] # Re: "Résolu"...
Posté par LeAg . Évalué à 2.
Trouver l'origine des IO provoquant une contention est jamais une tâche aisée.
Heureusement il y a des outils prévus mais méconnus.
Une excellent prez de Brendan Gregg, l'initiateur de Dtrace (une top feature de Solaris 10), permet d'en (re)découvrir les plus connus.
Le plus facile d'accès : iotop
Total DISK READ: 9.73 M/s | Total DISK WRITE: 2.47 M/sTID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND27498 be/4 postgres 4.30 M/s 143.64 K/s 0.00 % 12.73 % postgres: SELECT23734 be/4 postgres 710.66 K/s 105.84 K/s 0.00 % 3.46 % postgres: idle in transaction27934 be/4 postgres 922.35 K/s 60.48 K/s 0.00 % 2.16 % postgres: idle30243 be/4 postgres 340.21 K/s 158.76 K/s 0.00 % 2.04 % postgres: PARSESa version Dtrace : iotop.d
ou sysdig : sysdig -c fdbytes_by proc.exe
ou systemTap : disktop.stp
On peut aussi chercher du coté de "perf".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.