Discussion :

[yolle]

.... refaire aussi un formatage et un réinstallation complète et propre des logiciels réellement utiles.

[yento]

Memoire, disque et CPU saturés. 36 jours sans avoir redémarré le PC. 142 processus en tache de fond.

Faut pas non plus prendre le departement info pour des cons. Tu pourrais commencer par arrêter tous les programmes inutiles et redémarrer ton PC.

Si vraiment il y a une raison d'utiliser une telle quantité de ressources, c'est pas difficile de montrer quel programme le justifie plutôt que montrer ça.

[yolle]

Memoire, disque et CPU saturés. 36 jours sans avoir redémarré le PC. 142 processus en tache de fond.

HHHHHHaaaaaaaa ..... ouais, j"avais pas vu ... . C'est vrai que après 36 jours (Presque 37) sans redémarrage, c'est moyen .... Donc Manipulation N° 1 éteindre et redémarrer ... Manipulation N° 2 Verifier les process qui tournent. Ca me parait être déjà un bon début .

[sevyc64]

Memoire, disque et CPU saturés. 36 jours sans avoir redémarré le PC.

36 jours sans redémarrer n'a pas de réelle signification et n'est pas une information en soi. Cela dépend de l'utilisation du poste.
J'ai déjà vu des postes qui n'avaient pas redémarrés depuis plus de 200 jours et qui se comportaient comme un charme, à l'exception des mises à jours qui n'étaient pas installées.
Bien sur que redémarrer ne pourra pas faire de mal, mais ne résoudra certainement pas le problème qui réapparaitra sans doute en quelques minutes.

Quant aux processus, W10 en crées déjà énormément. A cet instant précis, sur un poste particulièrement nettoyé, j'en ai 187, dont pas loin de 90 appartenant au fonctionnement même de Windows, et presque une 50ène propre à Chrome et Firefox avec nombre d'onglets ouverts.

[yolle]

36 jours sans redémarrer n'a pas de réelle signification et n'est pas une information en soi. Cela dépend de l'utilisation du poste.
J'ai déjà vu des postes qui n'avaient pas redémarrés depuis plus de 200 jours et qui se comportaient comme un charme, à l'exception des mises à jours qui n'étaient pas installées.

Oui moi aussi mais bon, il y avait Word, excel, intranet qui tournaient c'est tout, D’après le type, il fait plein de trucs avec. Dev, modélisation etc etc ... la base c'est quand même de redémarrer histoire de vider la mémoire.

[gangsoleil]

Oui moi aussi mais bon, il y avait Word, excel, intranet qui tournaient c'est tout, D’après le type, il fait plein de trucs avec. Dev, modélisation etc etc ... la base c'est quand même de redémarrer histoire de vider la mémoire.

Uptime : 27 minutes. Nombre de fenêtres : 6. Nombre de processus : 118.

Redémarrer ne fera pas de mal, mais il est clair que ce n'est pas la solution. La plupart des programmes actuels sont très gourmands en RAM, et 8Go en tout ,c'est faible.

[yolle]

Uptime : 27 minutes. Nombre de fenêtres : 6. Nombre de processus : 118.

Redémarrer ne fera pas de mal, mais il est clair que ce n'est pas la solution. La plupart des programmes actuels sont très gourmands en RAM, et 8Go en tout ,c'est faible.

oui, enfin bon, si tu es obligé de dire à un mec comment faire un minimum de recherche pour résoudre un problème, il y a DEJA un souci ...

Pour ma part : Carte télé allumée + Film sur VLC + Firefox + Thunderbird ... (7 fenêtres ouvertes) : 38 processus. Ram de 4 giga a peine à 50 % ... donc !!!!

[Barsy]

Un PC de bureau n'est pas un serveur, il n'est pas fait pour rester allumé en permanence.

Déjà essaie d'éteindre ton PC tous les soirs, cela permettra de vider ta mémoire vive et ça fera aussi un peu de bien à la planète. Et puis peut-être que tu te sers de beaucoup d'applications, mais sans doute ne te sers tu pas de toutes chaque jour. Si tu n'ouvres que celles dont tu as besoin, tu peux réduire considérablement la consommation de ressources.

