[FUG-BR] Cache squid de 1 Tb
Joao Rocha Braga Filho
goffredo em gmail.com
Terça Setembro 23 19:04:02 BRT 2008
2008/9/23 Eduardo Schoedler <eschoedler at viavale.com.br>:
> Olá João!
>
> Nesse caso, utilize uma partição para COSS somente para arquivos pequenos...
> e deixe um outro diretório (diskd/aufs/oq for) para os arquivos grandes.
>
> Que tal ?
Isto é muito bom, mas como digo quais arquivos é para colocar lá?
Como limito o tamanho de arquivos a serem colocados lá?
João Rocha.
>
> Abraço.
>
>
>
> --------------------------------------------------
> From: "Joao Rocha Braga Filho" <goffredo at gmail.com>
> Subject: Re: [FUG-BR] Cache squid de 1 Tb
>
> 2008/9/21 Eduardo Schoedler <eschoedler at viavale.com.br>:
>> Já tentou utilizar COSS ?
>> Tente utilizar ele DIRETAMENTE na partição, sem nenhum sistema de
>> arquivos.
>>
>> cache_dir coss /dev/sdf1 34500 max-size=524288 max-stripe-waste=32768
>> block-size=4096 maxfullbufs=10
>> # This will use the /dev/sdf1 partition
>> # The cache_dir will store up to 34500MB worth of data
>> # The block size is 4096 bytes
>> # Objects that are up to 524288 bytes long will be stored.
>> # If a given stripe has less than 524288 bytes available, this cache_dir
>> will only accept smaller objects until there is less than 32768 bytes
>> available in the stripe.
>> # If the default stripe size of 1MB is not changed, up to 10MB will be
>> used for stripes that are waiting to be written to disk.
>
> Isto parece ser interessante. Tira todo o overhead criado pelo sistema de
> arquivos. O squid passa a lidar diretamente com o disco. Espero que ele
> seja eficiente com isto, mas vale fazer uma tentativa.
>
> Mas lendo:
>
> "
> # block-size=n defines the "block size" for COSS cache_dir's.
> # Squid uses file numbers as block numbers. Since file numbers
> # are limited to 24 bits, the block size determines the maximum
> # size of the COSS partition. The default is 512 bytes, which
> # leads to a maximum cache_dir size of 512<<24, or 8 GB. Note
> # you should not change the COSS block size after Squid
> # has written some objects to the cache_dir.
> "
>
> Com block-size de 4098, o tamanho máximo da cache é de 64 GB.
>
> Lendo mais, me pareceu que o formato COSS é muito limitado, e pode
> deixar de armazear muitas coisas grandes que merecem ser guardadas.
> Ele parece só armazernar arquivos contínuos - se não tiver uma seqüência
> de blocos grande suficiente para caber o arquivo, ele pode não guardá-lo - e
> ainda pode duplicar os arquivos armazenados. Acho que deveriam ter
> criado algo melhor.
>
>>
>> Mais informações em:
>> http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem
>> 8. Examples
>
> Vou dar uma olhada.
>
>
> João Rocha.
>
>>
>>
>> Lembrando que para utilizar DISKD / AUFS / COSS, você deve compular o
>> kernel
>> com a opção:
>> options VFS_AIO
>>
>> Caso já tenha compilado o kernel sem a opção, carregue como módulo:
>> kldload aio
>>
>>
>> Abraços.
>>
>>
>> --------------------------------------------------
>> From: "Victor" <victor_volpe at bol.com.br>
>> 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>
>> 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>
>> 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
>
> --
> "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
>
--
"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