Pourquoi une mémoire partiellement saturée provoque-t-elle un décalage?

Pourquoi une mémoire partiellement saturée (disons 80%) retarde-t-elle beaucoup le périphérique, même s'il reste de l'espace disponible pour stocker davantage de données? Ce que je pense, c’est que cela continue à bien fonctionner jusqu’à 99%.

Je le remarque plus sur le mobile que sur le PC, car sa mémoire vive est plus petite, par exemple, mon mobile dispose de 2 Go de RAM; Quand j'ai moins de 1 Go de RAM libre, ça prend beaucoup de temps! Pourquoi cela se produit-il, même s'il doit encore utiliser ~ 1 Go?

Il y a beaucoup de choses en jeu ici, mais je vais essayer de l'expliquer aussi simplement que possible et de manière applicable à pratiquement n'importe quel système d'exploitation.

Il y a 2 principes de base ici:

1. La somme totale de tout ce qui doit être en RAM et de tout ce qui gagnerait à être en RAM est presque toujours supérieure à la taille de la RAM. Les éléments qui gagneraient à être dans la RAM incluent les ensembles de travail de processus et la liste de veille. Ce dernier contient des données et du code qui étaient autrefois actifs mais qui sont depuis devenus inactifs. Une grande partie de celle-ci sera réutilisée, une partie très bientôt, il est donc avantageux de la conserver en RAM. Cette mémoire agit comme une sorte de cache mais n’est pas vraiment essentielle, c’est donc dans la catégorie de la mémoire disponible. Comme la mémoire libre, il peut être rapidement attribué à tout programme qui en a besoin. Dans l'intérêt de la performance, la mémoire de veille doit être grande.

2. La fréquence d'utilisation des blocs de mémoire est loin d'être aléatoire, mais elle peut être prédite avec une précision considérable. La mémoire est divisée en blocs, souvent 4K octets. Certains blocs sont consultés plusieurs fois par seconde, tandis que d'autres ne le sont pas depuis plusieurs minutes, heures, jours ou même plusieurs semaines si le système est en fonctionnement suffisamment longtemps. Il existe une large gamme d'utilisation entre ces 2 extrêmes. Le gestionnaire de mémoire sait quels blocs ont été utilisés récemment et ceux qui ne l'ont pas été. Il est raisonnable de penser qu'un bloc de mémoire auquel on a accédé récemment sera de nouveau nécessaire. La mémoire qui n'a pas été utilisée récemment ne sera probablement plus nécessaire de sitôt. Une longue expérience a prouvé que c'était un principe valable.

Le gestionnaire de mémoire profite du deuxième principe pour atténuer largement les conséquences indésirables du premier. Pour ce faire, il faut équilibrer les données récemment consultées dans la RAM tout en conservant des données rarement utilisées dans les fichiers d'origine ou le fichier d'échange.

Lorsque la RAM est abondante, cet équilibre est facile. Une grande partie des données récemment utilisées peuvent être conservées dans la RAM. C'est une bonne situation.

Les choses se compliquent lorsque la charge de travail augmente. La somme totale des données et du code utilisés est plus grande mais la taille de la RAM reste la même. Cela signifie qu'un plus petit sous-ensemble de cela peut être conservé dans la RAM. Certaines des données moins récemment utilisées ne peuvent plus être dans la RAM mais doivent être laissées sur le disque. Le gestionnaire de mémoire s'efforce de maintenir un bon équilibre entre la mémoire en utilisation active et la mémoire disponible. Mais à mesure que la charge de travail augmente, le gestionnaire de mémoire sera obligé de donner plus de mémoire disponible aux processus en cours d'exécution. Ce n'est pas une bonne situation mais le gestionnaire de mémoire n'a pas le choix.

Le problème est que le déplacement des données vers et depuis la RAM pendant l'exécution des programmes prend du temps. Lorsque la RAM est abondante, cela n'arrivera pas très souvent et ne sera même pas remarqué. Mais lorsque l'utilisation de la RAM atteint des niveaux élevés, cela se produit beaucoup plus souvent. La situation peut devenir si grave que passer plus de temps à déplacer des données de la mémoire vive qu’à consacrer à leur utilisation réelle. Il s’agit là d’une tâche ardue que le gestionnaire de mémoire s’efforce d’éviter mais qui ne peut souvent pas être évitée avec une charge de travail élevée.

Le gestionnaire de mémoire est à vos côtés, essayant toujours de maintenir au mieux les performances, même dans des conditions défavorables. Mais lorsque la charge de travail est importante et que la mémoire disponible est insuffisante, il faut faire des choses mauvaises pour continuer à fonctionner. C'est en fait la chose la plus importante. La priorité est d’abord de garder les choses en marche puis de les faire aussi vite que possible.

Tous les systèmes d'exploitation modernes utilisent une mémoire par ailleurs inutilisée pour la mise en cache des données afin de pouvoir y accéder à partir d'une mémoire vive rapide au lieu d'un stockage plus lent. Ils signalent généralement cela sous forme de mémoire disponible, car les applications peuvent vider le cache et l'utiliser s'il le faut, mais il est toujours utilisé. Moins il y en a, moins les données peuvent être mises en cache et plus l'ordinateur sera lent.

Cette réponse a été principalement réécrite pour réorganiser la structure et rendre le message plus clair. Je l'ai aussi ouvert comme réponse à un wiki de la communauté; N'hésitez pas à éditer.

La pagination est un schéma de gestion de la mémoire par lequel des processus sont attribués à des blocs de mémoire de taille fixe. Lorsque l'utilisation de la mémoire atteint un niveau élevé (c'est-à-dire une capacité de 80%), la pagination commence à s'étendre de la RAM à la vRAM (RAM virtuelle).

