Na Parte 1 dessa série, apresentei o PlayStation 3 (PS3) Linux e suas vantagens e desvantagens como um ambiente de desenvolvimento. Essa segunda parte abrange algumas das coisas que podem ter um impacto significativo em um desempenho do sistema PS3 executando Linux.

Nem todos os conselhos aqui funcionarão para todos. Se você estiver executando gráficos, não pode simplesmente executar o sistema sem X. Por outro lado, se você não estiver executando gráficos, nada mais faz qualquer diferença na área de cobertura de memória do sistema.

O foco na memória pode parecer estranho se você estiver acostumado com sistemas de desktop que nunca montaram uma unidade de troca irritados, mas, de fato, o PS3 não possui memória suficiente para um moderno desktop Linux sentir-se confortável nele fora da caixa. Com uma instalação padrão do Fedora 7, o sistema gasta grande parte do tempo (e do seu) fazendo troca. A troca impõe uma grande multa em qualquer sistema; em um sistema construído em torno de uma unidade de disco de 2,5 polegadas acessada através de um hypervisor, com memória principal que é substancialmente mais rápida do que você encontra na maioria dos desktops, o contraste é até mais nítido do que é em um sistema desktop mais tradicional.

Uma outra observação: No meu sistema de teste, a reinicialização era não confiável sob o kernel 2.6.21 que foi originalmente instalado. O kernel 2.6.23 corrigiu isso, utilizando a versão do CD de complementos do PS3 ou a versão do atualizador padrão do Fedora. Em geral, o kernel do CD de complementos do PS3 é provavelmente sua melhor opção.

Reduzindo a Utilização da Memória

Este tópico vai e vem em importância. Para a maioria de usuários Linux de desktop, a ideia de que seria realmente necessário fazer algo para reduzir a utilização da memória é uma recordação distante. Além disso, como os processos tendem a aumentar para preencher o espaço disponível, mesmo quando uma máquina com 64 MB de memória principal foi considerada um servidor eficaz, simplesmente não havia muito software em execução e ela não precisava de tanta memória. De qualquer forma, o PS3 é um dos sistemas no qual a utilização da memória é muito importante e o Fedora 7, apesar de fascinante, não foi projetado em torno de sistemas de memória pequena.

Para reduzir a utilização da memória, inicie identificando os maiores consumidores de memória. Uma maneira fácil de fazer isso é com principal, que lhe fornece uma exibição ativa de processos no sistema. Por padrão, principal mostra processos classificados pelo consumo de CPU, o que é útil para outros tipos de ajuste de desempenho, mas não é a melhor maneira de capturar hogs de memória. Observe que principal lhe fornece um resumo da utilização da memória. Por exemplo, em um PS3 com X em execução, mas vários serviços desligados, eu obtive esta linha:

                
Mem:    219192k total,  213692k utilizada,     5500k livre,   7232k buffers
Swap:  4192956k total,       0k utilizada,  4192956k livre,  89468k armazenado em cache
 

Torne visível principal (simplesmente execute principal em um shell) e, em seguida, pressione O (que é um O maiúsculo, como em "classificar por") e, em seguida pressione q, e, em seguida, pressione Retornar. Nesse caso, q significa "tamanho residente" e lhe informa quanta memória real o processo está utilizando. Uma outra opção provável seria "tamanho virtual" (opção o).

