[FUG-BR] Cache squid de 1 Tb

Segunda Setembro 22 03:08:11 BRT 2008

2008/9/21 Victor <victor_volpe at bol.com.br>:
> Olá Ademir,
>
> Eu entendo, porém quando mais partições e mais slices tiver, pior vai ser o
> rendimento. Tente utilizar 1 slice e 1 partição em cada disco e trabalhe com
> 8 pastas cache em cada um. Pode ter certeza que os problemas acabarão. Só
> que faça conforme nosso amigo disse, não deixe o cache tão grande... vá
> aumentando gradativamente. Não importa o tamanho da partição e sim o do
> cache ;-)

Nem sequer faça slice. Faça o modo DD, usando o disco inteiro. Mas não
faça o nível 1 de diretório pequeno.

Por exemplo, estou com "maximum_object_size 71680 KB", i.e., 70 MB,
e estou usando 1 i-node para cada 30 KB, i.e., a média de tamanho de
arquivos é de 30 KB. Se o maximum_object_size for bem menor, a média
seria cerca de 14 KB por arquivo.

Para facilitar, vamos assumir que a média é de 30 KB por arquivo, e com
a opção de maximum_object_size grande como coloquei. Para 420 GB de
cache você teria 14 milhões de arquivos. Existe uma regra que fala em
evitar diretórios muito grandes, de mais de 256 arquivos, as isto implica
que teria 54687 diretórios de nível 2. Neste caso, sugiro ter 256 diretórios
de nível um, e 256 de nível dois:

cache_dir aufs /usr/local/squid/cache1 420000 256 256
cache_dir aufs /usr/local/squid/cache2 420000 256 256

Abraços,
    João Rocha.

>
> Abraços.
>
>
> --
> Atenciosamente,
> Victor Gustavo Volpe
> Diretor Executivo
> Grupo Total Serviços de Internet LTDA - ME
> CNPJ: 08.776.401/0001-40
> (17) 3227-0686 / 9105-5392
>
> ----- Original Message -----
> From: "Ademir Costa Peixoto" <ademir at tellecom.com.br>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> <freebsd at fug.com.br>
> Sent: Sunday, September 21, 2008 10:15 PM
> Subject: Re: [FUG-BR] Cache squid de 1 Tb
>
>
> Olá Victor,
>
>
>    Antes de tudo isso começar eu tinha 1 partição e 5 slices em cada HD de
> cache.
>    É que eu lí tanto a respeito de "várias partições" que zerei os HDs e os
> particionei em 4 partes (limite do FreeBSD).
>    Agora estou operando conforme esquema abaixo:
>    4 Partições com 2 Slices em cada HD.
>
>
>    Ats,
>
>    Ademir Peixoto
>
>
>
> ----- Original Message -----
> From: "Victor" <victor_volpe at bol.com.br>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> <freebsd at fug.com.br>
> Sent: Sunday, September 21, 2008 10:06 PM
> Subject: Re: [FUG-BR] Cache squid de 1 Tb
>
>
> Olá Ademir,
>
> Desculpe a pergunta, mas voce continua usando mais de 2 particionamentos por
> disco ? Acredito que seja esse seu problema.
>
> Abraços.
>
>
> --
> Atenciosamente,
> Victor Gustavo Volpe
> Diretor Executivo
> Grupo Total Serviços de Internet LTDA - ME
> CNPJ: 08.776.401/0001-40
> (17) 3227-0686 / 9105-5392
>
> ----- Original Message -----
> From: "Ademir Costa Peixoto" <ademir at tellecom.com.br>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> <freebsd at fug.com.br>
> Sent: Sunday, September 21, 2008 9:53 PM
> Subject: Re: [FUG-BR] Cache squid de 1 Tb
>
>
> 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
>
>    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).
>
>    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
>
>    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"
>
>
>    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.
>    O pior é que é praticamente um monopólio.. Ninguém fala de outro Proxy..
> todos vivemos a mercê do squid e de seus bugs.
>
>    Obrigado a todos.
>    Sei que essa cruzada é pra todos e se eu puder servir de cobaia, estou
> de pé e a órdem.
>
>
>    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
>
> __________ NOD32 3458 (20080921) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.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
>
> __________ NOD32 3458 (20080921) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
> -------------------------
> 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