Cela dit, je suis d'accord sur un point, un informaticien ne doit pas avoir pour travailler le même PC que les comptables. Et c'est malheureusement le cas dans certaines entreprises qui veulent gérer un parc informatique uniforme (en le calibrant bien entendu sur les besoins du comptable). J'ai même vu le cas où la puissance des machines étaient en fonction du niveau du poste : les machines performantes étant réservées aux Managers.
Les consciences changent cela dit, et ce genre de cas devient de plus en plus rare.

Dans ton cas, ta machine est vieillissante (je dirai environ 6 ans), cela justifierai un remplacement. D'autant plus que le prix d'un PC neuf, même performant (i5, SSD, 16/32Go, CGG) n'est pas très élevé pour une entreprise (sauf si elle loue son matériel, mais le remplacement périodique des machines devrait être inclus dans le contrat de location).

[yolle]

Et c'est malheureusement le cas dans certaines entreprises qui veulent gérer un parc informatique uniforme (en le calibrant bien entendu sur les besoins du comptable).

Tes développements en info doivent tourner sur les bécanes des utilisateurs, c'est normal que tu es la même config ... ils auront les même temps de réponses que toi. Si ca marche chez toi, ca marche chez eux. C'est .... juste logique (du bon sens).

[el_slapper]

Tes développements en info doivent tourner sur les bécanes des utilisateurs, c'est normal que tu es la même config ... ils auront les même temps de réponses que toi. Si ca marche chez toi, ca marche chez eux. C'est .... juste logique (du bon sens).

C'est à double tranchant. Certains outils de développement sont très gourmands, et demandent effectivement des machines de combat. en revanche, quand on test sur une superbête à l'écran gigantesque, et qu'on se retrouve chez le client ou ça rame et il y a des ascenseurs partout, ben, comment dire..... et c'est du vécu, hein. Les hôpitaux(pas seulement Français, mais c'est encore pire ici) ont souvent des brouettes de l'avant dernière guerre, avec des écrans en résolution d'Amstrad CPC.

Enfin, j'ai connu un client qui avait d'excellentes machines pour tout le monde. Après tout, un consultant, ça coute 700/800€ par jour, un interne un peu moins mais quand même, mettre 400 euros de plus pour que tout le monde aie du confort à l'utilisation, ça leur a paru futé. 3000 postes d'un coup, quand même. Mais je suis sur qu'ils sont rentrés dans leur frais. Équipement standard, facile à remplacer et maintenir, et hautes performances pour qu'aucun salarié ne soit freiné. J'ai fait tourner des macros EXCEL, là dessus, qui, euh, comment dire, n'étaient pas forcément sympathiques avec le CPU ou la mémoire. Et ça a tenu parfaitement.

[Barsy]

Tes développements en info doivent tourner sur les bécanes des utilisateurs, c'est normal que tu es la même config ... ils auront les même temps de réponses que toi. Si ca marche chez toi, ca marche chez eux. C'est .... juste logique (du bon sens).

Tout d'abord, sans savoir sur quel type de projet je travaille, je doute que tu puisses juger sur quelle machine mes développements doivent tourner. D'autre part, il est quand même de plus en plus fréquent que ce soient des serveurs qui fassent tourner notre code étant donné que les clients lourds se font quand même de plus en plus rares. Enfin, quand tes utilisateurs ont des PC différents, avec des tailles d'écran différentes, j'espère que tu produits pour chacun d'entre eux une version personnalisée de ton code que tu auras pris le soin de développer sur chaque machine spécifique (Saperlipopette ! DELL sort un nouveau PC, faut tout refaire !! )

Cela dit, j'apprécie ton analyse qui consiste à penser qu'un développeur d'application pour smartphone doit développer depuis son smartphone et un développeur d'application pour bornes SNCF doit travailler directement sur la borne . Je te conseille dans ton cas de coder directement en prod

Plus sérieusement, un développeur doit travailler avec des outils performants et efficaces. Par contre, il doit pouvoir simuler facilement l'environnement cible sur son poste de développement et pouvoir déployer rapidement sur un banc d'essai ou sur une plateforme d'intégration afin de valider le bon fonctionnement de l'application dans un contexte réel. Il est vrai que beaucoup veulent faire l'économie de ce genre d'outils et de plateformes parce que cela semble être un surcoût en début de projet, mais c'est un véritable gain à terme et il existe de plus en plus d'outils pour mettre en place tout ça rapidement.

[sevyc64]

3000 postes d'un coup, quand même.

A ce volume là, ils n'ont certainement pas acheter le matériel. C'est de la location. C'est sans doute du leasing de la LOA, voire carrément de la location-maintenance au forfait.

Mais je suis sur qu'ils sont rentrés dans leur frais.

Oui certainement, parce que comptablement ça ne rentre pas dans les mêmes rubriques.
Acheter les machines c'est acheter du matériel, donc donner de la plus-value à l'entreprise avec en conséquence des impôts à payer. De plus, comme c'est un investissement, tu rentre ça dans les immobilisations avec un plan d’amortissement, etc ...

Louer le matériel, comptablement ça revient à acheter un service auprès d'un prestataire, les conséquences purement comptables sont tout autre.

[el_slapper]

A ce volume là, ils n'ont certainement pas acheter le matériel. C'est de la location.(.../...)

ça, c'est un autre sujet. C'est bien possible que tu aie raison - c'est juste que je ne connais pas bien cet aspect. Moi, je parlais de rentabilité opérationnelle, et je pense que là-dessus, ils ont été clairement gagnants(même si, comme tu le soulignes justement, c'est sans doute comptablement difficile à voir). J'étais loin d'être le seul à faire des macros gourmandes, dans cette maison, on trouvait des choses dans tous les services. Et quand le nombre de données à traiter devient important, la puissance de la bécane compte. Vraiment.

