[FUG-BR] Problema com ZFS com grande quantidade de dados

Quinta Março 26 13:50:31 BRT 2009

Uma perguntinha bem básica você esta usando  ao FreeBSD 64bits certo EMT_64

tente  isso

/boot/loader.conf
vm.kmem_size_max="1024M"
vm.kmem_size="1024M"
vfs.zfs.arc_max="100M"

no /etc/sysctl.conf
kern.maxvnodes=400000

Para um sistema com 2Gb de ram

de uma lida no
http://wiki.freebsd.org/ZFS

muito recomendado você ler isso aqui também
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide


2009/3/26 Rafael Henrique Faria <rafaelhfaria em cenadigital.com.br>:
> Boa tarde pessoal.
> Eu estou utilizando um FreeBSD 7.1 com GEOM e ZFS para montar um storage.
> Este storage, está parcialmente em produção, digo parcialmente, pq estou
> tendo que retirar tudo dele. Eu não consigo deixar o storage rodando direto.
>
> Primeiro, o cenário é o seguinte: Tenho 4 servidores com discos
> compartilhados para este storage.
> 3 servidores usando Geom Gated, esportando 1 disco de 1Tb cada e 1 disco de
> 750Gb cada.
> E no ultimo servidor que o ZFS está atuando, e ele que importa os discos
> pelo GEOM Gatec.
> Disponibilizando para o ZFS, 3 x 1TB, e 3x 750Gb. Com isso eu montei  o
> seguinte pool:
>
> RAIDZ1 ( 750GB + 750GB + 750GB ) + RAIDZ1 ( 1TB + 1TB + 1TB )
> Somando 3.5TB disponiveis.
>
> Neste pool, eu criei um ponto de montagem para backup de e-mails, os quais
> eu transfiro toda madrugada do servidor de e-mail para este pool usando
> exportação NFS do proprio ZFS. A transferencia é feita pelo rsync, assim eu
> crio 2 pastas com os e-mails: backup e deletados (eu mantenho uma copia dos
> e-mails deletados). E os e-mails são armazenados usando o Maildir (em um
> sistema Postfix). Então cada conta de e-mail, possui vários arquivos.
> Totalizando o backup destes e-mail possui cerca de 50Gb compactado (este
> ponto de montagem do ZFS está com o gzip-9 ativado) e 1110 caixas de e-mail
> (os usuários usam imap para verificar as mensagens, e as caixas não possuem
> quota - então algumas caixas chegam a ter mais de 4Gb de e-mails - e
> milhares de mensagens).
>
> O rsync que roda no servidor de e-mail toda madrugada para fazer a
> transferencia está rodando dentro do Periodic (Daily).
>
> Além dos backups do servidor de e-mail, este storage é utilizado por 3
> Servidores VMWare ESXi para armazenamento dos discos das maquinas virtuais.
> Eu exporto um ponto de montagem do ZFS para os servidores ESXi usando o NFS
> do ZFS. Atualmente as maquinas virtuais estão utilizando aproximadamente
> 300Gb de espaço. Não utilizo compressão neste ponto de montagem.
>
> Agora, o que está ocorrendo.
>
> Toda madrugada, o ZFS trava. Ele simplesmente para de responder. O NFS some
> do ar, um segundo compartilhamento que eu possuo usando iSCSI (como teste
> para acesso do ESXi), também para de responder.
> Eu consigo acessar o servidor normalmente via SSH, porém se eu ir até algum
> ponto de montagem do ZFS, e digitar "ls", meu shell fica travado. Se eu
> mando dar um reboot no servidor, ele inicia o processo de reboot, porém
> trava quando vai desligar os serviços... provavalmente o do ZFS.
>
> Eu estou utilizando um script para gerar um relatorio da utilização da
> memória do kernel:
>
> paramount em freud paramount # /usr/local/etc/periodic/daily/000.kmem
> Summarize of kernel memory utilization:
>  TEXT = 12386425, 11.8126 MB
>  DATA = 1268871168, 1210.09 MB
>  TOTAL = 1281257593, 1221.9 MB
> paramount em freud paramount #
>
> Como este script está no periodic, eu recebo um e-mail toda madrugada com os
> dados da utilização da memória do kernel.
> O que eu reparei, é que nos dias que o ZFS trava, eu recebo a seguinte
> mensagem:
>
> Summarize of kernel memory utilization:
>  TEXT = 12386425, 11.8126 MB
>  DATA = 1774715904, 1692.5 MB
>  TOTAL = 1787102329, 1704.31 MB
>
> Ou seja, a memória utilizada pelo Kernel chegou a 1.7GB.
> Porém eu possuo a seguinte linha no meu /boot/loader.conf
>
> vm.kmem_size="1536M"
> vm.kmem_size_max="1536M"
>
> Então eu nem entendo como a memória do kernel ultrapassou esse limite.
> Eu tentei aumentar esses valores, porém o servidor parou de inicializar...
> ele travava com um kernel panic antes mesmo de exibir qualquer outra
> mensagem no boot.
> Nesse servidor eu possuo 4GB de memória. E ele é utilizado apenas como
> storage, não possuo nenhum outro serviço rodando nele. E é um Intel Core 2
> Quad Q6600. Com placa mãe Intel D975XBX2.
> Utilizo 2 discos de 80Gb Sata apenas para o sistema... usango o GEOM Mirror.
>
>
> A minha suspeita, é que o ZFS está tendo problemas para lidar com a
> quantidade de arquivos que o backup de e-mail possui. Acredito que o
> problema não seja o tamanho em si dos dados, porque nem é tão grande. Mas a
> quantidade de arquivos é imensa. E ao meu ver, é isso que está estourando a
> utilização de memória do kernel.
>
> Eu estou removendo o backup de e-mails do ZFS esta tarde. Irei criar um
> volume UFS dentro do ZFS para armazenamento destes e-mails. E ver se o
> storage continua travando após isso.
>
> Mas eu gostaria de saber da lista se alguém teve algum problema parecido com
> o ZFS, ou sabe alguma solução para isso?
>
> O storage funciona muito bem, é rápido, acesso ele via placa de REDE (é uma
> placa HP NC360T com 2 portas Gigabit em trunking com um switch gigabit
> D-Link WebSmart de 16 portas). O único problema é que quase todos os dias eu
> preciso resetar o servidor pois ele está com o ZFS travado e com isso eu nem
> consigo reiniciar a quente.
>
> Agradeço qualquer sugestão.
>
> --
> Rafael Henrique da Silva Faria
> # Técnico de Informática
> # Faculdade de Ciências e Letras
> # Campus de Araraquara - UNESP
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>


-- 
- = - = - = - = - = - = - = - = - = -
<----.      Of course it runs                William David Armstrong
<----|==========================   Bio Systems Security Networking
<----'                  FreeBSD           MSN / GT  biosystems  gmail . com
 http://biosystems.ath.cx:8080/  http://biosystems.broker.freenet6.net/
--------------------------------------