2008/9/23 Eduardo Schoedler <[EMAIL PROTECTED]>: > 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" <[EMAIL PROTECTED]> > Subject: Re: [FUG-BR] Cache squid de 1 Tb > > 2008/9/21 Eduardo Schoedler <[EMAIL PROTECTED]>: >> 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" <[EMAIL PROTECTED]> >> 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" <[EMAIL PROTECTED]> >> 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" <[EMAIL PROTECTED]> >> Sent: Sunday, September 21, 2008 9:13 PM >> Subject: Re: [FUG-BR] Cache squid de 1 Tb >> >> >> 2008/9/21 Ademir Costa Peixoto <[EMAIL PROTECTED]>: >>> 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." > > [EMAIL PROTECTED] > > ------------------------- > 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." [EMAIL PROTECTED] ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd