Question à un PRO en informatique !!!!!!!

ggtggtggggtgtgt
2021-04-17 22:46:01

alors ? :rire:

JazzChill2
2021-04-17 22:47:10

Le 17 avril 2021 à 22:43:30 :

Le 17 avril 2021 à 22:42:39 :
Si la ram est remplie, il utilise ton disque pour effectuer la tâche. Hors le disque est bien plus lent que la ram, surtout avec un vieux HDD mecanique. (Vraiment des dizaines/centaines de fois plus lent) et là, c'est le début de la fin car typiquement en Java, tu vas manger un OutOfMemory exception car il n'y a plus de ram.

mais pourquoi faire un outofmemory ? plutôt que de finir d'exécuter la tache mais plus lentement ?

Car tu as un OS dont le but est de minimiser au maximum le swapping pour favoriser la fluidité et qui va buter ce qui consomme le plus en ram (les apps java en tête) et force à écrire le plus en swap.

Car le swapping et la ram remplie à flot a des conséquences sur tout en terme de lenteur y compris sur l'OS et ses fonctions essentielles. (Gérer les processus et prioriser quel processus a accès aux threads car tout est pas lancé en simultanée en vrai, ça se partage des ressources)

ggtggtggggtgtgt
2021-04-17 22:49:45

Le 17 avril 2021 à 22:47:10 :

Le 17 avril 2021 à 22:43:30 :

Le 17 avril 2021 à 22:42:39 :
Si la ram est remplie, il utilise ton disque pour effectuer la tâche. Hors le disque est bien plus lent que la ram, surtout avec un vieux HDD mecanique. (Vraiment des dizaines/centaines de fois plus lent) et là, c'est le début de la fin car typiquement en Java, tu vas manger un OutOfMemory exception car il n'y a plus de ram.

mais pourquoi faire un outofmemory ? plutôt que de finir d'exécuter la tache mais plus lentement ?

Car tu as un OS dont le but est de minimiser au maximum le swapping pour favoriser la fluidité et qui va buter ce qui consomme le plus en ram (les apps java en tête) et force à écrire le plus en swap.

Car le swapping et la ram remplie à flot a des conséquences sur tout en terme de lenteur y compris sur l'OS et ses fonctions essentielles. (Gérer les processus et prioriser quel processus a accès aux threads car tout est pas lancé en simultanée en vrai, ça se partage des ressources)

ok et si je me fiche que tout le pc soit lent du moment que ça y arrive je peux contrôler ça comment ?

JazzChill2
2021-04-17 22:52:48

Le 17 avril 2021 à 22:49:45 :

Le 17 avril 2021 à 22:47:10 :

Le 17 avril 2021 à 22:43:30 :

Le 17 avril 2021 à 22:42:39 :
Si la ram est remplie, il utilise ton disque pour effectuer la tâche. Hors le disque est bien plus lent que la ram, surtout avec un vieux HDD mecanique. (Vraiment des dizaines/centaines de fois plus lent) et là, c'est le début de la fin car typiquement en Java, tu vas manger un OutOfMemory exception car il n'y a plus de ram.

mais pourquoi faire un outofmemory ? plutôt que de finir d'exécuter la tache mais plus lentement ?

Car tu as un OS dont le but est de minimiser au maximum le swapping pour favoriser la fluidité et qui va buter ce qui consomme le plus en ram (les apps java en tête) et force à écrire le plus en swap.

Car le swapping et la ram remplie à flot a des conséquences sur tout en terme de lenteur y compris sur l'OS et ses fonctions essentielles. (Gérer les processus et prioriser quel processus a accès aux threads car tout est pas lancé en simultanée en vrai, ça se partage des ressources)

ok et si je me fiche que tout le pc soit lent du moment que ça y arrive je peux contrôler ça comment ?

C'est simple.

Tu peux pas, enfin si mais c'est stupide.

Si ça consomme beaucoup et qu'il réclame tout le temps, l'os va le foutre en priorité minimale et le buter quand il sera en difficulté.

Tu peux le forcer en priorité haute mais c'est une idée stupide, ton pc sera inutilisable et tout le reste va freeze.

ggtggtggggtgtgt
2021-04-17 22:54:40

Le 17 avril 2021 à 22:52:48 :

Le 17 avril 2021 à 22:49:45 :

Le 17 avril 2021 à 22:47:10 :

Le 17 avril 2021 à 22:43:30 :

Le 17 avril 2021 à 22:42:39 :
Si la ram est remplie, il utilise ton disque pour effectuer la tâche. Hors le disque est bien plus lent que la ram, surtout avec un vieux HDD mecanique. (Vraiment des dizaines/centaines de fois plus lent) et là, c'est le début de la fin car typiquement en Java, tu vas manger un OutOfMemory exception car il n'y a plus de ram.

mais pourquoi faire un outofmemory ? plutôt que de finir d'exécuter la tache mais plus lentement ?

Car tu as un OS dont le but est de minimiser au maximum le swapping pour favoriser la fluidité et qui va buter ce qui consomme le plus en ram (les apps java en tête) et force à écrire le plus en swap.

Car le swapping et la ram remplie à flot a des conséquences sur tout en terme de lenteur y compris sur l'OS et ses fonctions essentielles. (Gérer les processus et prioriser quel processus a accès aux threads car tout est pas lancé en simultanée en vrai, ça se partage des ressources)

ok et si je me fiche que tout le pc soit lent du moment que ça y arrive je peux contrôler ça comment ?

C'est simple.

Tu peux pas, enfin si mais c'est stupide.

