La RAM está para ser usada.

Esta frase es cierta dentro de un contexto en particular. Se usa para permitir que el sistema operativo acelere disco a RAM tanto como sea posible, pues la RAM es significativamente más rápida que los discos duros.

Sin embargo, dentro del contexto de una aplicación de usuario, en realidad es una falacia. Algunos usuarios (e incluso algunos desarrolladores) no saben mucho sobre el funcionamiento interno de su computadora y usan esta frase fuera de su contexto correcto. Lo peor es que algunas veces ni siquiera les importa el consumo de la RAM. No les importan los derrames de memoria o piensan que si ocurren sólo una vez, no pasa nada. O piensan que los lenguajes y plataformas con recolección de basura (garbage collectors) se encargarán mágicamente de todo. Sin darse cuenta, acaban usando la frase en cuestión como un equivalente de:

La RAM está para ser desperdiciada.

Hay algunas cuestiones que en realidad alimentan este modo de pensar, llevándolos a concluir que una aplicación realmente debería poner tanta información como sea posible en la RAM y que, tarde o temprano, el sistema operativo lo manejará eficientemente. Más aún, que no hacerlo es un sacrificio de rendimiento.

Consideremos lo siguiente (sobresimplificaré para efectos de facilidad de explicación, pero el modelo es bueno). Por una parte:

• Cuando una aplicación solicita RAM y el sistema operativo la asigna, esa memoria queda reservada para el uso exclusivo de la aplicación hasta que ésta la libera. Una aplicación no puede saber (y no debería) si otra requiere o solicita RAM.
• Si la RAM física se llena y hay espacio de paginación (swap o paging) disponible en el sistema, el OS descargará algunas de las páginas menos usadas de la RAM hacia el espacio de paginación, sea una partición o un archivo. Cuando la RAM paginada se necesita nuevamente, se intercambia con otras páginas de RAM de las menos usadas. Ambas operaciones requieren de actividad en el disco duro. Eso es lo que hace a la paginación inherentemente lenta.
• El sistema operativo siempre dejará libre algo (digamos, 50 MB) de RAM física sin usar para que haya disponible cuando necesite reaccionar a una emergencia de inestabilidad de sistema.

Por otra parte:

• El sistema operativo usa memoria física para acelerar lecturas y escrituras a disco por medio de caché, de modo que cuando un sector de disco es leído múltiples veces, las subsecuentes se obtienen de la RAM, que es mucho más rápida.
• El OS sólo acelerará lecturas/escrituras a disco hacia RAM física, pues sería inútil “acelerar” de disco a disco.
• Cuando una aplicación solicita RAM, el OS liberará RAM usada para caché antes de asignarla al a aplicación solicitante. Esta operación no requiere actividad de disco si se están liberando lecturas aceleradas o escrituras ya fijadas; sin embargo, sí requiere de escribir en disco si necesita fijar escrituras aceleradas pendientes. Usualmente, el sistema operativo realiza esta fijación cuando la PC está en ocio, de modo que uno no lo nota y, cuando llega el momento, ya no hay escrituras pendientes por fijar.

Por último:

• Linux reporta el “tamaño residente en RAM” para un proceso como “consumo de RAM física”. Si uno quiere medir el consumo de RAM por una aplicación, se debe hacer con la swap desactivada. Por favor indíquenme cómo Windows reporta la RAM consumida por un proceso.
• Las escrituras a disco suelen ser más lentas que las lecturas.

La realidad sobre esta falacia es “cierto, el sistema operativo se encargará de eso, pero se muere el caché de disco y se provoca la paginación, alentando todo el sistema, incluyendo la propia aplicación“. Entonces: sí, el sistema se encarga, pero en realidad está recuperándose del error del programador a costa de una degradación global e innecesaria de sistema y la potencial inestabilida que conlleva.

Analicemos dos escenarios tomados de mi propia experiencia. Repito: estoy sobresimplificando. Úsese esto como modelo.

Caso 1: Un navegador acelera la red a disco en lugar de a RAM

Tienes un sistema con 2 GB of RAM, de los cuales tienes 1 GB libres (como en “tal vez usados por el caché de disco pero ciertamente disponible para las aplicaciones”). Tú ejecutas un navegador que acelera los recursos de red a disco porque es más rápido que el Internet (pues es más rápido que el Internet) y usa unos 300 MB of RAM.