[yolle]

T
Cela dit, j'apprécie ton analyse qui consiste à penser qu'un développeur d'application pour smartphone doit développer depuis son smartphone et un développeur d'application pour bornes SNCF doit travailler directement sur la borne . Je te conseille dans ton cas de coder directement en prod

He oui cette année encore nous avons un prix Nobel. .... Barsy, "l'homme qui a vu l'homme qui à vu l'ours"

[yento]

Uptime : 27 minutes. Nombre de fenêtres : 6. Nombre de processus : 118.

Redémarrer ne fera pas de mal, mais il est clair que ce n'est pas la solution. La plupart des programmes actuels sont très gourmands en RAM, et 8Go en tout ,c'est faible.

Non, 8 Go n'est pas faible. C'est suffisant pour presque tout sauf faire fonctionner plusieurs VMs. Si c'est un manque de mémoire, acheter une barrette de RAM n'est pas comparable a acheter un PC.

Le reboot c'est histoire de nettoyer les processus de fonds (et appliquer les mises a jour windows majeur tant qu'a faire). J'imagine bien le mec qui a laisser un while(1) en tache de fond avec 150 onglets sur Chrome et une base Oracle. Forcement ca passe pas.

Quand on est pauvre, on fait avec les moyens du bord et on optimise.

C'est comme au travail. Pas assez de memoire dans nos vieux serveurs, 1TB ca ne suffit plus de nos jours. Bref, c'est l'histoire d'un dev qui ship un programme avec une fuite de memoire, le programme bouffe toute la RAM a la fin de la journée et crash les autres jobs en prod.

[el_slapper]

(.../...)C'est comme au travail. Pas assez de memoire dans nos vieux serveurs, 1TB ca ne suffit plus de nos jours. Bref, c'est l'histoire d'un dev qui ship un programme avec une fuite de mémoire, le programme bouffe toute la RAM a la fin de la journée et crash les autres jobs en prod.

Vu dans une grande banque Française : le gars avait carrément fait une boucle infinie sur l'écriture de piste d'audit(ce qui trace absolument tout ce qui est fait par les agents). Donc le disque dur a crashé instantanément. Il a fini la correction avec le grand chef sur le dos(oui, le gars assez puissant pour donner des ordres à un président de la république, qui se retrouve derrière ton dos à attendre que tu aie fini de livrer ta correction). Forcément, 10 00 agents ne pouvaient plus travailler.....

