Como contornar os badblocks do seu HD!!!

Antes de fazer qualquer coisa garanta um backup da partição que você vai realizar os procedimentos de manutenção!

Primeiramente desmonte a partição onde você precisa mapear os badblocks.

No meu caso era a partição /dev/sdb1 e ela estava montada na pasta /dados

# umount /dados

Em seguida, efetue o comando e2fsck -c

# e2fsck -c /dev/sdb1
ou
# e2fsck -cc /dev/sdb1

O parâmetro -c usa o programa badblocks para realizar um escaneamento de leitura no dispositivo para encontrar os bad blocks. Se houver bad blocks, eles serão adicionados ao bad block inode para prevenir que eles sejam alocados a um arquivo ou diretório.

Quando esse parâmetro é usado de forma duplicada (-cc), o escaneamento dos badblocks serão realizados usando um teste de leitura e escrita não destrutivos.



Fonte: http://linux.die.net/man/8/e2fsck

Login via ssh demorando muito para conectar

Se o login via ssh está tomando muito tempo.

Você efetua o comando e leva um bom tempo até que ele solicite a senha...

Isso pode ser um problema de DNS.
É necessário configurar o aruqivo /etc/hosts adicionado as seguinte linhas
127.0.0.1 localhost, nomedamaquin
192.168.0.1 nomedamaquina


Onde o ip 192.168.0.1 é um ip que a máquina tem para se conectar a rede.

Outra alteração que deve ser feita para sanar o problema é editar o arquivo sshd_config do serivdor.

vi /etc/ssh/sshd_config

Mudar a linha de
UseDNS yes
para
UseDNS no

Muitas vezes essa linha está comentada, então descomente e sete o UseDNS para no .

Reinicie o serviço de ssh
no SuSe:
rcsshd restart
no CentOS/RedHat
service sshd restart

Agora teste novamente!
É pra estar uma bala!

Correção do Dicas de Tunning

A melhor consulta para descobrir as piores tabelas é essa!

SELECT relname AS table_name,
seq_scan, seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE (seq_tup_read + idx_tup_fetch) > 0
ORDER BY seq_tup_read desc, seq_scan desc;

Alterei apenas a ordem do order by
DE
seq_scan desc, seq_tup_read desc;
PARA
seq_tup_read desc, seq_scan desc;

Na consulta do post passado eu tinha ordenador primeiro pelo número de table scans e depois pelo número de tuplas lidas por meio de table scans.

A melhor forma é justamente o contrário, pois teremos de cara as piores tabelas do nosso banco de dados que serão aquelas tabelas gigantes que tem muitas tuplas lidas por table scan.

Configurar o YUM para usar um proxy no CentOS

vi /etc/yum.conf

Adicione as seguintes linhas

# The proxy server - proxy server:port number
proxy=http:/ip_do_servidor:porta
# The account details for yum connections
proxy_username=usuario
proxy_password=senha

Dicas de Tunning no Postgres

--Verificar quais tabelas possuem mais table scans/sequential scans (coluna seq_scan)

SELECT relname AS table_name,
seq_scan, seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE (seq_tup_read + idx_tup_fetch) > 0
ORDER BY seq_scan desc, seq_tup_read desc;


Dentre as tabelas com mais table scans verifique as que maiores em quantidades de linhas, pois muitas vezes o tablescan não é tão pesado se a tabela possuir poucos registros. Uma tabela com 10 linhas não causa tanto problema se forem realizados muitos table scans, porém uma tabela com 2milhoões de linhas já causa um estrago grande!

Vendo isso encontrei uma tabela de log que estava entre as dez com maior número de consulta que efetuaram table scans. Busquei no sistema quais select que estavam causando esse problema, criei um índica para a coluna id_usuario e daí a consulta que demorava 2 segundos para executar passou para 12ms!


Para analisar a atividade no banco no momento da consulta.
SELECT *
FROM pg_catalog.pg_stat_activity 

Se houver uma consulta demorada, você vai ver ela aparecer com frequência nessa consulta.

Copie a consulta que aparecerá na coluna current_query e verifique quanto tempo demora para executá-la. Analise as cláusulas WHERE e crie índices para as principais colunas.