1000 – 300 – 50 = 650

Acabas con unos 650 MB of RAM para aceleración de disco por memoria caché y 50 MB de RAM física real.

Cuando un navegador necesita un recurso de red, intenta cargarlo de disco (pues lo está acelerando). Sin embargo, el disco queda acelerado en la RAM por el sistema operativo y las lecturas subsecuentes se realizan en RAM. La penalidad en rendimiento apenas se nota.

Si el navegador quiere acelerar una página visitada por primera vez, la guardará ne disco. El SO acelerará la lectura a RAM y la pospondrá hasta que el sistema esté ne ocio (cuando estás leyendo el contenido del sitio). La penalidad en rendimiento apenas se nota.

Cuando cualquier otro proceso lee de disco, la probabilidad de pegarle al caché es alta porque hay 650 MB de RAM disponibles par esto. Incluso si se le falla al caché, lo que se lee de disco se acelera en RAM para los accesos subsecuentes. reading.

Entonces, ejecutas una máquina virtual que requiere de 450 MB de RAM. Ocurre lo siguiente:

• El sistema operativo libera 450 MB de caché de disco. Parte de este requiere de escrituras, parte no. Esta operación es sólo tan lenta como la cantidad de escrituras requeridas para fijar las escrituras aceleradas, así que no es tan lento. Además, el usuario en cierto modo lo espera porque le pidió a la PC cargar la VM.
• No hay paginación. No es necesario.
• Finalmente se asignan los 450 MB a la VM.
• La VM escribe a ese espacio físico de RAM asignado.

Aún quedan 200 MB disponibles para caché de disco, que el SO procurará usar eficientemente.

Ahora, el navegador quiere cargar algo de su “cache de disco”. Hay una probabilidad, claro que mayor que 0, de pegarle al caché y que el SO sirva el dato directamente desde la RAM. Supongamos que no, que fue leída desde disco. El navegador aún está acelerando la navegación pues el disco local es más rápido que el Internet. Más aún, el SO acelerará este objeto en la RAM para sus accesos subsecuentes.

Claro: la VM continúa corriendo desde la RAM sin necesitar de ningún tipo de paginación (o hiperpaginación). El sistema responde perfectamente. El usuario sabe (o debería saber) que si quiere liberar memoria, debe cerrar la VM o el navegador.

Caso 2: Un navegador usa más RAM que la que requiere, para su aceleración

Tienes un sistema con 2 GB of RAM, de los cuales tienes 1 GB libres (como en “tal vez usados por el caché de disco pero ciertamente disponible para las aplicaciones”). Tú ejecutas un navegador que acelera los recursos de red a disco porque es más rápido que el Internet (pues es más rápido que el Internet) y usa unos 300 MB of RAM.

1000 – 600 – 50 = 350

Acabas con unos 350 MB of RAM para aceleración de disco y 50 MB de RAM física real.

Cuando el navegador necesita un recurso de red, trata de cargarlo desde su asignación de RAM, así que es muy rápido (aún así, tiene que leerlo primero de disco si no estaba previamente disponible en RAM).

Cuando cualquier otra aplicación lee de disco hay una baja probabilidad de pegarle al caché. En cualquier caso, la probabilidad general de que otra aplicación le pegue al caché es más baja, pues la memoria está exclusivamente asingada para el navegador. Esto incrementa significativamente la probabilidad de acceder a disco, lo que puede llevar a una alentar todo el sistema.

Minimizar el navegador no libera memoria para otras aplicaciones. la memoria aún está asignada para su uso exclusivo para éste.

Entonces, ejecutas una máquina virtual que requiere de 450 MB de RAM. Ocurre lo siguiente:

• El sistema operativo libera 350 MB de caché de disco. Parte de este requiere de escrituras, parte no. Esta operación es sólo tan lenta como la cantidad de escrituras requeridas para fijar las escrituras aceleradas, así que no es tan lento.
• Determina los 100 MB menos usados de RAM y las mueve al espacio de paginación. Esta operación es lenta pues implica varias escrituras inevitables a disco.
• Finalmente se asignan los 450 MB a la VM
• La VM escribe a ese espacio físico de RAM asignado.

