¿Hay algún inconveniente del modificador "/ 3Gb" en boot.ini para Windows de 32 bits?

8

Microsoft aconseja utilizar el modificador / 3Gb en Boot.ini para obtener más memoria para un proceso que se ejecuta en un sistema de 32 bits.

Actualmente necesito mucha memoria para el proceso devenv (Visual Studio 2008) porque tengo una solución compleja que tiene muchos proyectos y formas y consume muchos recursos en tiempo de diseño.

Me gustaría preguntar, si alguien sabe, cuáles son los aspectos negativos del uso del modificador / 3Gb, ¿hay alguna circunstancia en la que no se recomiende usarlo?

windows performance memory 32-bit Bogdan_Ch
fuente
Gracias a todos los que respondieron, todas las publicaciones son muy informativas y hay muchas consideraciones a tener en cuenta. También leí algo de documentación y noté que para MS SQL Server no necesita esto incluso para sistemas de 32 bits, puede habilitar las Extensiones de
ventanas de

Respuestas:

11

En una máquina de escritorio, probablemente no haya problemas. El grupo paginado del kernel es más pequeño en una máquina W2K3 / WXP con el conjunto de conmutadores / 3GB. Esto probablemente no sea un problema para una máquina de escritorio porque no debería estar a punto de agotar su grupo paginado de kernel. En un servidor, agotar el grupo paginado del núcleo le causará problemas, y es mucho más probable que pueda agotarlo.

Aquí hay algunos buenos detalles sobre las consideraciones de memoria del núcleo asociadas con el modificador / 3GB. Si realmente lo desea, puede iniciar el depurador del núcleo NT y perfilar su sistema antes y después del cambio con la información de este documento: http://blogs.technet.com/markrussinovich/archive/2009/03/26 /3211216.aspx

Evan Anderson
fuente
3
Siempre me pregunto, cuando recibo votos negativos, por qué recibo votos negativos. No creo que nada en esta publicación sea incorrecto, pero si lo fuera, me gustaría saberlo para poder eliminar la publicación o corregirla. Tengo curiosidad por saber cuál es el problema que tienen los votantes negativos ... (y, por supuesto, me doy cuenta de que nunca volverán para responder a este comentario ... oh, bueno ...)
Evan Anderson
5

Tendrá menos memoria disponible para su núcleo: el conmutador ajusta el espacio de direcciones del modo de núcleo / división del espacio de direcciones del modo de usuario, anteriormente de 2 GB a 2 GB, de 1 GB a 3 GB. Lea la publicación de Raymond Chen en / 3GB, y los seguimientos, antes de continuar.

crb
fuente
5

Antes de realizar cualquier cambio, primero debe verificar si los procesos que desea ejecutar están vinculados con el indicador LARGEADDRESSAWARE. Con la bandera, no habrá cambios en la forma en que el proceso usa la memoria.

Puede usar las herramientas del SDK para esto:

dumpbin / headers exeName

Los encabezados que se escupen deben incluir:

La aplicación puede manejar direcciones grandes (> 2GB)

Hice la comprobación en devenv.exe y en VS2008 incluye la bandera.

Jack Bolding
fuente
4

Un montón de inconvenientes. De manera predeterminada, Windows asignará un grupo de memoria de 4GB a cada proceso, que se divide 50/50 entre los procesos en modo kernel (común a todas las aplicaciones) y los procesos en modo usuario (únicos para cada aplicación) (explicación simplificada). Por lo tanto, una aplicación que se ejecuta en el sistema tiene 2 GB de memoria para jugar, mientras que el sistema en sí tiene sus propios 2 GB. Nota importante: este segundo 2GB es el mismo 2GB para todas las aplicaciones que se ejecutan en el sistema.

El modificador / 3GB ajusta la división para que el modo de núcleo obtenga 1 GB y el modo de usuario obtenga 3 GB.

Ahora considere las aplicaciones que está ejecutando. Algunos requerirán más espacio en modo kernel, otros requerirán más espacio en modo usuario. Como el grupo de modo de kernel se comparte, puede quedarse sin memoria rápidamente si está ejecutando aplicaciones que presionan la memoria del modo de kernel. Por otro lado, si sus aplicaciones usan mucha memoria en modo de usuario, la implementación de / 3GB les dará el margen que necesitan.

Por lo tanto, se trata realmente de la naturaleza de las aplicaciones que desea ejecutar. La regla de oro es consultar al proveedor de la aplicación y leer la documentación; en particular, si el proveedor de la aplicación no tiene una recomendación de ninguna manera, debe comenzar a sospechar ... ¿han probado adecuadamente su aplicación o no? Esto es algo básico que todo vendedor debe saber.

Hay una muy buena discusión de todo aquí: http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

En su caso particular, creo que cambiar a 64 bits y obtener más RAM será una solución más viable, ya que / 3GB realmente no le dará lo que desea (¿funciona incluso en XP?)

Maximus Minimus
fuente
Creo que, en lugar de "grupo de modo de núcleo" mejor decir "espacio de direcciones virtuales de núcleo". También "compartido" significa para mí "idéntico para todas las aplicaciones". ¿Es tan?
dma_k
1

Lo hemos usado en un par de sistemas que ejecutaban aplicaciones de procesamiento de imágenes en muchas imágenes grandes, y nunca notamos ningún problema. En cualquier situación en la que necesite el Gig adicional de memoria de la aplicación, probablemente dejará que la aplicación se ejecute y no haga nada más con el sistema, por lo que probablemente no habrá mucho impacto.

Ward - Restablece a Monica
fuente
1

Solo funciona de manera confiable (excepto para la depuración de controladores, etc.) en un sistema operativo de servidor empresarial para binarios LARGEADDRESSAWARE.

Devenv no es un binario . SQL Server y Exchange son, por ejemplo.

Necesitaría un sistema operativo x64 bit y una edición VS x64 : se detecta LARGEADDRESSAWARE en x64 para romper el límite de 2 GB.

gbn
fuente
actaully devenv.exe es largeaddressaware.
Jack Bolding
correcto, me perdí eso en mi edición sobre x64. Editado nuevamente
gbn