La vRAM est située dans le stockage système, généralement sur un disque dur, ou dans d'autres emplacements de stockage importants.

Les processus se voient attribuer une partie de votre disque dur à exécuter en tant que mémoire et traiteront leur section en tant que RAM. Il s'agit d'un processus parfaitement normal, cependant, lorsque le temps passé à transférer des données vers et à partir de la vRAM augmente, les performances du système diminuent.

Alors que la CPU dédiée permet d’accéder directement à la RAM dédiée via la carte mère, ce qui permet une connexion rapide, la RAM virtuelle doit effectuer un câblage transversal entre la carte et l’emplacement de la vRAM.

Cela ne provoque toutefois qu'un léger impact sur les performances. Lorsque la fréquence de la pagination vers vRAM a lieu augmente considérablement (lorsque la RAM dédiée approche de sa capacité), des ralentissements ont lieu.

Thrashing est la pratique de transférer rapidement et rapidement des pages de mémoire dans votre mémoire virtuelle. Cela pèse lourdement sur les performances car il faut plus de temps pour extraire et traiter les données.

Disons que vous voulez écrire un nombre de 30 chiffres. Vous pouvez soit vous asseoir à côté de votre écran avec votre bloc-notes et l'écrire (en utilisant la mémoire dédiée), soit vous vous souvenez de morceaux de 5, courir dans la pièce suivante et l'écrire sur votre bloc-notes (en utilisant la mémoire virtuelle). Les deux font le travail, mais lequel va être plus rapide?

En savoir plus sur thashing ici !

Un grand merci aux contributeurs de cette réponse, y compris Daniel B , xenoid et Jon Bentley .

C'est parce que le système d'exploitation doit faire beaucoup de pagination (chargement de parties de programmes actifs) et de permutation (déplacer des données de la RAM vers la HD et vice-versa) pour que votre logiciel continue à fonctionner. Lorsque de nouvelles pages nécessitant plus d’espace que les 20% disponibles doivent être chargées, le système d’exploitation devra échanger les pages existantes dans la RAM qu’il considère moins susceptibles d’être utilisées prochainement. Surtout au démarrage d'autres programmes. Échanger et revenir en arrière dans les pages prend beaucoup de temps et ralentit considérablement les performances de votre PC, car vous travaillez maintenant à la vitesse du disque dur, pas de la mémoire vive.

Il est utile, sur un disque dur, de créer une partition spéciale sur votre disque dur et de l’affecter à un espace "swap" dédié (ne pas l’utiliser pour de "vrais" fichiers) afin que le swap soit moins affecté par la fragmentation du disque dur .

N'oubliez pas que les disques durs ont un ordre de grandeur plus lent que la RAM, et que la RAM elle-même n'est pas si rapide que ça (pour l'architecture générale). Par ordre de rapidité d’accès (où chaque échelon est un ordre de grandeur plus lent que celui ci-dessus), vous avez

1. Registres de processeur - Concrètement, les registres sont disponibles dans un cycle de processeur . Étant donné que les processeurs font des milliards de cycles par seconde (3 GHz = 3 milliards de cycles par seconde), la vitesse est folle.
2. Cache du processeur - Dépend du niveau, mais reste assez rapide (disponibilité de 3 à 5 cycles pour le cache N1).
3. Random Access Memory (RAM) - La partie aléatoire signifie que vous ne savez pas dans quel état il se trouve lorsque vous y accédez. Pensez à un livreur de colis qui doit s’arrêter, ramasser le colis, se diriger vers la porte, sonner à la porte et attendre une réponse. Peut-être que vous n'attendez pas du tout, ou peut-être que vous attendez une minute ou deux pour que Mme Smith se mêle à la porte de l'arrière de la maison. En termes pratiques, nous parlons de 14 à 27 cycles (en fonction de l'état de la mémoire vive lorsque nous y avons accédé).
4. Disque dur - Il y a un processus physique ici maintenant et bien que cela se produise aussi rapidement que possible, vous attendez que les têtes bougent et les pistes se déplacent sous ces têtes. Concrètement, un disque dur à 7 200 tr / min peut effectuer une révolution en environ 4 ms , soit environ 750 000 cycles pour un processeur de 3 GHz . C'est lent.

Le gestionnaire de mémoire virtuelle est un joueur. Il parie que vous n’avez pas besoin de toute votre mémoire vive tout le temps, il faut donc deviner et lancer les dés que votre programme de documentation (qui est en arrière-plan depuis 10 minutes pendant que vous lisez ceci) n’est pas vraiment important et il pousse au disque dur.

Mais ensuite, vous cliquez sur le document! Maintenant, le VMM doit charger toutes ces données depuis le disque dur. Pire encore, si vous manquez de RAM, il doit maintenant transférer d'autres données (plus de jeu) sur le disque dur pour libérer de l'espace. Linux aime vivre sur le bord ici. Il remplira la grande majorité de la RAM avec des données fréquemment utilisées (idéal pour les serveurs avec peu de processus).

La réponse raclante résiste assez bien. Si vous le pouvez, vous pouvez minimiser la rapidité avec laquelle cela se produit en réduisant le swappiness (la quantité de RAM que le système permettra d'utiliser avant de déplacer des éléments vers un espace d'échange). J'aime configurer les systèmes pour qu'ils restent en dehors de la permutation jusqu'à ce que la RAM atteigne 99% pour les applications serveur, car la valeur par défaut signifierait que je devrais coder pour que les choses n'utilisent que 80% de la RAM pour tirer parti de la mise en cache sans être pénalisé pour avoir poussé. le système dans l'espace d'échange.