El sistema ya no tiene caché de disco. Cuando otra aplicación necesita leer de disco, no le pegarán al inexistente caché y el SO tendrá que acceder físicamente al disco para servir esta petición. Esto es lento. Lo peor es que el acceso a disco no será acelerado para sus subsecuentes lecturas.

Ahora, el navegador quiere cargar algo desde su propia “caché de memoria” (que, por cierto, tal vez está paginada a disco). Puede pasar una de dos:

Si el recurso a extraer del caché de RAM de la aplicación está paginado en disco, el SO necesitará leerlo de vuelta. Puesto que los datos leídos ahora serán memoria “más reciente usada”, el SO podría intercambiarlos de disco contra algo de la RAM de la VM o de otra aplicación menos usada. Esta operación es lenta pues implica varias escrituras inevitables a disco. O:

Si el recurso aún está en la propia “caché de memoria” de la aplicación, será extraída como de rayo de la RAM. Sin embargo, la VM aún necesita su propia RAM para continuar al igual que las demás aplicaciones. Esto fuerza al sistema operativo a usar paginación nuevamente. Además, no hay RAM disponible para caché de disco y otras solicitudes de disco estarán continuamente siendo servidas desde disco sin la posibilidad de acelerar las subsecuentes hacia RAM. Esto genera una actividad constante a disco, alentando todo el sistema incluyendo al navegador. El “caché de memoria” de la aplicación no sirvió para nada.

Claro que la máquina virtual continúa corriendo y su RAM se necesita constantemente, así que la escritura a disco por paginación se vuelve una constante. El sistema operativo se alenta por lo que se llama hiperpaginación. En casos extremos, el sistema deja de responder, impidiendo al usuario de siquiera cerrar una de las dos aplicaciones para recuperarlo.

Conclusiones

Sí, la RAM está ahí para ser usada cuando se necesita, no para desperdiciarse. La RAM es un recurso limitado. Hay maneras de usar la RAM eficientemente. Por ejemplo, cargar los índices de un buzón de correo en RAM (sin cargar el contenido completo del buzón) puede, si se hace correctamente, acelerar significativamente la búsqueda de mensajes.

Sin embargo, acelerar disco a RAM puede que no sea una buena idea. La aceleración ya se hace por el SO, así que sólo se desperdicia una función eficiente del sistema operativo. A veces puede ser una buena idea, pero lo más probable, especialmente en aplicaciones de escritorio, es que no.

RAM is there to be used.

This phrase is true within a particular context. It is used to let the operating system cache as much disk as possible into RAM, as RAM is significantly faster than hard disks.

However, within the context of a user-space application it is actually a fallacy. Some users (and even some developers) don’t know much about the inner workings of their computers, and use this phrase outside of its proper context. What is worse, sometimes they don’t even care much about RAM consumption. They don’t care about memory leaks, or think that if memory leaking occurs only once, it’s fine. Or they think garbage-collected frameworks or languages will take care of everything by magic. Without knowing, they end up using the aforementioned phrase as the equivalent of:

RAM is there to be wasted.

There are some issues that may lead to actually feed this thought, leading them to think that an application actually should put as much information as needed in RAM, and that, sooner or later, “the OS will handle it efficiently”. Furthermore, that not doing this is just a performance sacrifice.

Consider the following (I’ll oversimplifying for the sake of easy explanation, but the model is true). On one hand:

• When an application requests for RAM and the OS allocates it, the memory is being reserved for its exclusive use until the application frees it. An application can not know (and should not know) if another application requires or requests RAM.
• If physical RAM gets topped and there is swap space available in the system, the OS will move out some of the least used RAM pages out to swap space, be it a partition or a file. When the paged-out RAM in swap space is needed, it gets swapped with other least-used physical RAM pages. Both operations require hard disk activity. That’s what makes swapping inherently slow.
• The operating system will always leave some (say, 50 MB) physical RAM unused, so it has RAM available to react to a system instability emergency.

On the other hand:

• Operating systems use free physical memory to cache disk reads and writes, so when a disk sector is read multiple times, subsequent reads are read from RAM, which is much faster.
• The OS will only cache disk reads/writes to free physical RAM, as it would be useless to “cache” disk to disk.
• When an application requests for RAM, the OS will free RAM used by disk cache before allocating it to the requesting application. This operation doesn’t require disk activity if freeing up RAM-cached reads or flushed disk writes; however, it does require disk writes if freeing up unflushed RAM-buffered disk writes. Usually, the OS flushes cached disk writes when system is idle, so you don’t really notice it, and when the time comes, everything is already flushed.

