[FUG-BR] Cache squid de 1 Tb
Joao Rocha Braga Filho
goffredo em gmail.com
Segunda Setembro 22 02:30:50 BRT 2008
2008/9/21 Ademir Costa Peixoto <ademir at tellecom.com.br>:
> Olá João,
>
>
> Refiz a minha tabela de slices, deixei apenas 2 em cada uma das 4
> partições em cada disco sata2 de 500g.
> Não monto filesystem de squid em fstab. Faço por script como esse:
>
> mount -o noexec,async,noatime,nosuid /dev/ad14s1d /cache1
> mount -o noexec,async,noatime,nosuid /dev/ad14s1e /cache2
> mount -o noexec,async,noatime,nosuid /dev/ad14s2d /cache3
> mount -o noexec,async,noatime,nosuid /dev/ad14s2e /cache4
> mount -o noexec,async,noatime,nosuid /dev/ad14s3d /cache5
> mount -o noexec,async,noatime,nosuid /dev/ad14s3e /cache6
> mount -o noexec,async,noatime,nosuid /dev/ad14s4d /cache7
> mount -o noexec,async,noatime,nosuid /dev/ad14s4e /cache8
> mount -o noexec,async,noatime,nosuid /dev/ad16s1d /cache9
> mount -o noexec,async,noatime,nosuid /dev/ad16s1e /cache10
> mount -o noexec,async,noatime,nosuid /dev/ad16s2d /cache11
> mount -o noexec,async,noatime,nosuid /dev/ad16s2e /cache12
> mount -o noexec,async,noatime,nosuid /dev/ad16s3d /cache13
> mount -o noexec,async,noatime,nosuid /dev/ad16s3e /cache14
> mount -o noexec,async,noatime,nosuid /dev/ad16s4d /cache15
> mount -o noexec,async,noatime,nosuid /dev/ad16s4e /cache16
Coloque na fstab com noauto,rw,noatime,noexec,nosuid,nosymfollow.
Para moutar fica muito mais fácil mountar. Basta um mount /cache
se estiver no fstab, e ainda facilita a vida do fsck.
Ainda acho que tem que tem SOMENTE UM (1) File System em cada
disco. Qualquer outro é manter informações de sistemas de arquivos
espalhadas pelo disco, o que obriga muitos seeks (posicionamento
das cabeças de leitura e gravação). Nem sequer faça slices. Faça o
modo DD do disco, o que o sysintall fala que é perigosamente dedicado.
Usar async é meio roleta russa. Se acontecer uma parada brusca, como
uma falta de luz, o sistema de arquivos poderá se danificar facilmente.
>
> Assim tenho 16 cache_dir com 56G cada.
> Voltei ao velho DISKD.
> Até o momento está bem. Tem 2 horas de uptime.
> O problema acontece quando o cache começa a ter mais de 200Gb de
> dados... aí é que a coisa começa a tropeçar. O micro tem 8Gb de ram, não faz
> nada além de proxy + dns (Bind 9).
Não libere todo o cache de uma vez. Limite em 50 GB por cada um dos
dois sistemas de arquivos que sugeri. Veja como reage, e depois aumente.
Os parâmetros a serem observados são o uso de memória do squid, que
pode ser visto no top, e ainda observe o iostat, e veja quanto IO está sendo
feito. o iostat vai dar uma idéia se o disco está sobrecarregado.
>
> Estava tudo na paz, eu estava usando 10 cache_dirs com AUFS mas quando
> ele atingiu 480Gb de cache começou a dizer:
>
> 2008/09/20 08:31:34| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:31:34| /cache2/1A/38/001A38BC
> 2008/09/20 08:31:34| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:31:34| /cache9/1E/03/001E035E
> 2008/09/20 08:32:10| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:32:10| /cache2/1A/38/001A38BC
> 2008/09/20 08:32:10| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:32:10| /cache9/1E/03/001E035E
> 2008/09/20 08:32:40| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:32:40| /cache2/1A/38/001A38BC
> 2008/09/20 08:32:40| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:32:40| /cache9/1E/03/001E035E
> 2008/09/20 08:33:07| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:33:07| /cache2/1A/38/001A38BC
> 2008/09/20 08:33:07| DiskThreadsDiskFile::openDone: (2) No such file or
> directory
> 2008/09/20 08:33:07| /cache9/1E/03/001E035E
Dá a impressão que dois sistemas de arquivos se corromperam. Isto é
estranho.
>
> PS: Já fiz muitos testes com os HDs e eles nunca tropeçaram em um bit
> sequer (os erros se referem aos 2 hds ao mesmo tempo)
>
>
> Aí e picotei em 56 cache_dirs mas deu erro de "squidaio_queue_request:
> WARNING - Queue congestion"
Você sobrecarregou os discos. Imagine ficar acessando muitas tabelas
de i-nodes e árvores de diretórios espalhadas pelo disco. Por isto que
estou falando para fazer SOMENTE um sistema de arquivos por disco.
Você só vai ter uma tabela de i-nodes e uma árvore de diretórios, e no
início do disco, onde a taxa de transferência é maior e a quantidade de
seeks é menor.
>
>
> Agora voltei ao DISKD (como citei no início) em 16 daemons e vamos ver
> no que dá.
> Tem horas que parece que o squid foi feito pra cache de 10Gb no
> máximo... é tanta aberração que aparece quando vc turbina que dá vontade de
> desistir e partir pra uma outra coisa qualquer.
Estou operando a 2 anos com 63 GB de cache, em um disco de 80 GB,
sem problemas. Só o desempenho deu um pulo recentemente quando
fiz o upgrade para a versão 2.7 do squid.
> O pior é que é praticamente um monopólio.. Ninguém fala de outro Proxy..
> todos vivemos a mercê do squid e de seus bugs.
Pode usar o Apache, ou os comerciais (o que pode vir a descobrir que são
algum derivado do squid), mas o squid é muito bom.
>
> Obrigado a todos.
> Sei que essa cruzada é pra todos e se eu puder servir de cobaia, estou
> de pé e a órdem.
Daqui a algumas semanas, se tudo der certo, vou estar com um squid
operando com 2 HDs de 250 GB. Eu já lhe adiantei várias dicas do que
eu vou fazer. Só vou fazer um sistema de arquivos por disco, com a
opção do newfs de "-i 20480". Vou limitar inicialmente 50 GB para cada
um deles, e observar o comportamento. Depois vou subir aos poucos.
João Rocha.
>
>
> Ats,
>
> Ademir Peixoto
>
>
>
>
>
> ----- Original Message -----
> From: "Joao Rocha Braga Filho" <goffredo at gmail.com>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> <freebsd at fug.com.br>
> Sent: Sunday, September 21, 2008 9:13 PM
> Subject: Re: [FUG-BR] Cache squid de 1 Tb
>
>
> 2008/9/21 Ademir Costa Peixoto <ademir at tellecom.com.br>:
>> Prezados,
>>
>> Estamos com um servidor Quad 6600 com 8Gb de ram.
>> Temos 2 HDs Satas2 de 500Gb cada.
>> Fui particionar ele ontem pra ter slices menores e só consegui fazer 4
>> partições FreeBSD com 7 slices cada. Totalizando 28 filesystens por HD.
>> Então criei 56 diretórios pra cache no SQUID.:
>> cache_dir aufs /cache1 7770 16 128
>> cache_dir aufs /cache2 7770 16 128
>> cache_dir aufs /cache3 7770 16 128
>> cache_dir aufs /cache4 7770 16 128
>> ...
>> cache_dir aufs /cache55 7770 16 128
>> cache_dir aufs /cache56 7770 16 128
>
> Não faça isto. Monte somente 2 sistemas de arquivos, um pra cada HD.
> Aumentará a eficiência de uso, e terá somente uma tabela de i-nodes,
> que estará no inicio do disco, se não me engano, onde o acesso é mais
> eficiente. Com tantos sistemas de arquivos que você fez, o acesso a eles
> não será eficiente. O squid possivelmente distribuirá a carga bem melhor
> entro 2 sistemas de arquivos do que entre tantos, que pode, dependendo
> do algoritmo dele, saturar um disco, e dois o outro, alternadamente.
>
> Se for aceitar objetos grandes no cache, tipo 100 MB, sugiro usar a opção
> "-i 20480" no newfs. Se for bem menores, use a opção "-i 13000".
>
> Não aumente a cache toda de uma vez. Aumente aos poucos, tipo 100GB,
> e depois veja o comportamento. A minha experiência diz que o disco pode
> ficar muito ocupado com caches de 63 GB.
>
>
>>
>> Tá funcionando bem mas mesmo com o cache zerado em poucos minutos
>> começa
>> a ter os famigerados:
>> squidaio_queue_request: WARNING - Queue congestion
>
> Pode ser o que eu falei, e a quantidade de seeks que os discos estão
> tendo de fazer, por causa da quantidade de tabelas de i-nodes espalhadas
> pelo disco. Tente a minha sugestão acima,
>
> Outra coisa, o uso de memória do squid é proporcional ao tamanho da
> cache em disco, portanto, mais um motivo para fazê-la crescer devagar,
> e ver como se comporta.
>
>>
>> O Micro é todo intel. O average fica em 0.09 e o buzy dos HDs não
>> passam
>> de 21% sob fogo cruzado (14mbps de link).
>> Tentei usar DISKD mas ele não abre mais que 8 daemons simultâneos.
>
> É o disco físico que está saturando. Ele que não está conseguindo acompanhar
> a quantidade de requisições que está recebendo.
>
>>
>> Antes que alguém fale de SCSI eu já respondo que não exitem hds dessa
>> capacidade a valores abaixo de U$ 1.000,00 e acho que não tem nem no
>> Brasil.
>
> Não adianta um cache grande se o disco não puder acompanhar a quantidade
> de requisições que recai sobre ele. Dois discos de 143 GB com 15 KRPM pode
> dar mais desempenho total do que dois discos de 500 GB de 7200 RPM.
>
>
>>
>> Pergunto:
>>
>> Qual a melhor forma de aproveitar esse cache?
>>
>> Realmente esse congestioamento é por I/O lento?
>>
>> Tem como usar XFS no FreeBsd 7.0 e Squid 3.0 Stable8?
>
> Experimente 2 sistemas de arquivos somente, com Soft Update, sem sequer
> tabela de partições. Não esqueça da opção de noatime no /etc/fstab. Se
> quiser ser paranóico, rw,noatime,noexec,nosuid,nosymfollow.
>
> Use um terceiro disco para o sistema. Faça os dois discos exclusivos pro
> cache.
>
> Li a sugestão do RAID 1. Ele vai melhorar a leitura, mas poderá piorar um
> pouco a escrita. No início a sua cache fará muitas escritas. Acho que 2
> discos separados pode melhorar mais ainda o desempenho.
>
> Ao invés de dividir em várias istâncias, por que não usa aufs, que faz multi
> tarefa?
>
>
> João Rocha.
>
> PS: Se tentar a minha sugestão, e de vários adiante também, conte como
> foi o resultado.
>
>
>
>>
>>
>>
>> Ats,
>>
>> Ademir Peixoto
>>
>>
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>
>
>
> --
> "Sempre se apanha mais com as menores besteiras. Experiência própria."
>
> goffredo at gmail.com
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
--
"Sempre se apanha mais com as menores besteiras. Experiência própria."
goffredo at gmail.com
Mais detalhes sobre a lista de discussão freebsd