Plus généralement, c'est toujours une question d'équilibre. Micro-optimiser tout au poil près, ça n'est pas rentable, mais se moquer complètement des performances, ça pose assez vite des problèmes. J'ai toujours fait un effort léger dans ce sens, genre un tri qui fait gagner 30% de performances, ou alors une bufferisation qui fait gagner 17%, etc... Des choses simples et qui rapportent facilement... La bufferisation m'a couté une heure de travail et faisait gagner une heure de traitement sur un batch mensuel. Pas le Pérou, mais utile quand même pour l'équipe marketing qui attend les résultats avant de partir tard le soir.

Mais sur des algorithmes complexes, déjà, on essaye de faire marcher. Après, si ça passe dans un temps raisonnable, on oublie. trop dangereux.

Un des problèmes possibles, dans le cas présenté, ce sont les outils. Une autre problématique. Si ils sont codés avec les pieds, alors il faut faire un peu le ménage soi-même, et ne les garder ouverts que lorsque c'est utile. Et faire le ménage dans ces onglets firefox, de temps en temps.

[Glutinus]

Plus généralement, c'est toujours une question d'équilibre. Micro-optimiser tout au poil près, ça n'est pas rentable, mais se moquer complètement des performances, ça pose assez vite des problèmes. J'ai toujours fait un effort léger dans ce sens, genre un tri qui fait gagner 30% de performances, ou alors une bufferisation qui fait gagner 17%, etc... Des choses simples et qui rapportent facilement... La bufferisation m'a couté une heure de travail et faisait gagner une heure de traitement sur un batch mensuel. Pas le Pérou, mais utile quand même pour l'équipe marketing qui attend les résultats avant de partir tard le soir.

J'ai tendance à trop penser à amont comment tout disposer. Après, ça devient un réflexe, et quand t'es encore dans ta phase de conception "dans ta tête", avec l'expérience, ça case vite.
Chez un gros client, on avait repris un datawarehouse qui mettait 20h, des fois 24h, pour s'alimenter en quotidien. En guise de bienvenue, on a vu une présentation avec des gars qui allaient faire venir des serveurs en mode machine de guerre. En jour 2, on a regardé le code de l'équipe précédente :

- Les traitements se lançaient quand tous les fichiers sources étaient arrivés, alors qu'il y avait certaines indépendances. Résultats, on pouvait lancer les traitements les plus lourds en réalité quatre ou cinq heures plus tôt...

- Je suis allé demander au chef de projet à quel rythme il passait les stats sur la base. Il m'a regardé avec des yeux ronds comme des soucoupes "Les quoi ?". Je reviens à mon poste ; en dev, quelques analyze table compute statistics, un run de mon appli. Dans le batch, encore quelques heures de gagnées.

- L'équipe d'avant ne regardaient même pas les logs. Lors des requêtes, ils avaient oublié la plupart du temps le flag version courante à 1 : résultat, des pseudo produits cartésiens à tout va, avec près de 90% des lignes qui allaient écrire les logs de rejets. Quelques flags de version courante placés : quelques heures de gagnées (au passage, ils copiaient collé absolument tout lors du paramétrage de l'appli, résultat les logs ne s'écrivaient que sur une seule log, en réécrasant le tout. Donc le matin : une seule log, celui du dernier job...)

Bon j'avoue, j'ai bichonné par la suite un traitement au maximum, au moindre calcul de cache à l'octet près, j'avais estimé à deux heures et demi le run, et dès le premier lancement en uat (volumétrie de prod) = 45 minutes. J'ai juste passé trois jours à bichonner toutes les options, mais derrière la seule fois il a crashé, c'est à cause du n00b d'à côté qui m'a fourni un jeu de données eronné et beaucoup trop volumineux.

[phili_b]