And last:

• Linux, report “resident RAM size” for a process as “physical RAM usage”. So if you measure your application RAM requirements, you should do it with your swap partitions disabled. Please enlighten me about how Windows reports RAM for a process.
• Disk writes are usually slower than disk reads.

The actual truth around this fallacy is “sure, the OS handles it, but you kill the disk cache and encourage memory swapping, slowing the whole system down, including your own application“. So yes, the system “takes care” of it, but it is actually recovering from the programmer’s mistake at the cost of overall, unnecessary, system slow down and potential instability.

So let’s analyze two scenarios taken out of my own experience. I repeat: I am oversimplifying. Use this as a model.

Case 1: A browser caches on disk instead of RAM.

You have a system with 2 GB of RAM, out of which you have 1 GB free (as in “maybe used by disk cache but surely available for applications”). You fire up a web browser that caches resources on disk (because it is faster than the Internet) and needs about 300 MB of RAM.

1000 – 300 – 50 = 650

You end up with about 650 MB of RAM for disk cache optimization and 50 MB of actual free physical RAM.

Whenever the browser needs a network resource it tries to load it up from disk. However, disk gets cached on RAM by the OS, so subsequent reads will be read out from RAM. Performance penalty it is barely noticeable.

If the browser wants to cache a newly-visited website, it will save it to disk. The OS will buffer the write to RAM so it will postpone it until the system is idle (when you are reading the website). Performance penalty it is barely noticeable.

Whenever another application reads from disk there is a high probability of hitting the cache because there is 650 MB of RAM available for this purpose. Even if missing the cache, whatever was read from disk will be cached in RAM for subsequent reading.

You, then, fire up a VM that requests 450 MB of RAM. The following occurs:

• The operating system frees up 450 MB of disk cache. Some of it requires writing, some not. This operation is only as slow as the disk-writes required for unflushed writes, so it’s not really that slow. Besides, the user somewhat expects it because he just commanded the PC to load up a VM.
• There is no swapping at all. There is no need.
• It finally allocates 450 MB to the VM.
• The VM writes to that physical RAM allocated for it.

There is still 200 MB available for disk caching, which the OS will try to efficiently use.

Now, the browser wants to load something from “disk cache”. There is some probability, higher than 0 of course, of hitting the cache and the OS serving the data directly from RAM. Let’s assume not: it was read from disk. The browser is still accelerating web surfing, as the local disk is still faster than the Internet. Furthermore, the OS will cache the object on RAM for subsequent access.

Of course, the VM continues running from RAM without ever needing of any kind of swapping or disk trashing. The system is fully responsive. The user knows (or should know) that if it wants to free up RAM it will close the VM or the browser.

Case 2: A browser uses more RAM than it should, for caching.

You have a system with 2 GB of RAM, out of which you have 1 GB free (as in “maybe used by disk cache but surely available for applications”). You fire up a web browser that could work really nice with 300 MB of RAM but instead caches everything up for the sake of speed and ends up using 600 MB of RAM.

1000 – 600 – 50 = 350

You end up with about 350 MB of RAM for disk cache optimization and 50 MB of actual free physical RAM.

Whenever the browser needs a network resource it loads it up from its own RAM allocation, so it is really fast. (It still has to load it first from disk if not previously available on RAM).

Whenever any other application reads from disk there is a lower probability of hitting the cache. In any case, the overall probability of the other applications of hitting the cache is lower, as memory is exclusively allocated for the web browser. This significantly increases the probability of accessing disk, which may lead to slow the whole system down.

Minimizing the browser does not free memory for other applications. Memory is still being allocated for exclusive use by it.

You, then, fire up a VM that requests for 450 MB of RAM. The following occurs:

• The operating system frees up 350 MB of disk cache. Some of it requires writing, some not. This operation is only as slow as the disk-writes required, so it’s not really that slow.
• It determines the least used 100 MB of physical RAM and moves it out to swap space. This operation is slow, as it involves a lot of unavoidable on-the-fly disk writes.
• It finally allocates 450 MB to the VM application.
• The VM writes to that physical RAM allocated for it.

