memcontrold

Categoria: Linux Publicado: Quarta, 19 Dezembro 2012 Escrito por Helio Loureiro

O calcanhar de Aquiles do Linux sempre foi o gerenciamento de memória.  Por mais memória que se tenha disponível, ele vorazmente sempre quer mais.  E nunca libera a memória livre.

E meus parcos 6 GB de memória do laptop tem sentido isso nesses últimos dias de 2012.   E verificável pelos gráficos do Munin, que mostra o pedido de 10 GB de memória pra usar.  Isso me faz pensar que talvez os Maias esteja certos.

 

 

Eu ainda não descobri qual programa (ou processo) está causando isso, e o kernel Linux não cuida de matar o processo comilão.

Então criei um pequeno daemon, em perl, para ficar lendo o /proc e matando os processos que mais consomem memória se a carga do sistema aumentar muito (atualmente marquei para load average maior de 10).

 

#! /usr/bin/perl

use POSIX;

$PROC = "/proc";
$MAXLOAD = 10;  #loadaverage
$SLEEPTIME = 1; #seconds

if (getuid() != 0) {
  print "Only root can run this program.\n";
  exit(1);
}

if (! -d $PROC) {
  print "Not possible to run.  System not running with $PROC directory\n";
  exit(1);
}

sub GetMem() {
  $pid_dir = $_[0];
  my $dir = $PROC."/".$pid_dir."/statm";
  open(MEM, $dir) or die "Error:$dir $!\n";
  @params = split(/ /, );
  close MEM;
  $memory = $params[0];

  return $memory;
}

sub GetPID() {
  my %MEM;
  opendir(PROC,$PROC) or die "Not possible to run.  System not running with $PROC directory\n";

  foreach $dir (readdir PROC) {
	# Just read higher processes
	# avoid init (1) or non-pid
	next if ($dir !~ m/^\d\d\d+/);
	$mem = &GetMem($dir);
	if ($mem) {
	  $MEM{$dir} = $mem;
	}
	
  }
  closedir PROC;

  return %MEM;
}

sub GetLoad() {
  open(LOAD,$PROC."/loadavg") or die "Impossible to detect load average by $PROC:$!\n";
  my $load = ;
  close LOAD;
  my @params = split(/ /, $load);

  return $params[0];
}

sub GetCommand() {
  my $pid = $_[0];
  open(CMD, $PROC."/".$pid."/cmdline") or die "Impossible to read the source command: $!\n";
  my $cmd = ;
  close CMD;

  return $cmd;
}

sub DaemonizeMe() {
  print "Starting to memory control daemon\n";
  POSIX::setsid or die "setsid: $!";
  my $pid = fork ();
  if ($pid < 0) {
	die "fork: $!";
  } elsif ($pid) {
	exit 0;
  }
  chdir "/";
  umask 0;
  foreach (0 .. (POSIX::sysconf (&POSIX::_SC_OPEN_MAX) || 1024)) { 
	POSIX::close $_; 
  }
  open (STDIN, "/dev/null");
  #open (STDERR, ">&STDOUT");
}

&DaemonizeMe();
my $mypid = getpid();
my %DEATHCOUNTER;

while (! $SIG{TERM}) {
  
  sleep($SLEEPTIME);
  my $load = &GetLoad();
  next if ($load < $MAXLOAD);
  my %MEM;
  %MEM = &GetPID();

  $higher_m = 0;
  $higher_pid = 0;

  foreach $k (sort keys %MEM) {
	next if ($k eq $mypid);
	$mem = $MEM{$k};
	if ($mem > $higher_m) {
	  $higher_m = $mem;
	  $higher_pid = $k;
	  $DEATHCOUNTER{$higher_pid}++;
	}
  }

  if ($DEATHCOUNTER{$higher_pid} >= 5) {
	print "Killing due higher memory usage: ".&GetCommand($higher_pid)." (".$higher_pid.") [".$higher_m." Bytes]\n";
	%DEATHCOUNTER;
  }
}

print "Exiting...";
exit(0);

Os Maias podiam até estar certos, mas isso não significa que precisamos ficar sentados olhando.

Compilando kernel com parâmetro -j