Si ça consomme beaucoup et qu'il réclame tout le temps, l'os va le foutre en priorité minimale et le buter quand il sera en difficulté.

Tu peux le forcer en priorité haute mais c'est une idée stupide, ton pc sera inutilisable et tout le reste va freeze.

ok mais sur le jeu d'instruction par exemple

Faire 1+1
Rajouter 2 au résultat précédent

pourquoi le PC ramerait pour faire une longue tache ?
Pourquoi il ferait pas juste faire 1+1.... attendre très longtemps puis rajouter 2 ..... ?

JazzChill2
2021-04-17 22:55:04

Après, si c'est une appli Java, tu peux dire de lancer l'app avec des valeurs min et Max de ram à consommer avec -Xmm et -Xmg comme variables à la commande java.

Ca évite qu'il bouffe toute la ram et le outofmemory

King_Foltest
2021-04-18 12:32:17

Le 17 avril 2021 à 22:29:42 :

Le 17 avril 2021 à 22:28:28 :
Justement ça ne crash pas, sa rame

Vraiment ?
Si je demande d'exporter un gros jeu vidéo de 20 gigas à un acer aspire 3610 de 2006 pourrave à 300 euros, il va finir un jour par l'exporter, mais juste plus lentement ? :(

La vitesse d'écriture ne dépend que du système de stockage (et de transmission, la vitesse ne sera pas identique entre échanger d'un PC à un autre, tout deux équipés du même SSD, selon que les deux communiquent par wifi ou par un cable USB3.0).

T'aura beau avoir un laptop gamer à 1500€ aec RTX3060 + 16go de ram, si dedans tu as un HDD 5400t/min, il mettra infiniment plus de temps à copier un fichier de 20go qu'un thinkpad reconditionné de 2010 à 150€ équipé d'un SSD M.2 NVMe

Xeranths
2021-04-18 14:00:49

Je vais essayer de répondre à la question du début en synthétisant tout ce qui a été dit et en rajoutant des trucs, même si je suis loin d'être un expert.
Les raisons d'un crash: y'en a beaucoup, mais en gros
- problèmes/incompatibilités matérielles (et éventuellement le logiciel qui y est lié les drivers, ou le programme de gestion)
genre ta carte graphique est trop pourrie pour gérer tel logiciel lié à tel jeu (par exemple) et donc ça crash. (anecdote: j'avais eu ça avec nvidia je crois, très chiant)
-problèmes dans les logiciels ( pour les + complexes en tout cas, ce sont des programmes qui sont dispersés et interagissent avec énormément de composants et logiciels, donc ils peuvent rencontrer des incompatibilités, par exemple 2 logiciels ayant 2 fichiers .dll pour interagir avec windobe qui rentrent en conflit)
-le crash est voulu : par le logiciel lui même ou par un autre avec + de droits
par exemple t'as un jeu qui tourne sur ta poubelle, mais windows décide de lancer un scan antivirus (parce que windows defender) et là t'as pas assez de ram, car même si ton jeu ne tourne pas forcément, il faut quand même stocker certaines info en mémoire vive ( genre que le jeu est ouvert, avec quels composants il communique, et les tâches qu'il exécute là maintenant en arrière plan), mais windows s'en fout, il a tt les droits, donc il crash ce qui est "inutile".
Ca peut être aussi de la volonté du dev (un programme du logiciel qui foire, ou bien qui prend trop de temps par rapport à la normale donc on fait crash et envoi d'un rapport d'erreur, alors que le pb c'est juste que ton pc est pourri).

Pour les lags, c'est une histoire de puissance de calcul, et de vitesse de com entre les composants, je pense que tu l'as compris.
Après si tu regardes ton gestionnaire de tâches tu remarques que ta RAM (ce sur quoi sont stockés infos les programmes qui tournent) est de base occupé à 20% environ par ton OS et autres programmes de base, alors que le processeur qui fait les calculs n'a pas souvent de pb, c'est parce que tt ce que tu as en arrière plan doit être temporairement stocké puis être traité par le proco en temps utile. Autre exemple, tu télécharge un truc et t'as une bonne co, un SDD, mais ça rame du cul quand même, c'est peut être à cause de ta carte ethernet qui pue tellement qu'elle a du mal à gérer le dl + les autres comms (t'imagine pas tt ce qui circule sans que tu le saches, tcpdump en admin sur linux si tu veux avoir une idée)

Les solutions aux crash (pas tous) c'est de libérer la mémoire vive, de s'assurer que tout les composants peuvent suivre la même cadence (je connais un mec qui a galéré à mettre un water cooling sur son pc, alors qu'avec un ventilo normal d'assez bonne qualité y'aurait eu aucun pb, car le reste de l'ordi était pas constitué de composants incroyables qui dégagent beaucoup de chaleur, et ce type est pour moi le parfait exemple des gens qui oublient qu'un ordi c'est un tout et qui se focus sur une partie), de s'assurer que le programme est supporté par la cadence de l'ordi et qu'il est compatible (architecture + logiciels de base + conflits avec logiciels tiers).

Voilà, il y a surement des corrections à faire, et ça reprend pas mal ce qui a été dit, même si j'ai essayé de donner des exemples compréhensibles (et dsl pour ceux qui voudront citer mon pavé :gni: ça va pas être pratique pour avoir le bon passage)

Infos
Gestion du forum

contact@geevey.com

API disponible. Utilisez le paramètre "api" en GET, peu importe le contenu, sur une page du site.

Notes

    ⚠️ Les archives de novembre sont désormais disponibles.
Non-assumage
    Personne n'a pas assumé de topic pour le moment.