Você deve agora ver uma lista de processos, classificada pela utilização da memória física real. Aqui está uma lista parcial, novamente a partir de uma máquina de teste:

                
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3259 root      20   0 65424  36m 4996 S    2 17.2   0:01.39 Xorg
 3422 seebs     20   0 92900  24m  20m S    0 11.6   0:01.22 nautilus
 3439 seebs     20   0 58600  24m  22m S    0 11.5   0:00.36 nm-applet
 3473 seebs     20   0 56620  24m  14m S    0 11.4   0:01.22 /usr/bin/sealer
 3420 seebs     20   0 50248  21m  18m S    0 10.2   0:01.90 gnome-panel
 3476 seebs     20   0 48988  14m  10m S    1  6.9   0:00.64 gnome-terminal
 3445 seebs     20   0 33104  14m 9464 S    0  6.7   0:00.40 puplet
 3453 seebs     20   0 45764  13m  12m S    0  6.4   0:00.22 gnome-power-man
 3414 seebs     20   0 41920 9696 8052 S    0  4.4   0:00.29 gnome-settings-
 3418 seebs     20   0 22200 8996 7316 S    0  4.1   0:00.33 metacity
 3297 seebs     20   0 40544 8384 7088 S    0  3.8   0:00.32 gnome-session
 3432 seebs     20   0 20076 6120 5244 S    0  2.8   0:00.10 bluetooth-apple
 3444 seebs     20   0 14692 6060 3532 S    0  2.8   0:00.24 python
 

Os 10 maiores consumidores de memória, aproximadamente, são todos relacionados com X. Este é o motivo pelo qual, se você realmente deseja liberar memória, uma de suas primeiras opções pode ser encerrar o X. Observando quantos desses aplicativos são específicos de GNOME, é possível ser seduzido a tentar KDE, mas eu receio que isso não o leve a nenhum lugar. KDE possui uma área de cobertura de memória comparável no PS3.

De fato, se você realmente precisar de X, sua melhor opção é não utilizar os ambientes de sessão X oferecidos pela janela de login do X; em vez disso, efetue login no console e inicie X com um gerente de janelas menor e menos programas adicionais. Mas como fazer isso? Sua primeira etapa será sair de principal e obter seu prompt de volta—simplesmente pressione q.

Voltar para parte superior

Fazendo Uso de Níveis de Execução

Níveis de Execução são um recurso que muitos usuários Linux nunca têm motivo para aprender a respeito. Eles são basicamente herdados do System V UNIX®, embora haja algumas diferenças, é claro. Um nível de execução é um conjunto definido de serviços do sistema que são executados juntos. Por razões históricas, o ambiente Linux de desktop usual, com um programa gráfico de login que efetua spawn do Gnome ou KDE, é chamado de nível de execução 5. Uma estação de trabalho convencional independente do X seria executada frequentemente no nível de execução 2. Em teoria, é possível se dar bem apenas alterando o nível de execução do sistema diretamente com o comando init , localizado em /sbin. Por exemplo, executar (como root) /sbin/init 2 instrui o sistema para mudar para o nível de execução 2. (Geralmente isso é feito parando qualquer serviço não utilizado no nível de execução 2 e, então, iniciando qualquer serviço que for utilizado no nível de execução 2.)

O nível de execução padrão é configurado por uma linha no arquivo /etc/inittab, que é semelhante a isso:

                
		 id:5:initdefault:
      

O formato da linha é histórico e tudo o que você realmente precisa saber para alterá-lo efetivamente é que pode alterar o 5 para um 2 ou um 3. Então, da próxima vez em que o sistema é inicializado, ele irá surgir em um prompt de login de console de texto em vez de iniciar o X.

O simples fato é, o console de texto é uma opção bem melhor para um sistema de desenvolvimento com memória limitada do que o ambiente X de capacidade máxima. Esse é um bom momento para executar alguma procura para ver do que podemos nos livrar. Altere o valor initdefault em seu /etc/inittab para 3 e reinicialize. (É possível, na verdade, utilizar o comando init para transição, mas há casos periféricos onde isso não funciona.) Você irá notar imediatamente como o sistema surge muito mais rapidamente. Imediatamente após efetuar login, execute principal novamente. Os resultados irão variar, mas é possível ver que a memória está, talvez, metade cheia, em vez de quase completamente vazia. Progresso!

Isso ainda É Bastante Memória