Categoria: Linux Publicado: Segunda, 22 Outubro 2012 Escrito por Helio Loureiro

Já faz anos que compilo meus kernels e sistemas com a utilização do parâmetro "-j 8" ou "-j 12".  Esse parâmetro, passado ao GCC, faz uso de multithreads em máquinas com mais de um processador ou processador multicore, como esse Intel Core i3 que tenho no laptop.

Mas sempre usei esse parâmetro quase que como dogma, sem muita certeza de sua eficiência.  Aliás, com uma pequena idéia de eficiência já que, sem o uso do mesmo, o tempo de compilação era mais demorado.  Mas tudo muito de "sentimento", sem nenhuma comprovação.

Então, num desses dias sem muita coisa pra fazer (pequena metira: estava lotado de coisas pra terminar, mas decidi fazer isso pra limpar um pouco a mente), resolvi verificar essa compilação com dados mais concretos e monitoração dos resultados.  Fiz o seguinte programa em python pra ficar compilando um kernel que já estava configurado e que eu tinha certeza que compilava sem problemas, com as threads indo de 1 a 20:

#! /usr/bin/python
# make clean; time make-kpkg -j 4 --initrd kernel_image
import os
import time

#print time.time()
OUTPUT = "/tmp/kernel_results.csv"

FD = open(OUTPUT, "w")

for TH in xrange(1,21):
        print "Threads:", TH
        print "\tlimpando..."
        os.system("make clean")
        t_0 = time.time()
        os.system("make-kpkg -j " + str(TH) + " --initrd kernel_image")
        t_1 = time.time()
        total_time = t_1 - t_0
        msg = "Threads: %d in %0.2f s" %(TH, total_time)
        print msg
        FD.write(str(TH) + "," + str(total_time) + "\n")
        FD.flush()

Então deixei o sistema rodando.  Eu costumo usar o "make-kpkg", do pacote kernel package, que já gera para mim o pacote DEB para instalação.

Ao final, os resultados foram os seguintes:

A troca de contextos de processos realmente aumentou com o aumento de threads.  Por isso o sistema fica tão lento.

O sistema ficou com uso de CPU intenso, mas sem crescimento gradual (isso eu já achei estranho).

As interrupções de mudança de contexto também ficaram iguais, onde eu esperava um valor em degraus.

Mas a carga do sistema, load average, aumentou realmente em degrau, acompanhando a quantidade definida no "-j".  Isso era esperado e é sempre notado, pois o computador fica super lento.

Porém o melhor ficou pro final: a análise do tempo pela quantidade de threads.

O tempo diminuiu conforme a quantidade de threads que aumenta até... 3???  O processador Intel Core i3 é um multicore de 4 cores, eu esperava ao menos um melhor desempenho até 4 threads, mas dá pra ver bem claro que o sistema estabiliza em 3.

Ou seja, usando "-j 8" ou "-j 12" só serve para aumentar a carga da CPU, aumentando as trocas de contextos, mas não significam nem melhora nem otimização da compilação.  Pelo contrário.  Então o melhor é saber o máximo que a CPU realmente aguenta antes de aplicar cegamente parâmetros para *melhorar* o desempenho do sistema.  E monitorar os resultados!

Atualização: Sun Feb  3 20:34:35 BRST 2013

Conforme pedido do Erick Tostes, @ericktostes no twitter, estou incluindo o meu /proc/cpuinfo.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
microcode       : 0x9
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dtherm tpr_shadow 
vnmi flexpriority ept vpid
bogomips        : 4255.62
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

O pf-kernel

Categoria: Linux Publicado: Segunda, 13 Agosto 2012 Escrito por Helio Loureiro

Já faz tempo que estou querendo escrever um pouco sobre o pf-kernel e acho que finalmente chegou esse momento.  Talvez a idéia dramática de fatalidade, derivado do fato de que estou assistindo o filme 2012, tenha me levado a escrever sobre isso logo.

