[FUG-BR] Cache squid de 1 Tb
Eduardo Schoedler
eschoedler em viavale.com.br
Terça Setembro 23 23:08:34 BRT 2008
No COSS você consegue especificar somente o tamanho máximo do objeto que
será armazenado ali.
Logo, ele serve para os arquivos pequenos até um certo limite.
Você tem de verificar nos outros storages se existe a opção de configurar um
tamanho mínimo de objeto.
Assim, você poderá configurar esse para gravar os arquivos grandes.
Ah, se alguém utiliza DISKD, existem alguns tweaks no kernel para quem usa
FreeBSD.
http://wiki.squid-cache.org/SquidFaq/DiskDaemon
sds.
--------------------------------------------------
From: "Joao Rocha Braga Filho" <goffredo em gmail.com>
Subject: Re: [FUG-BR] Cache squid de 1 Tb
2008/9/23 Eduardo Schoedler <eschoedler em 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 em gmail.com>
> Subject: Re: [FUG-BR] Cache squid de 1 Tb
>
> 2008/9/21 Eduardo Schoedler <eschoedler em 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 em 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 em 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 em 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 em 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 em 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 em gmail.com
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Mais detalhes sobre a lista de discussão freebsd