Embora seja certamente bom ter uma centena de megabytes livres, o sistema poderia, talvez, ser um pouco mais enxuto. Uma outra execução através de principal revela mais alguns hogs de memória:

                
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2204 root      39  19 30056  12m 5632 S    0  5.7   0:00.70 yum-updatesd
 1825 root      20   0 19220 5052  972 S    0  2.3   0:00.00 python
 2238 haldaemo  20   0  6648 2728 2180 S    0  1.2   0:00.27 hald
 1909 root      20   0 13480 2236 1564 S    0  1.0   0:00.02 cupsd
 2015 root      20   0 12352 1976 1272 S    0  0.9   0:00.02 console-kit-dae
 1958 root      20   0 12132 1796  748 S    0  0.8   0:00.01 sendmail
 2301 root      20   0  5548 1792 1484 S    0  0.8   0:00.02 login
 2141 xfs       20   0  5388 1776  884 S    0  0.8   0:00.05 xfs
 2425 seebs     20   0  5392 1732 1480 S    0  0.8   0:00.08 bash
 2371 seebs     20   0  5392 1728 1480 S    0  0.8   0:00.08 bash
 1966 smmsp     20   0 10356 1576  696 S    0  0.7   0:00.00 sendmail
 2221 avahi     20   0  3772 1520 1344 S    0  0.7   0:00.07 avahi-daemon
 1751 root      20   0 11332 1348  588 S    0  0.6   0:00.43 pcscd
 1796 root      20   0 29652 1304 1032 S    0  0.6   0:00.02 automount
 

De longe, o programa maior é yum-updatesd, aparentemente um daemon relacionado ao atualizador yum do sistema. (Na era ponto com, esse tipo de insight profundo poderia ter relocalizado você em qualquer lugar no país onde quisesse ir.) Felizmente, esse também é um programa que podemos facilmente ficar sem; é possível executar yum manualmente quando desejar.

Editando Níveis de Execução

Infelizmente, não existe um nível de execução específico para "nível de execução 3, somente sem yum-updatesd". Isso significa que é hora de iniciar manualmente a remoção de serviços. Há duas maneiras de fazer isso. Cada nível de execução é definido por um diretório correspondente em /etc/rc.d, denominado rcN.d; por exemplo, o nível de execução 3 é definido pelos arquivos em /etc/rc.d/rc3.d. (Também há symlinks para esses diretórios em /etc, em um sistema Fedora 7, mas é um bom hábito utilizar o caminho completo.)

Cada um desses diretórios contém uma série de arquivos, com nomes levemente crípticos como "K74nscd" ou "S88nasd." A convenção de nomenclatura é simples: nomes que iniciam com um K são serviços a serem interrompidos ao entrar nesse nível de execução (aparentemente a partir de um nível de execução numerado mais alto, que podem estar utilizando-os) e nomes que iniciam com um S são serviços a serem iniciados ao entrar nesse nível de execução. Os números de dois dígitos são utilizados para classificar serviços; S13rpcbind é iniciado antes de S14nfslock, que por sua vez é iniciado antes de S25netfs. Simples e efetivo.

Na verdade, geralmente, esses não são arquivos, mas symlinks para scripts armazenados em /etc/rc.d/init.d. Normalmente, existe um script único que pode iniciar ou parar um determinado serviço e, em seguida, links para ele são feitos de modo apropriado. Quando init altera níveis, ele chama os scripts com argumentos "iniciar" ou "parar", como indicado.

Se você estiver pensando em aprofundar-se, pronto para agir, pode simplesmente remover links ao S ou K indesejados a partir de um diretório de nível de execução. De forma semelhante, é possível incluir novos links. Uma outra opção é utilizar o utilitário chkconfig ; este é um utilitário muito flexível e eficaz que pode manter esses symlinks para você. Uma advertência: se você remover algo crucial, pode ter que utilizar um CD de recuperação de algum tipo (como o disco de instalação do Fedora; consulte Recursos) para obter sua inicialização do sistema de forma limpa novamente. Assegure-se de entender o que as coisas são e o que depende delas, antes de removê-las!

Como um exemplo, se você desejasse remover o programa yum-updatesd do nível de execução 2, poderia simplesmente remover o link /etc/rc.d/rc2.d/S97yum-updatesd. Para removê-lo do nível de execução 2 com chkconfig, o comando seria /sbin/chkconfig yum-updatesd off.

Capturando Mais Espaço