Sempre existiram variações do kernel do Linux, desde seu surgimento.  As versões de Andrew Morton eram famosas por incluir algumas vantagens como melhor preempção e gerenciamento de memória se comparado com o kernel padrão, por exemplo.  Mas isso era no passado.  Nos tempos atuais de Linux, alguns kernels modificados para melhoria de resposta em tempo real são os mais famosos, justamente por existir dentro de distribuições como Debian e Ubuntu, bastando usar o gerenciador de pacotes para instalar e testar.  Nesse panorama, sem muito alarde, surgiu um novo fork do kernel Linux: o pf-kernel.

Site do pf-kernel

pf-kernel no GITHUB

Apesar da associação de pf-kernel com o packetfilter dos BSDs, na verdade o pf é uma referência ao apelido do autor, post-factum.  O pf-kernel é um kernel padrão Linux modificado da seguinte forma:

  1. [m] atualizações do kernel padrão
  2. [t] BLD: técnica de distribuição de carga pro kernel Linux
  3. [w] BFS: Brain Fuck Scheduler - escalonador de baixa latência
  4. [m] BFQ: Budget Fair Queue I/O scheduler - escalonador de E/S
  5. [m] TuxOnIce - sistema de hibernação
  6. [m] UKSM - suporte à deduplicação de dados

A maioria são patches para melhorar o tempo de resposta do sistema (preempção), mas não somente com alteração no escalonador, mas por melhorias inclusive nas respostas de I/O, além de TuxOnIce, uma forma nova hibernar o Linux, com várias vantagens em relação ao sistema padrão, como o retorno mais rápido.  Infelizmente no meu caso tive problemas do TuxOnIce com o meu filesystem, XFS.  Mas de resto, gostei de usar o pf-3.2, ficando com uptime além de 100 dias graças a ele. Eu não conhecia o pf-kernel, só tinha ouvido falar por cima, mas uma sugestão no twitter, do @cleitonflima, me fez experimentar e gostar muito dessa árvore de kernel.  Posteriormente encontrei um artigo sobre o mesmo:

Fazendo o pinguim voar: o pf-kernel

Apesar da riqueza de dados sobre pf-kernel nesse artigo, não há tanta informação assim sobre o mesmo.  Então não consegui confirmar o que o artigo diz sobre os patches, além das informações que cada patch já traz.  Aliás as melhorias, no meu processador Intel Core I3, só foram percebidas com carga alta, ou seja, load average acima de 4.  Abaixo disso, que é o normal do sistema, não percebi nenhum ganho.  Mas com o sistema sobrecarregado, consegui continuar ouvido música sem interrupções, o que não acontece com o kernel padrão.

E fui brindado com um kernel mais estável que o kernel padrão também.  Tive problemas com o kernel 3.2.0, e com o pf-kernel-3.2.5, mas a versão pf-kernel-3.2.7 funcionou muito bem (com exceção do problema do filesystem XFS).  Agora estou criando coragem pra compilar uma versão mais recente do pf-kernel, que suporte mais de 100 dias de uptime, mas não acho que terei problemas.

Pra quem tem uma máquina mais antiga, da geração Core Duo ou até anterior, é bem provável que os benefícios do pf-kernel sejam mais bem notados.  Para agraciados donos de CPUs mais modernas, como a última geração dos Core-i7, talvez nem seja perceptível, mas é sempre interessante testar as alternativa ao kernel padrão e saber que elas existem.

Um update sobre os 100 dias

Categoria: Linux Publicado: Quinta, 02 Agosto 2012 Escrito por Helio Loureiro

E minha alegria realmente chegou ao fim nos 110 dias de uptime.  Dessa vez o culpado foi o filesystem, XFS, que começou a cuspir vários erros como esses:

 
XFS (sda1): xlog_space_left: head behind tail
  tail_cycle = 252, tail_bytes = 8731136
  GH   cycle = 252, GH   bytes = 8731128
XFS (sda1): xlog_space_left: head behind tail
  tail_cycle = 252, tail_bytes = 8731136
  GH   cycle = 252, GH   bytes = 8731128
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8328704
  GH   cycle = 1212, GH   bytes = 8328696
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8328704
  GH   cycle = 1212, GH   bytes = 8328696
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8356864
  GH   cycle = 1212, GH   bytes = 8356856
XFS (sda8): xlog_space_left: head behind tail
  tail_cycle = 1212, tail_bytes = 8356864
  GH   cycle = 1212, GH   bytes = 8356856
XFS (dm-0): xlog_space_left: head behind tail
  tail_cycle = 350, tail_bytes = 158558208
  GH   cycle = 350, GH   bytes = 158558200
XFS (dm-0): xlog_space_left: head behind tail
  tail_cycle = 350, tail_bytes = 158558208
  GH   cycle = 350, GH   bytes = 158558200
XFS (sda1): xlog_space_left: head behind tail
  tail_cycle = 252, tail_bytes = 8787968
  GH   cycle = 252, GH   bytes = 8787960
 
Isso em todas as partições.  Tentei forçar um "init 1" pra single mode e "desmontar/montar" as partições, mas as mesmas não permitiam isso.  Como encontrei referências bem ruins sobre esse comportamente, dizendo que poderia levar à perda de dados, eu preferi fazer o reboot do sistema.
 
A lista da SGI, criadora do XFS, foi essencial pra decidir o que fazer.  Só espero que o problema não se repita nos meus próximos 100 dias de uptime.
 

A guerra dos 100 dias

Categoria: Linux Publicado: Sexta, 20 Julho 2012 Escrito por Helio Loureiro

11:55:20 up 100 days, 0 min, 43 users, load average: 1.22, 0.83, 0.84


Finalmente meu laptop, de uso diário e pessoal, quebrou a barreira dos 100 dias de uptime. E o que isso quer dizer?  Nada, e ao mesmo tempo, várias coisas. Mas significa que estou trabalhando sem interrupções por 100 dias.

Fazia tempo que eu não tinha um uptime maior que 30 dias, quanto mais de 100.  O problema não era específico, mas um conjunto deles.  O que mais afetava o tempo em que a máquina funcionava sem interrupções (leia-se travamentos) era o driver de vídeo Intel.  Invariavelmente o Xorg apresentava um crash por conta dos efeitos 3D do KDE com o plasma-desktop.  Tentei de tudo, inclusive desabilitar os efeitos e até mesmo parar de usar o KDE, mas o crash de xorg sempre me encontrava.

Contudo vários esforços ocorreram em várias frentes e paralelamente, como sempre acontece no mundo do software livre.  A equipe do Xorg melhorou o driver Intel, o KDE, com o lançamento do 4.7, criou uma forma de contornar esse crash, deixando o ambiente plasma muito mais estável e, por fim, a equipe de kernel trabalhou na melhoria do driver framebuffer e DRM pra Intel.

Esse conjunto de melhorias deram um resultado excelente, visível pelo tempo em que o laptop está funcionando sem parar.  E olhe que o uso é intenso.  Faço desde desenvolvimento de software até apresentações pra clientes, inclusive utilizando 2 monitores (em geral uma televisão).  Tive alguns problemas nesse percurso, como uma sobrecarga no xorg, que levou o KDE a cair, mas nada que um reinício do serviço gráfico não pudesse resolver, sem precisar rebootar o laptop.

Em geral tenho trabalhado de forma consistente, fechando e abrindo o laptop, sem reiniciar o trabalho que tinha parado anteriormente.  Isso garante um ganho de produtividade muito bom, pois já vejo em que ponto eu estava da última vez e continuo dali pra frente.  Nada de reabrir documentos e procurar onde foi a última linha editada, nada de reabrir ambientes de desenvolvimento, nada de reiniciar minhas conexões SSH pra máquinas em que trabalho via VPN, já que faço isso automaticamente via script, que só detectam a queda do link e reiniciam a conexão.  Fecho o laptop na sexta-feira e reabro na segunda, como se tivesse parado pra um café.

Então quando se vê um uptime alto, não estamos falando somente de tempo se desligar a máquina mas a produtividade que isso proporciona.  Claro que existe um lado egocêntrico de falar no tempo sem desligar ou sem reboot, que vem da cultura de sysadmin, onde o maior uptime significa (ou ao menos significava) um servidor bem ajustado e configurado, mas isso é quase insignificante em relação ao benefício do trabalho ininterrupto.

E você?  Já chegou aos 100 dias ou isso ainda é um fardo pra sua produtividade?