Ça me fait penser aux cas où les "optimisations" étaient beaucoup trop basées sur les fuites mémoires alors qu'elles auraient d'abord du porter sur la recherche des boucles infinies ou allocations mal fermées (monde du développement), ou trop basées sur les réglages du moteur de bases de données alors qu'elles auraient d'abord du porter sur la recherche des produits cartésiens et de la trop grande verbosité du SQL généré à tort (monde de la base de données).

[4sStylZ]

Ce topic est intéressant. Je trouve qu’il y a un peu trop de commentaires très logiques basés parfois sur la moralité, la légalité, mais malheureusement en dehors de considération des réalités du monde du travail.

J’ai un soucis un peu similaire (que je vais expliquer après) qui ne bloque en rien mon travail mais qui m’irrite. Dans la société ou je suis (50 personnes environ) je ne peux pas me permettre de mettre à dos la direction technique. D’une part je suis dépendant d’eux mais ils peuvent aussi me mettre des gros freins à ma productivité, en me supprimant des outils, en m’obligeant à utiliser des outils inadaptés etc.
Par exemple, je suis un des seuls non-dev qui n’utilise pas Windows et j’ai des périphériques particuliers pour des raisons de santés (Ma distri linux est très optimisées pour être plus ergonomique et éviter de nombreuses souffrances, TMS et autres). On m’a déjà plus ou moins menacé de me supprimer ce privilège et cela me fait suffisament peur pour ne pas aller souler la DT pour un point de vue divergent.

Bref, tout ça pour dire que des intérêts différents entre les section techniques et les employés peut être un vrais frein qui ne facilite aucunement la résolution des problèmes.

---

J’en viens à ma petite histoire perso :
Dans ma société il est interdit de bosser avec des PC perso. Très bien. Je comprend les soucis que l’usage d’un pc pro soulève et je vais arrêter. C’est dommage, mon PC*pro possède deux écrans et je ne suis pas obligé de bosser sur un portable 13”.
Par contre à l’opposé, la boite vient de passer au double facteur google sur plusieurs outils et me demande d’utiliser mon tel perso pour me connecter à mon compte pro.

Je n’aime pas l’idée :

• J’ai des problèmes pour capter dans ma société à cause, certainement de filtres lumineux sur les fenêtres.
• Mon tel est assez vieux et ne mémorise pas les wifi de la société.
• Je l’oublie souvent ou le laisse déchargé, n’étant pas addict du télephone.
• Je ne peux pas installer les applis google sur mon tel : Dû à son age il a peu de mémoire et ne me permettrait pas d’installer Google authentificator.
• Mais surtout, c’est mon device, perso que j’ai payé 350€, pas un tel pro ! Si j’ai toujours accepté de l’utiliser pour un usage pro de manière occasionnelle, je trouve ça fort en pomme qu’on m’interdise d’utiliser mon matériel perso pour certains usages ou ça m’aide à être productif et à tenir mes délais mais qu’on m’oblige à utiliser mon tel perso pour un usage pro !

Bien-sur on ne vas pas acheter 50 smartphone pro avec abonnements pour les employés pour une question budget mais ça reste quand même étrange à mes yeux.
Tous les employés ont accepté d’utiliser les device perso pour s’authentifier sur les comptes pro et je semble être le seul à être réticent.

Je n’attend pas vraiment de solution miracle évidement. Surtout que pour les raisons citées plus haut je ne suis pas allé en parler à la DT ni à des délégués du personnel.

[Hermite]

Ton cas est un peu particulier quand même, mais sur le principe j'aurais refusé. Quitte à "jouer au con" en quelques sortes, et ne plus amener mon téléphone au boulot. De toutes manières, s'il est interdit de s'en servir, à quoi bon l’amener.

Dans ton cas, je ne suis pas d'accord avec ta remarque

Bien-sur on ne vas pas acheter 50 smartphone pro avec abonnements pour les employés pour une question budget mais ça reste quand même étrange à mes yeux.

.
En tant que société, ils mettent en place un système, c'est anormal de ne pas faire entrer dans le budget tout ce qui tourne autour et de compter sur les employés.
La personne qui a validé la solution est soit incompétente, soit malhonnête.