Com o chkconfig e principal, é possível capturar um número justo de usuários de espaço grande, compreender o que eles fornecem e removê-los se não precisar deles. Mas, e o processo do Python? Não há nenhum serviço do Python. O comando ps revela mais:

                

	 $ ps ax | grep python
	  1825 ?        S      0:00 python ./hpssd.py

Um grep rápido entre os scripts de inicialização revela que isso é parte do serviço hplip, que fornece "Imagem e Impressão do HP Linux." Isso pode ser utilizado com algumas impressoras e scanners HP, mas, por outro lado, é desnecessário. Portanto, se você não desligou isso ainda, faça-o agora.

Em um sistema de desenvolvimento dedicado bem típico, o total final era de 49.896 KB utilizados, abaixo de um início de 213.692 KB. A memória livre foi de 5.500 KB para 169.296 KB—um aperfeiçoamento notável em espaço para executar o compilador. A diferença que isso faz irá variar dependendo de sua carga de trabalho; muitos dos daemons de plano de fundo, uma vez trocados, permanecerão trocados e deixam seu sistema quase tão responsivo quanto seria sem eles. Durante um longo período de tempo, entretanto, mesmo uma diferença bastante pequena em tempos de compilação faz sentido.

Voltar para parte superior

Próximo: Obtendo um Ambiente X Utilizável

Como você vê, se estiver disposto a sacrificar uma série de recursos desnecessários ou ociosos, pode recuperar uma grande quantidade de memória do sistema, ficando com muita memória para executar e iniciar o código de desenvolvimento. No entanto, muitos usuários acharão a perda completa do X um preço muito alto a pagar. A Parte 3 nessa série examina o que é possível fazer para obter o ambiente X para executar trabalho gráfico simples, sem perder a capacidade de executar o compilador.

Recursos

Aprender

• Consulte todas as partes na série Desenvolvimento de Linux no PlayStation 3 , .
  
  
• "Programando Aplicativos de Alto Desempenho no Processador Cell BE, Parte 1: Uma Introdução ao Linux no PLAYSTATION 3" (developerWorks, janeiro de 2007) e "PS3 fab-para-lab, Parte 1: Construção do Equipamento de Laboratório Linux a partir de um Sony PLAYSTATION 3" (developerWorks, maio de 2007) são os primeiros artigos em outra série do developerWorks sobre a execução do Linux no PS3.
  
  
• A macro Cell Broadband Engine Resource Center é o recurso definitivo para todas as coisas de Cell/B.E.
  
  
• Saiba mais sobre principal, ps e outros utilitários UNIX excelentes a partir da wikipedia. Para chkconfig, consulte man chkconfig.
  
  
• A Wikipedia também tem a troca detalhada.
  
  
• Seu CD de instalação do Fedora possui um modo de resgate que pode ser capaz de ajudá-lo a sair da obstrução.
  
  
• Na zona Linux do developerWorks, encontre mais recursos para desenvolvedores Linux e varra nossos artigos e tutoriais mais conhecidos.
  
  
• Consulte todas as dicas de Linux e tutoriais de Linux no developerWorks.
  
  
• Fique atualizado com eventos técnicos e Webcasts do developerWorks.
  
  

Obter produtos e tecnologias

• Solicite o SEK para Linux, um conjunto de dois DVDs que contém o software de período experimental IBM mais recente para Linux a partir do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  
• Com o Software de período experimental IBM, disponível para download diretamente do developerWorks, construa seu próximo projeto de desenvolvimento em Linux.
  
  

Discutir

• Envolva-se com a comunidade do developerWorks através de blogs, fóruns, podcasts e tópicos da comunidade em nossos novos espaços do developerWorks.
  
  

Sobre o autor

Peter Seebach coleciona dispositivos pequenos que executam em Linux. Ele está cansado de ouvir piadas sobre criar um cluster Beowulf a partir deles.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Reduzindo a Utilização da Memória
• Fazendo Uso de Níveis de Execução
• Isso ainda É Bastante Memória
• Próximo: Obtendo um Ambiente X Utilizável
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais