A troca aconteceu aparentemente quando as páginas de RAM inativas estavam realmente ativas.
( Atualização: como foi esclarecido em um comentário, este não é o seu caso. Portanto, as pessoas com o mesmo problema podem pular para a regra horizontal .)
Ou seja, você tinha muitos programas em execução e o kernel trocou algumas páginas. Então você saiu de alguns programas. O kernel marca suas páginas de RAM como inativas. Mas ele não trocará as páginas de volta para a RAM até que essas páginas sejam necessárias. Isso resulta em páginas inativas e trocadas.
Por que não trocar preventivamente as páginas? Porque isso seria apostar contra as probabilidades: a longo prazo, você perde. Vamos pensar em um exemplo simplificado: dois programas A e B que não cabem na RAM ao mesmo tempo. O programa A ainda está em execução e todas as páginas trocadas pertencem a A. O programa B foi encerrado e todas as páginas inativas pertencem a B.
Se o kernel trocar preventivamente as páginas de A e imediatamente após:
- O programa A precisa acessar suas páginas -> Você vence - as páginas já estão na RAM.
- você lança B novamente -> Você perde - você "pagou" o custo de trazer as páginas para a RAM e agora precisa enviá-las de volta.
- você inicia outro programa C -> Você perde se A e C não couberem na RAM ao mesmo tempo. Se eles se encaixam, você está quieto.
Também leve em consideração que a troca (gravação no disco) é mais cara que a troca (leitura do disco). O que torna essa "aposta" ainda mais desinteressante.
Resumindo: confie no seu kernel e não tente enganá-lo.
Atualização:
verifica-se que a memória inativa não funciona, pois o artigo Usando o Monitor de Atividade para ler a Memória do Sistema levou muitas pessoas a acreditar que ela funciona. A definição dada no artigo para memória inativa está correta:
Esta informação está na RAM, mas não está sendo usada ativamente, foi usada recentemente.
Mas o exemplo a seguir é totalmente enganador e simplificado demais (como meu exemplo para ser franco):
Por exemplo, se você estiver usando o Mail e o encerrar, a RAM que o Mail estava usando será marcada como memória inativa. A memória inativa está disponível para uso por outro aplicativo, assim como Memória livre. No entanto, se você abrir o Mail antes que sua memória Inativa seja usada por um aplicativo diferente, o Mail abrirá mais rapidamente porque sua memória Inativa é convertida em Memória Ativa, em vez de carregá-la da unidade mais lenta.
Eu procurei por mais recursos online e acabei indo para este tópico na lista de discussão do kernel do darwin, que é bastante informativa. Citando Jim Magee (da equipe de darwin - eu acho):
Em resumo, o sistema VM do kernel, ao lidar com a pressão da memória, varre as páginas em uso e tenta mantê-las em equilíbrio entre as marcações ativas e inativas. As páginas inativas são digitalizadas para reutilização enquanto marcadas como inativas. Se eles foram reutilizados, são marcados como ativos e alguma outra página deve passar do estado ativo para o inativo para detectar se está em uso ativo. Portanto, inativo é um nome impróprio. É uma abreviação de "possivelmente inativo, vamos tentar verificar isso".
Como você descobriu, o saldo interno pelo qual nos esforçamos (atualmente) é de aproximadamente 2/3 ativo versus 1/3 inativo ...
Isso explica o comportamento que você observa. Ou seja, as páginas inativas que você vê pertencem a programas em execução que não foram usados recentemente. Portanto, quando você inicia um novo programa, as páginas inativas são trocadas. Ao mesmo tempo, as páginas de outros programas são marcadas como inativas para manter a proporção 2/1 de ativo versus inativo.
O tópico também contém algumas sugestões para aprender mais sobre os componentes internos do darwin. Existem também algumas sugestões, caso você comece a investigar o uso da memória devido a problemas de beachball (que geralmente têm pouco a ver com isso).
A conclusão permanece a mesma: confie no seu kernel e não tente enganá-lo. :-)