The system has no memory for disk cache anymore. Whenever other applications need to read from disk, they will miss the cache and the OS will have to physically access the disk to serve the request. This is slow. What is worse, the disk access will not be cached for subsequent reading.

Now, the browser wants to load something from its own “RAM cache” (which, by the way, may probably be out in swap space, now). It may happen one of two things:

If the RAM cache resource is on swap space, the OS will need to read it back. Since that data will be now a “more recently used” memory page, the OS might swap RAM and disk with some contents of the VM or another least-used application. This operation is slow because it requires another lot of unavoidable on-the-fly disk writes. Or:

If the resource is still in the application own “RAM cache”, it will be retrieved flash-fast from RAM. However, the VM still needs its own RAM to continue, and so do all other applications. This forces the operating system to swap memory again. Also, there is no RAM available for disk cache, and other applications disk requests will still served continuously from disk without the possibility of RAM caching for subsequent access. This generates constant disk activity, slowing all the system, including the browser. The browser “extra RAM cache” did no good at all.

Of course, the VM continues running and its RAM will continuously be needed back, so disk writing becomes a constant. The whole system slows down by what is called disk trashing. In really bad cases, the system may become unresponsive, restricting the user from even being able to close one of the two applications to recover the system back.

Conclusions

Yes, RAM is there to be used when it is needed, not wasted. RAM is a limited resource. There are ways to use RAM efficiently. For instance, loading the indexes of a mailbox in RAM (but not the whole mailbox content), if done correctly, may significantly speed up mail searching.

However, caching disk to RAM might not be a good idea. The caching is already done by the OS, so it is just discarding an efficient OS function by an application. Sometimes it may be a good idea but most probably, particularly in desktop applications, it is not.

El texto dice:

Uno o más de los mensajes seleccionados no tienen el cuerpo descargado localmente, ¿Desea que Opera descargue los cuerpos faltantes antes de la exportación (sumamente recomendado)?

:-D

That’s why Opera can be set to ignore core X fonts, by unchecking the Enable Core X fonts configuration option. You can use this as a workaround.

So, the result of having this option enabled can be compared in the following images. The first image shows the rendering when the font-family: "Deja Vu Sans", sans-serif directive is used. The second image shows the same page when the “Deja Vu Sans” option is removed from the directive. In this second case, Opera renders the text using the “sans-serif” font, whatever it matches.

Seen from a different perpective, it appears to be that when Opera asks X for a font, X returns an antialised core font. Does this happen on other distributions too?

Continuing with the stream of web browser interoperability issues I recently found how to make Opera 10 work with a Cisco Secure Access Control Server 4.1.

The problem I experienced is briefly described as, clicking any option in the menu (in the left frame) will open the menu again in the right frame, instead of actually showing the selected option.

The answer is simple: set Opera to identify as Firefox for that domain or IP. This is located under Tools » Preferences » Advanced » Content » Manage Site Preferences. Add the site and under Network, change “Browser identification” to “Identify as Firefox”.

Here are the screenshots. Click on them.

Opera identified as such.

Opera identified as Firefox.

The analysis narrows down to this code in the menu:

// unfortunately the Object model in IE doesn't match the Netscape one so we have to check the browser...
if( "Netscape" == navigator.appName )
{
	obj.href=sequence_url;
}
else
{
	ua=navigator.userAgent;
	v=navigator.appVersion.substring(0,1);
	if ((ua.lastIndexOf("MSIE")!=-1) && (v!='1') && (v!='2') && (v!='3'))
	{
		// MSIE 4.0 and later.
		obj.href=sequence_url;
	}
	else
	{
		parent.parent.R.location=sequence_url;
	}
}

(some code snipped)

<A HREF="" TARGET=R onClick="getURL( this , 'setup.exe?action=make_r_fs&option=users' )" >
<IMG SRC="images/cisco_buttons/user-up.gif" BORDER=1 ALT="User Setup"></A>

So Cisco is actually trying to detect the UA, but instead of assuming a standards-complaint browser and applying special fixes for IE, it assumes IE and applies a special fix for Mozilla (Netscape).

That’s why changing the identifier for that site actually works. Now the JavaScript code correctly detects the UA and performs the correct action of loading the page in the “R” frame.