Mémoire maximale utilisable par un système RHEL 6 32 bits

Eh bien, je ne m'attends pas à une réponse concise que celle disponible ici .

Ce que je comprends du operating system 32 bits, c'est que l'adresse est exprimée en 32 bits, donc au plus le operating system pourrait utiliser 2 ^ 32 = 4 Go d'espace memory

Le plus que le process peut adresser est de 4 Go. Vous êtes potentiellement confus de la memory avec l' espace d'adressage . Un process peut avoir plus de memory que d'espace d'adressage. C'est parfaitement légal et assez commun dans le traitement video et d'autres applications intensives en memory. Un process peut être alloué des dizaines de Go de memory et de l'échanger dans et hors de l'espace d'adressage à volonté. Seulement 2 Go peuvent aller dans l'espace d'adressage de l' user à la fois.

Si vous avez un garage pour quatre voitures chez vous, vous pouvez toujours posséder une cinquantaine de voitures. Vous ne pouvez tout simplement pas les garder tous dans votre garage. Vous devez avoir un stockage auxiliaire ailleurs pour stocker au less 46 d'entre eux; les voitures que vous gardez dans votre garage et celles que vous gardez dans le parking dans la rue.

Cela signifie-t-il un operating system 32 bits, que ce soit Windows ou unix, si la machine possède un file RAM + disque dur de plus de 4 Go, par exemple 8 Go de RAM et 20 Go de page, il n'y aura jamais de «memory épuisée»?

Absolument ça ne veut pas dire ça. Un seul process pourrait utiliser plus de memory que cela! Encore une fois, la quantité de memory utilisée par un process est presque totalement indépendante de la quantité d'espace d'adresse virtuelle utilisée par un process. Tout comme le nombre de voitures que vous gardez dans votre garage n'a aucun rapport avec le nombre de voitures que vous possédez.

De plus, deux process peuvent partager des pages de memory non privées . Si vingt process chargent tous la même DLL, les process partagent tous les pages de memory pour ce code. Ils ne partagent pas l' espace d'adressage de la memory virtuelle , ils partagent la memory .

Mon sharepoint vue, au cas où ce n'est pas clair, c'est que vous devriez cesser de penser à la memory et à l'espace d'adressage comme la même chose, parce que ce n'est pas la même chose.

si cette machine OS 32 bits possède 2 Go de RAM et 2 Go de file de page, l'augmentation de la taille du file de la page n'aidera pas les performances. Est-ce vrai?

Vous avez cinquante voitures et un garage pour quatre voitures, et un parking de 100 places dans la rue. Vous augmentez la taille du parking à 200 places. Est-ce que l'une de vos voitures est plus rapide parce que vous avez maintenant 150 places de stationnement supplémentaires au lieu de 50 places de stationnement supplémentaires?

La réponse de Ramesh est complètement fausse. Un process ne peut pas avoir plus de memory que d'espace d'adressage, et simplement parce qu'il ne peut pas y répondre !! Pour utiliser plus de 4 Go, le process doit y accéder par l'adresse, comme utiliser des ponters en C / C ++. Si vous pouvez supposément avoir, par exemple, 10 Go de RAM, comment pouvez-vous dire au process d'accéder aux données situées à 5 Go, si vos pointeurs, en 32 bits, peuvent atteindre 4 Go au maximum? C'est impossible. Toutes ses explications sont liées au operating system. Il peut activer certains blocs de 4 Go au maximum, à partir d'un pool de, disons, 64 Go. Il y a donc toujours 4 Go maximum, et n'importe quel process peut accéder au plus 4 Go. Ensuite, pour un process différent, le SO peut activer un bloc différent de 4 Go du pool, mais le process sera à nouveau limité à 4 Go. En fait, même si un pointeur 32 bits peut traiter jusqu'à 4 Go, la limite pour un process 32 bits est de 3 Go.