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:
Outro dia, durante o trabalho, fui perguntado sobre onde fazer cursos para certificação Linux LPI. Antes de dar recomendações, fiz a pergunta básica: qual o seu propósito com essa certificação?
Muitas pessoas buscam a certificação por vários motivos: status, melhoria salarial ou carreira, ou conhecimento. Mas será que é algo que vale a pena? Como resposta, ou melhor, opinião minha digo que depende da situação e do objetivo.
Certificação é uma forma mais rápida de adquirir um conhecimento e comprovar tal aprendizado.
Nada mais que isso. Cursos de certificação levam em média 6 meses (em geral menos), mas não são nada mais que isso. São cursos, e cursos não substituem uma boa faculdade. Alguns cursos ainda o preparam somente pra passar na prova de certificação. Caso ainda não seja formado ou seja um profissional autodidata, e queira comprovar no seu currículo que detém mesmo um certo conhecimento, então eu recomendo uma certificação na sua área de atuação. Muitas certificações não exigem uma quantidade mínima de aulas, mas apenas agendamento, pagamento e realização da prova (não necessariamente nessa ordem). Se aprovado, consegue-se a certificação.
Mas caso tenha uma faculdade, tentar engrossar o currículo com certificação pode significar que seu curso não prestou a que devia: ensinar. É bastante arriscado fazer isso. Não existe no mundo certificação que seja melhor que um curso de no mínimo de 2 anos (em relação às boas faculdades). Claro que é preciso "saber aprender" durante a faculdade, do contrário realmente foi um tempo jogado fora e nem mesmo a certificação vai ajudar.
Em termos de carreira, se deseja melhorar seu salário ou crescer na empresa, é melhor negociar com seu gerente antes, pois pode ser que a empresa precisa desse conhecimento mas... não tanto a ponto de pagar algo a mais por seu esforço. Então realmente converse com seu gerente sobre sua carreira, o que deseja, sobre a certificação, e tenha a certeza se vale a pena investir nele ou não.
Se o desejo for por um melhor emprego, certificação não é o que ajuda. O importante é o conhecimento. Mentir no currículo não pega bem e é descoberto logo, pela falta de conhecimento. Certificação não é diferente. De todas as entrevistas de emprego em que eu estava como empregador, em nenhum caso a certificação fez diferença já que eu perguntava aos candidatos sobre suas competências e pedia exemplos de como a usaram. Em alguns casos eu ainda fazia exemplos de problemas e perguntava como resolveriam.
Mas se o caso de busca for por conhecimento, eu acho que cursos gratuitos na Internet podem ajudar com isso sem necessariamente precisar da certificação. Existem os mais variados materiais disponíveis e o interessante seria aplicar seus conhecimentos, ao longo do aprendizado, em algum projeto que esteja trabalhando. Isso ajuda a fixar o conteúdo.
No exemplo do LPI, eu sugeri que buscassem as apostilas do Guia Foca Linux, que é um curso completo de Linux desenvolvido com várias contribuições e ao longo de vários anos. Eu mesmo administro os treinamentos internos da empresa baseados nessa apostilas. Sempre que me pedem referência sobre livros ou qualquer coisa de Linux, eu sempre recomendo o Guia Foca Linux.
Então quando pensar em certificação, pense antes qual o seu real objetivo com isso.
Após aproximandamente passado 1 mês do lançamento da pesquisa do MBA FGV, sobre perfil de consumidores de dispositivos móveis em frente da TV, finalmente é possível sumarizar e apresentar os resultados.
Antes de mais nada agradeço aos que participaram.
A pesquisa foi anônima, mas pelo perfil apresentado, é possível ver que a rede de contato não fugiu muito do perfil de T.I., pois a maioria é composta de homens entre 25 e 40 anos e atuantes na área de exatas. Tentei fazer o mais abrangente possível, mas... é impossível fugir do teorema dos grafos...
Vamos às respostas então.
Os resultados foram muito próximos daqueles já informados por pesquisas como IBOPE e até mesmo a ConsumerLabs da Ericsson.
A idéia da pesquisa era saber sobre o mercado de aplicativos second screen, onde os dispositivos móveis como smartphones e tablets tornam-se parte da programação de TV. A forma mais fácil de visualizar isso seria através do aplicativo participando online durante o debate político na TV. Imagine poder verificar online quem está indo melhor num debate, ou pior. Pode não ser significativo em termos de análise eleitoral, mas é no mínimo diverto.
Agora resta saber se algum dia conseguirei realmente montar uma empresa startup com isso :-)
No dia 13 de janeiro de 2012 eu resolvi experimentar um desses roteadores wireless que são vendidos no Dealextreme. O que mais me seduziu pra fazer isso foram dois fatores: preço (sempre barato) em torno de 70 reais e dizer que rodava o DD-WRT.
Então nessa data comprei o roteador WR3G01.
O roteador chegou exatamente dia 27 de junho do mesmo ano, praticamente 6 meses depois da compra. A entrega no Brasil foi rápida, quem atrasou tudo foi a receita federal. Mas não foi taxado já que a compra foi abaixo de 50 dólares.
Ao abrir o equipamento, foi uma grande decepção. Não pelo hardware, mas pelo software. É uma horrível interface escrita em pseudo-inglês com chinês.
E nada de carregar o DD-WRT ou Open-WRT facilmente, as versões alternativas de firmware de roteadores wireless que rodam puramente Linux. Pra conseguir tal façanha é necessário soldar os pinos de E/S serial na placa, conectar com um módulo de porta serial RS-232, e então habilitar um carregamento de firmware por tftp.
O Dealextreme já vende um kit para fazer esse tipo de aventura, como o "RS232 Serial Port To TTL Converter Module w/ Transmitting and Receiving Indicator - Blue", mas isso está longe do que sonhei, que era simplesmente realizar um upgrade via web GUI e carregar um firmware alternativo, como é feito pelo TP-Link 1043. Infelizmente na época da compra faltavam informações sobre isso.
Não existe interface de upgrade automática e somente uma informação de versão, que é 1.0.5.3. Conectando via telnet, é possível verificar a informação de revisão também, que dá mais algumas pistas sobre o equipamento.
Sem nenhuma outra informação. Buscando na Internet pelo número serial, modelo e versão de firmware, é possível encontrar referências como sendo um Widemac. O site é tão informativo quanto horário político.
O roteador tem acesso via telnet, mas as opções de comandos são extremamente limitadas:
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
Router login: admin
Password:
Welcome to Bococom Router Series
For detailed information, please check:
www.bococom.com
BusyBox v1.12.1 (2010-11-26 17:38:48 CST) built-in shell (msh)
Enter 'help' for a list of built-in commands.
# sh
Unknow command
# ls
Unknow command
# help
? ->Display help information.
help ->Display help information, same as '?' command.
clear ->Clear various talbes, type clear for help.
ping ->ping HOST, type ping for help.
traceroute ->route trace, type traceroute for help.
ipmac ->ip mac bind settings.
quit ->Close terminal session.
show ->Display various talbes information, type show for help.
restart_httpd ->Restart web server.
restore_defaults ->Restore the config to the default factory value.
run_ated ->Run ated for MS product.
O roteador funcionou pro básico que nada mais é que uma conexão WAN via DHCP com o Net Virtua, wireless interno com WPA2 e controle de acesso. Mas falta coisas mais avançadas como suporte à IPv6.
Tem também uma porta USB que eu esperava conseguir usar no Linux como NAS, conectando um HD externo, mas não deu certo com o firmware que veio por padrão.
Reza a lenda que vem com suporte para modems 3G nessa porta USB, mas não me dei o trabalho de testar.
Para quem tem filho adolescente, sabe que as traquitanas tecnológicas tornaram a vida um inferno quando o assunto é estudar. Controlar o acesso ao computador é fácil, criando regras de bloqueio após certos horários estabelecidos, ou mesmo permissão e filtragem de acessos à sites baseados em URL e squid.
Mas com a chegadas dos dispositivos móveis, como telefones Android e tablets, a coisa não ficou tão fácil.
Restou a opção de bloquear o acesso pelo MAC address nos horários de estudo (que em geral são transformados em horários de soneca durante a tarde ou televisão).
Então fiz um pequeno script em python que bloqueia os MACs já cadastrados, tanto do tablet quanto do smartphone, e libera nos horários em que o computador desktop também está liberado. Com certeza isso não resolve o problema, mas com adolescentes, em geral, quase nada resolve.
O programa funciona com meu roteador wifi, um WR3G01, que comprei no Dealextreme (mais informações aqui). É um roteador wireless que se diz compatível com DD-WRT, mas que pra isso exige soldar os contatos da conexão serial na placa e carregar o firmware por tftp (era mais fácil dizer que não suporta então).
O programa segue:
#! /usr/bin/python
import re, urllib2
from base64 import encodestring
from sys import argv
MACS = [ "94:63:AA:BB:CC:DD", "74:E1:AA:BB:CC:DD" ]
login = "admin"
password = "admin"
server = "192.168.0.1"
port = 80
URI = "/apply.cgi"
TAG =""
for mac in MACS:
mac = re.sub(":",'%3A', mac)
TAG += mac + '%3B'
def Usage():
print "Use: %s {block|allow}" % argv[0]
exit(1)
if (len(argv) < 2):
Usage()
elif (not re.search("allow|block",argv[1])):
Usage()
msg_body = "submit_button=wlan_access&" + \
"change_action=&" + \
"action=Apply&" + \
"AccessControlList0=" + TAG + "&"
if (argv[1] == "allow"):
msg_body += "AccessPolicy0=0&"
elif (argv[1] == "block"):
msg_body += "AccessPolicy0=2&"
msg_body += "mac=&mac=&mac=&mac=&mac=&mac=&"
if (argv[1] == "allow"):
msg_body += "selectMAC=1"
elif (argv[1] == "block"):
msg_body += " selectMAC=3"
http_pass = encodestring(login + ":" + password)
url = "http://" + server + ":" + str(port) + URI
my_headers = {
'User-Agent' : 'Python Client/1.0/1.0',
'Authorization' : 'Basic ' + http_pass,
'Content-Type' : 'application/x-www-form-urlencoded'
}
req = urllib2.Request(
url,
headers = my_headers,
data = msg_body
)
print "Sending: %s" % argv[1]
resp = urllib2.urlopen(req)
Desde a mudança pra Joomla 2.5 que meu site estava limpo 
de propaganda do Google AdSense. Apesar da interface mais limpa, isso afeta a parte de rentabilidade do site que, diga-se de passagem, não é lá essas coisas. Mas se um dia eu puder viver de blog como o vídeo do "vida de blogueiro", não vou achar ruim. Então é necessário ao menos tentar.
Então eu estava procurando por algum plugin ou módulo do Joomla para conseguir inserir essa propaganda quando encontrei o artigo:
Adicionar o AdSense ao seu Joomla! 2.5 do Site
Simplesmente fantástico! Ensina com um passo-a-passo como criar um módulo no Joomla 2.5 para adicionar o AdSense. É fácil, é rápido, e sem ficar dependendo de módulos ou plugins de terceiros.
Um amigo de trabalho, o @dancriv, publicou uma foto muito legal em seu Instagram nesse dia dos pais.
Essa foto me fez pensar que sou um pai desse tipo.
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.
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:
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.
Fazia anos que não participava de um FISL, Fórum Internacional de Software Livre. Acho que uns 9 ou 10 anos. Esse ano consegui me programar melhor e participar do evento, ficando junto com o pessoal da caravana do Espírito Santo.
Diferente dos FISLs do passado, o desse ano foi totalmente dominado pelo Ubuntu. De laptops nos estandes a desktops pra apresentação. Há quem possa reclamar da "ubuntização" do evento, mas sob meu ponto de vista, isso é ótimo. O último FISL que fui, por volta de uma década atrás, era dominada pelo Windows. Faziamos movimentos de "libertação dos desktops" e "install fests" para migrar tais computadores, com Debian. Era uma batalha. Vejo hoje que realmente vencemos e isso é lindo de se ver. Mas uma coisa realmente mudou em relação ao uso dos computadores: a maioria era usado somente para acessar o FaceBook. Isso foi colocado em algumas palestras, que pra maioria das pessoas a Internet estava se tornando o FaceBook. Esse foi o lado triste do evento.
Outra mudança sensível foi em relação à qualidade das palestras. No passado, o FISL era entupido de políticos mostrando cases de "adoção de software livre na administração pública", que nada mais eram que uma mostra ruim de como foram adotados aplicativos de office através do OpenOffice. Beiravam ao ridículo. Felizmente não vi nada disso esse ano, talvez pela oferta abundante de palestras de alto nível.
E como sempre o contato com o pessoal que só conhecemos remotamente. Foi muito divertido e enriquecedor dividir um quarto de hostel, o hostel Casa Azul, com o pessoal do Espírito Santo, assim como re-encontrar velhos amigos no evento (e notar que não sou o único ficando velho). Isso fez valer toda a viagem e o cansaço de 4 dias ininterruptos de palestras, além de ajudar a ficar acordado durante todo esse tempo.
Essas são as fotos que fiz durante o evento, publicada num velho companheiro de fotos e eventos, o Flickr. Mas também publiquei no FaceBook :-p
UPDATE: 2021-12-23 atualizado pra usar o formato exportado do Flickr em javascript ao invés do formato em flash.
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.
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?
Aos poucos estou arrumando o site. Muitos dos plugins antigos pararam de funcionar, como as tags "{mosimage}" e "{denvideo}", sem muito jeito de arrumar em curto prazo. São os efeitos colaterais do upgrade que infelizmente não dava pra adiar mais.
Perdi a parte de estatísticas uma vez que o Joomlastats só suporta a antiga versão 1.5. Mais um que entra em "perdas e danos". Ainda não achei um substituto a altura, mas vou continuar procurando...
Depois de empurrar esse upgrade por um longo tempo (acho que mais de 6 meses), finalmente tomei coragem e aproveitei o feriado de corpus christi chuvoso que São Pedro, esse fanfarrão, preparou para todos nós e mandei ver.
Como não tenho acesso shell ao provedor de hospedagem, mas somente interface web via plesk, tive de fazer um dump do BD e cópia do conteúdo para o desktop que tenho. Feito o upgrade lá, copiar tudo novamente de volta pro site. Trabalho dobrado e cuidado pra não apagar o que não devia. Mas deu certo (até agora parece tudo ok).
Infelizmente nem tudo é alegria. Preciso ainda ver se todos os artigos mais antigos estão corretos e se a indexação do site continua funcionando como anteriormente, principalmente pras buscas do google. Fora que formatação foi perdida, estatísticas, plugins, etc. Dá uma limpada no ambiente, mas preciso refazer o caminho das pedras do site.
Então, mãos à obra!
Page 20 of 33
