Re: [FUG-BR] Cache squid de 1 Tb
sobre a parte de consumo de cpu, talvez a solução conjunta de CACHEBOY + FUSION I/O !! chega aos 10.000 usuarios !! www.cacheboy.net projeto paralelo ao squid.. porem mantido na linguagem C !!! 2008/9/27 Joao Rocha Braga Filho [EMAIL PROTECTED]: 2008/9/27 Eduardo Schoedler [EMAIL PROTECTED]: Agora imagina um storage COSS para arquivos pequenos utilizando esse hardware: http://www.fusionio.com/Products.aspx Até aceito um hd ide para deixar os arquivos grandes... rsrsrs. Muito bom, mas parece ter um problema grave... falta de driver. Tem a promessa para segunda metade deste ano o suporte para Mac OS X. Pelo visto não simula uma controladora com um disco, o que eu tentaria fazer para não ter problemas com drivers. O de 320 GB cai MUITO o desempenho, mas mesmo assim ja é muito superior a um HD. Realmente, é um monstro em desempenho. Um squid com um COSS nele para fazer arquivos até 128 KB, e um conjunto de discos de 15 KRPM para arquivos maiores seria um monstro. Acho que poderia atender uns 10 mil usuários simultâneos, exceto pelo problema que faltaria CPU para atender o squid. Abraços, João Rocha. Abraços. -- From: Joao Rocha Braga Filho [EMAIL PROTECTED] Subject: Re: [FUG-BR] Cache squid de 1 Tb 2008/9/26 João Paulo Just [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joao Rocha Braga Filho wrote: | Voltando ao assunto. Me deu a idéia de usar um disco com coss, sem | sistema de arquivos, para arquivos até uns 32 KB, ou 64 KB, e um com | diskd ou aufs para objetos maiores. Dúvida. Se um objeto for grande | para armazenar no coss, onde ele colocará? Ele armazenará no outro | cache, ou descartará? Se todos os objetos pequenos ficarão no coss | deixando os grandes para o outro? De dividir assim, acho que fica uma | boa relação de desempenho. Tem um parâmetro no cache_dir, max-size=n, onde n é o tamanho máximo do arquivo em bytes, se não me engano. Use o max-size no cache_dir com COSS e use min-size no outro cache_dir. Eu fiz por merecer um RTFM, e obrigado por não ter falado. rsrs Tirando do squid.conf # min-size=n, refers to the min object size this storedir will accept. # It's used to restrict a storedir to only store large objects # (e.g. aufs) while other storedirs are optimized for smaller objects # (e.g. COSS). Defaults to 0. # # max-size=n, refers to the max object size this storedir supports. # It is used to initially choose the storedir to dump the object. # Note: To make optimal use of the max-size limits you should order # the cache_dir lines with the smallest max-size value first and the # ones with no max-size specification last. Muito Obrigado. João Rocha. - -- João Paulo Just Diretor Executivo - Justsoft Informática Ltda. http://www.justsoft.com.br/ - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 Blog: http://just.rg3.net/ - 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 -- Sds. Alexandre J. Correa Onda Internet / OPinguim.net http://www.ondainternet.com.br http://www.opinguim.net - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joao Rocha Braga Filho wrote: | Eu fiz por merecer um RTFM, e obrigado por não ter falado. rsrs Ôh,é verdade. rsrsrs :P - -- João Paulo Just Diretor Executivo - Justsoft Informática Ltda. http://www.justsoft.com.br/ - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 Blog: http://just.rg3.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3e89XL+vuN2d7ZwRAs5gAJ4su1qvgpm5aShDhpTRF6kD2aKBRwCeOnxn zHOQx2XsJmNteeOoVT+w1IY= =mEhU -END PGP SIGNATURE- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joao Rocha Braga Filho wrote: | Voltando ao assunto. Me deu a idéia de usar um disco com coss, sem | sistema de arquivos, para arquivos até uns 32 KB, ou 64 KB, e um com | diskd ou aufs para objetos maiores. Dúvida. Se um objeto for grande | para armazenar no coss, onde ele colocará? Ele armazenará no outro | cache, ou descartará? Se todos os objetos pequenos ficarão no coss | deixando os grandes para o outro? De dividir assim, acho que fica uma | boa relação de desempenho. Tem um parâmetro no cache_dir, max-size=n, onde n é o tamanho máximo do arquivo em bytes, se não me engano. Use o max-size no cache_dir com COSS e use min-size no outro cache_dir. - -- João Paulo Just Diretor Executivo - Justsoft Informática Ltda. http://www.justsoft.com.br/ - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 Blog: http://just.rg3.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3RTGXL+vuN2d7ZwRAuuzAKDGvBX7K3AFGwcUIxwHfx/6X7DiYgCgu2lZ BMraAJ3UqBPNJUnXyOjzKzs= =9Gv9 -END PGP SIGNATURE- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/26 João Paulo Just [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joao Rocha Braga Filho wrote: | Voltando ao assunto. Me deu a idéia de usar um disco com coss, sem | sistema de arquivos, para arquivos até uns 32 KB, ou 64 KB, e um com | diskd ou aufs para objetos maiores. Dúvida. Se um objeto for grande | para armazenar no coss, onde ele colocará? Ele armazenará no outro | cache, ou descartará? Se todos os objetos pequenos ficarão no coss | deixando os grandes para o outro? De dividir assim, acho que fica uma | boa relação de desempenho. Tem um parâmetro no cache_dir, max-size=n, onde n é o tamanho máximo do arquivo em bytes, se não me engano. Use o max-size no cache_dir com COSS e use min-size no outro cache_dir. Eu fiz por merecer um RTFM, e obrigado por não ter falado. rsrs Tirando do squid.conf # min-size=n, refers to the min object size this storedir will accept. # It's used to restrict a storedir to only store large objects # (e.g. aufs) while other storedirs are optimized for smaller objects # (e.g. COSS). Defaults to 0. # # max-size=n, refers to the max object size this storedir supports. # It is used to initially choose the storedir to dump the object. # Note: To make optimal use of the max-size limits you should order # the cache_dir lines with the smallest max-size value first and the # ones with no max-size specification last. Muito Obrigado. João Rocha. - -- João Paulo Just Diretor Executivo - Justsoft Informática Ltda. http://www.justsoft.com.br/ - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 Blog: http://just.rg3.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3RTGXL+vuN2d7ZwRAuuzAKDGvBX7K3AFGwcUIxwHfx/6X7DiYgCgu2lZ BMraAJ3UqBPNJUnXyOjzKzs= =9Gv9 -END PGP SIGNATURE- - 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
Re: [FUG-BR] Cache squid de 1 Tb
Agora imagina um storage COSS para arquivos pequenos utilizando esse hardware: http://www.fusionio.com/Products.aspx Até aceito um hd ide para deixar os arquivos grandes... rsrsrs. Abraços. -- From: Joao Rocha Braga Filho [EMAIL PROTECTED] Subject: Re: [FUG-BR] Cache squid de 1 Tb 2008/9/26 João Paulo Just [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joao Rocha Braga Filho wrote: | Voltando ao assunto. Me deu a idéia de usar um disco com coss, sem | sistema de arquivos, para arquivos até uns 32 KB, ou 64 KB, e um com | diskd ou aufs para objetos maiores. Dúvida. Se um objeto for grande | para armazenar no coss, onde ele colocará? Ele armazenará no outro | cache, ou descartará? Se todos os objetos pequenos ficarão no coss | deixando os grandes para o outro? De dividir assim, acho que fica uma | boa relação de desempenho. Tem um parâmetro no cache_dir, max-size=n, onde n é o tamanho máximo do arquivo em bytes, se não me engano. Use o max-size no cache_dir com COSS e use min-size no outro cache_dir. Eu fiz por merecer um RTFM, e obrigado por não ter falado. rsrs Tirando do squid.conf # min-size=n, refers to the min object size this storedir will accept. # It's used to restrict a storedir to only store large objects # (e.g. aufs) while other storedirs are optimized for smaller objects # (e.g. COSS). Defaults to 0. # # max-size=n, refers to the max object size this storedir supports. # It is used to initially choose the storedir to dump the object. # Note: To make optimal use of the max-size limits you should order # the cache_dir lines with the smallest max-size value first and the # ones with no max-size specification last. Muito Obrigado. João Rocha. - -- João Paulo Just Diretor Executivo - Justsoft Informática Ltda. http://www.justsoft.com.br/ - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 Blog: http://just.rg3.net/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
É nisso vc esta corretíssmo, varios FS vao ferrar o desempenho de qualquer disco ou array de disco... Outro detalhe importante se voce usa raid, é o tamanho do chunk ou setor do array, algumas controladoras tem opcoes de 16,32,64,128,1024,2048kb.. e etc.. Voce deve definir esse tamanho em funcao do tamanho de arquivo que vc armazena em média.. Se sao milhares de arquivinhos de 25K por exemplo, definir um chunk de 2048 vai fazer vc perder muito espaco no disco, ao mesmo tempo que se for um arquivo grande, um setor pequeno vai ocasionar muitos reads no array, aí seria o caso de um chunk de 2048K para um arquivo de 5M por exemplo seria mais negocio.. entao tens que analisar isso tambem. se for o teu caso.. Agora que é melhor ter um FS gigantesco apenas para o squid isso é.. A nao ser que cada FS esteja num disco fisico diferente.. []'s 2008/9/22 Joao Rocha Braga Filho [EMAIL PROTECTED]: 2008/9/22 Ademir Costa Peixoto [EMAIL PROTECTED]: Eita... até de leigo sou chamado... Desculpe-me. A impressão que deu é que vovê não entendeu como funciona o disco, e as limitações de desempenho dele. O início do disco é a parte mais eficiente dele, portanto a primeira partição que eu crio, depois do /, é o swap. No início do disco tem mais setores por trilha, para manter a densidade linear constante e aproveitar a máxima densidade que a mídia magnética pode fornecer. Os seeks para ler os diretórios e as tabelas de i-node são menores, etc. Quando criou várias caches no mesmo disco, forçou a cabeça viajar desnecessariamente pelo disco todo, mesmo com a cache relativamente vazia. O seek track to track em muitos HDs é de cerca de 1 ms, enquanto o full stroke é de 20 ms. Você forçou muitos seeks quase full stroke, pelo disco todo, quando poderiam ser mais track to track se tivesse somente um único sistema de arquivos. Fez sentido? Por isto que estou teimando contigo para fazer um só sistema de arquivos em cada disco. Abraços, João Rocha. Ats, Ademir Peixoto - Original Message - From: Joao Rocha Braga Filho [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Monday, September 22, 2008 7:32 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb On Mon, Sep 22, 2008 at 7:10 PM, Leonardo Augusto [EMAIL PROTECTED] wrote: Problemas com desempenho de IO ? Vai de raid 10 = mirror de strip... o read é muito rapido.. Voce precisa de no minimo 4 discos para tal.. mas vale a pena.. (se puser 6 discos entao...) Use uma controladora SCSI Ultra 320 (ou uma sas 3G) com pelo menos 128Mega de cache.. O problema dele é outro. Ele está fazendo vários caches no mesmo disco, criando vários sistemas de arquivos, o que é um erro grave. Nem este RAID que você sugeriu resolveria o problema dele. Ele ainda não entende como funciona um HD. João Rocha. []'s - 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 - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/23 Leonardo Augusto [EMAIL PROTECTED] É nisso vc esta corretíssmo, varios FS vao ferrar o desempenho de qualquer disco ou array de disco... Outro detalhe importante se voce usa raid, é o tamanho do chunk ou setor do array, algumas controladoras tem opcoes de 16,32,64,128,1024,2048kb.. e etc.. Voce deve definir esse tamanho em funcao do tamanho de arquivo que vc armazena em média.. Se sao milhares de arquivinhos de 25K por exemplo, definir um chunk de 2048 vai fazer vc perder muito espaco no disco, ao mesmo tempo que se for um arquivo grande, um setor pequeno vai ocasionar muitos reads no array, aí seria o caso de um chunk de 2048K para um arquivo de 5M por exemplo seria mais negocio.. entao tens que analisar isso tambem. se for o teu caso.. Agora que é melhor ter um FS gigantesco apenas para o squid isso é.. A nao ser que cada FS esteja num disco fisico diferente.. []'s Interessante tem alguma forma de se destinar deternimando arquivo que será armazenado no cache para um disco cujo sistema de arquivos esteja mais indicado quanto ao tamanho do arquivo a ser armazenar ? No caso o squid opta por qual será o melhor destino para o arquivo final baseado em seu tamanho e com relação ao tamanho do setor visando sempre poupar espaço !!! -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
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 ? 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 51224, 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
Re: [FUG-BR] Cache squid de 1 Tb
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 51224, 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
Re: [FUG-BR] Cache squid de 1 Tb
Olá Eduardo. Eu sempre achei meio estranho um servidor de arquivos depender de um FileSystem pra ter performance. Não seria legal se fosse como o NOVEL? Ter sua própria formatação e técnica de acesso aos dados? No caso do COSS, como faríamos pra informar ao squid que ele não deve gravar objetos pequenos na partição com DISKD? Qual a maior partição que pode ser criada com essa técnica do COSS sem filesystem? Ats, Ademir Peixoto - Original Message - From: Eduardo Schoedler [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Tuesday, September 23, 2008 6:10 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb 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 ? 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 51224, 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
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/23 Eduardo Schoedler [EMAIL PROTECTED]: 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 A dica para o Linux é até engraçada: Linux * /!\ Use AUFS on Linux. It's much faster. Voltando ao assunto. Me deu a idéia de usar um disco com coss, sem sistema de arquivos, para arquivos até uns 32 KB, ou 64 KB, e um com diskd ou aufs para objetos maiores. Dúvida. Se um objeto for grande para armazenar no coss, onde ele colocará? Ele armazenará no outro cache, ou descartará? Se todos os objetos pequenos ficarão no coss deixando os grandes para o outro? De dividir assim, acho que fica uma boa relação de desempenho. João Rocha. sds. -- From: Joao Rocha Braga Filho [EMAIL PROTECTED] Subject: Re: [FUG-BR] Cache squid de 1 Tb 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 51224, 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
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/21 Victor [EMAIL PROTECTED]: 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 42 256 256 cache_dir aufs /usr/local/squid/cache2 42 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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/21 Ademir Costa Peixoto [EMAIL PROTECTED] ... Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Olá, tem sim, basta fazer um fwd. Dê uma olhada no histórico da lista. Isto já discutido várias vezes. Quanto à perda de performance, uma solução pode ser a troca de SO (e por consequeência a de FS) :-) -- -syncd! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
Problemas com desempenho de IO ? Vai de raid 10 = mirror de strip... o read é muito rapido.. Voce precisa de no minimo 4 discos para tal.. mas vale a pena.. (se puser 6 discos entao...) Use uma controladora SCSI Ultra 320 (ou uma sas 3G) com pelo menos 128Mega de cache.. []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
On Mon, Sep 22, 2008 at 7:10 PM, Leonardo Augusto [EMAIL PROTECTED] wrote: Problemas com desempenho de IO ? Vai de raid 10 = mirror de strip... o read é muito rapido.. Voce precisa de no minimo 4 discos para tal.. mas vale a pena.. (se puser 6 discos entao...) Use uma controladora SCSI Ultra 320 (ou uma sas 3G) com pelo menos 128Mega de cache.. O problema dele é outro. Ele está fazendo vários caches no mesmo disco, criando vários sistemas de arquivos, o que é um erro grave. Nem este RAID que você sugeriu resolveria o problema dele. Ele ainda não entende como funciona um HD. João Rocha. []'s - 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
Re: [FUG-BR] Cache squid de 1 Tb
Eita... até de leigo sou chamado... Ats, Ademir Peixoto - Original Message - From: Joao Rocha Braga Filho [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Monday, September 22, 2008 7:32 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb On Mon, Sep 22, 2008 at 7:10 PM, Leonardo Augusto [EMAIL PROTECTED] wrote: Problemas com desempenho de IO ? Vai de raid 10 = mirror de strip... o read é muito rapido.. Voce precisa de no minimo 4 discos para tal.. mas vale a pena.. (se puser 6 discos entao...) Use uma controladora SCSI Ultra 320 (ou uma sas 3G) com pelo menos 128Mega de cache.. O problema dele é outro. Ele está fazendo vários caches no mesmo disco, criando vários sistemas de arquivos, o que é um erro grave. Nem este RAID que você sugeriu resolveria o problema dele. Ele ainda não entende como funciona um HD. João Rocha. []'s - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/22 Ademir Costa Peixoto [EMAIL PROTECTED] Eita... até de leigo sou chamado... Calma, Leigo você não é mais aparentemente, passou batido com relação a alguma informação sobre o Squid e carga de io que ele proprícia sobre um disco. Até mais. Ats, Ademir Peixoto - Original Message - From: Joao Rocha Braga Filho [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Monday, September 22, 2008 7:32 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb On Mon, Sep 22, 2008 at 7:10 PM, Leonardo Augusto [EMAIL PROTECTED] wrote: Problemas com desempenho de IO ? Vai de raid 10 = mirror de strip... o read é muito rapido.. Voce precisa de no minimo 4 discos para tal.. mas vale a pena.. (se puser 6 discos entao...) Use uma controladora SCSI Ultra 320 (ou uma sas 3G) com pelo menos 128Mega de cache.. O problema dele é outro. Ele está fazendo vários caches no mesmo disco, criando vários sistemas de arquivos, o que é um erro grave. Nem este RAID que você sugeriu resolveria o problema dele. Ele ainda não entende como funciona um HD. João Rocha. []'s - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/22 Ademir Costa Peixoto [EMAIL PROTECTED]: Eita... até de leigo sou chamado... Desculpe-me. A impressão que deu é que vovê não entendeu como funciona o disco, e as limitações de desempenho dele. O início do disco é a parte mais eficiente dele, portanto a primeira partição que eu crio, depois do /, é o swap. No início do disco tem mais setores por trilha, para manter a densidade linear constante e aproveitar a máxima densidade que a mídia magnética pode fornecer. Os seeks para ler os diretórios e as tabelas de i-node são menores, etc. Quando criou várias caches no mesmo disco, forçou a cabeça viajar desnecessariamente pelo disco todo, mesmo com a cache relativamente vazia. O seek track to track em muitos HDs é de cerca de 1 ms, enquanto o full stroke é de 20 ms. Você forçou muitos seeks quase full stroke, pelo disco todo, quando poderiam ser mais track to track se tivesse somente um único sistema de arquivos. Fez sentido? Por isto que estou teimando contigo para fazer um só sistema de arquivos em cada disco. Abraços, João Rocha. Ats, Ademir Peixoto - Original Message - From: Joao Rocha Braga Filho [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Monday, September 22, 2008 7:32 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb On Mon, Sep 22, 2008 at 7:10 PM, Leonardo Augusto [EMAIL PROTECTED] wrote: Problemas com desempenho de IO ? Vai de raid 10 = mirror de strip... o read é muito rapido.. Voce precisa de no minimo 4 discos para tal.. mas vale a pena.. (se puser 6 discos entao...) Use uma controladora SCSI Ultra 320 (ou uma sas 3G) com pelo menos 128Mega de cache.. O problema dele é outro. Ele está fazendo vários caches no mesmo disco, criando vários sistemas de arquivos, o que é um erro grave. Nem este RAID que você sugeriu resolveria o problema dele. Ele ainda não entende como funciona um HD. João Rocha. []'s - 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 - 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
Re: [FUG-BR] Cache squid de 1 Tb
wiki.squid-cache.org em algum lugar la.. fala que.. eh melhor por ex.. 10 hds de 120gb ... do que 2 de 500gb... (obviamente que sim) nao seis e o hd aguenta voce criar mais de 2 cache_dir por hd.. vai ocasionar esses congestion ai porque o hd nao vai dar conta de atender.. o squid considera cada cache_dir sendo um hd .. para cada cache_dir ele cria N threads... 2008/9/21 Paulo Henrique [EMAIL PROTECTED]: 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Sds. Alexandre J. Correa Onda Internet / OPinguim.net http://www.ondainternet.com.br http://www.opinguim.net - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - 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
Re: [FUG-BR] Cache squid de 1 Tb
Olá Ademir, Como o Alexandre disse, o problema é a quantidade de partição no mesmo disco, resultando no congestionamento pois o squid irá acessar simultaneamente as partições criadas e sabemos que isso não funciona muito bem, a não ser que inventem um HD com uns 200 braços de acesso ao disco. O interessante ai na sua situação é fazer o RAID 0 (stripping) para obter a velocidade deste recurso e dividir estes 1 TB em no maximo 4 partições. Vale mais perder um pouco de desempenho pelos tamanhos das partições do que ficar gerando congestionamento ;-) 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] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:25 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - 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
Re: [FUG-BR] Cache squid de 1 Tb
Já testou usar ZFS ele não é ainda suportado no raiz mais para o que você quer eh excelente, e pelo que li é de otima performace. Compreendo, mais o Alexandre Correa passou uns pontos legais para se pensar. 2008/9/21 Ademir Costa Peixoto [EMAIL PROTECTED] Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Onde está essa documentação pois não me lembro de ter lido sobre tal problema. Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Creio ser desnecessáio pois o Squid ele suporta Ptreads pelo que lembro de ter lido, eh dessa forma que ele trabalha com multiprocessamento simetrico. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Parece que XFS ainda é experimental no FreeBSD. Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - 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 -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cache squid de 1 Tb
2008/9/21 Victor [EMAIL PROTECTED] Olá Ademir, Como o Alexandre disse, o problema é a quantidade de partição no mesmo disco, resultando no congestionamento pois o squid irá acessar simultaneamente as partições criadas e sabemos que isso não funciona muito bem, a não ser que inventem um HD com uns 200 braços de acesso ao disco. O interessante ai na sua situação é fazer o RAID 0 (stripping) Pelo que me lembro de ter lido RAID 0 não é mirror, e RAID 1 que é Stripping ? para obter a velocidade deste recurso e dividir estes 1 TB em no maximo 4 partições. Vale mais perder um pouco de desempenho pelos tamanhos das partições do que ficar gerando congestionamento ;-) 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] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:25 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - 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 -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom
Re: [FUG-BR] Cache squid de 1 Tb
Olá Paulo, Negativo... RAID 1 é mirror. http://pt.wikipedia.org/wiki/RAID 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: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:42 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb 2008/9/21 Victor [EMAIL PROTECTED] Olá Ademir, Como o Alexandre disse, o problema é a quantidade de partição no mesmo disco, resultando no congestionamento pois o squid irá acessar simultaneamente as partições criadas e sabemos que isso não funciona muito bem, a não ser que inventem um HD com uns 200 braços de acesso ao disco. O interessante ai na sua situação é fazer o RAID 0 (stripping) Pelo que me lembro de ter lido RAID 0 não é mirror, e RAID 1 que é Stripping ? para obter a velocidade deste recurso e dividir estes 1 TB em no maximo 4 partições. Vale mais perder um pouco de desempenho pelos tamanhos das partições do que ficar gerando congestionamento ;-) 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] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:25 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http
Re: [FUG-BR] Cache squid de 1 Tb
Olá Alexandre, No caso em especial é melhor voltar ao DISKD ou o AUFS está mais eficiente na versão 3.0x? Ats, Ademir Peixoto - Original Message - From: Alexandre Correa [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:23 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb wiki.squid-cache.org em algum lugar la.. fala que.. eh melhor por ex.. 10 hds de 120gb ... do que 2 de 500gb... (obviamente que sim) nao seis e o hd aguenta voce criar mais de 2 cache_dir por hd.. vai ocasionar esses congestion ai porque o hd nao vai dar conta de atender.. o squid considera cada cache_dir sendo um hd .. para cada cache_dir ele cria N threads... 2008/9/21 Paulo Henrique [EMAIL PROTECTED]: 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Sds. Alexandre J. Correa Onda Internet / OPinguim.net http://www.ondainternet.com.br http://www.opinguim.net - 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
Re: [FUG-BR] Cache squid de 1 Tb
Paulo, Era isso que estava tentando. Onde acho documentação do ZFS no Free (será usado apenas nos 2 HDs de cache)? Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:41 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb Já testou usar ZFS ele não é ainda suportado no raiz mais para o que você quer eh excelente, e pelo que li é de otima performace. Compreendo, mais o Alexandre Correa passou uns pontos legais para se pensar. 2008/9/21 Ademir Costa Peixoto [EMAIL PROTECTED] Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Onde está essa documentação pois não me lembro de ter lido sobre tal problema. Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Creio ser desnecessáio pois o Squid ele suporta Ptreads pelo que lembro de ter lido, eh dessa forma que ele trabalha com multiprocessamento simetrico. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Parece que XFS ainda é experimental no FreeBSD. Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - 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 -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman
Re: [FUG-BR] Cache squid de 1 Tb
Vitor Obrigado, me confundi ... Bom creio eu que as informações que deseja se encontra nesse sitio.. e seus links. http://wiki.freebsd.org/ZFS Até mais. 2008/9/21 Ademir Costa Peixoto [EMAIL PROTECTED] Paulo, Era isso que estava tentando. Onde acho documentação do ZFS no Free (será usado apenas nos 2 HDs de cache)? Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:41 PM Subject: Re: [FUG-BR] Cache squid de 1 Tb Já testou usar ZFS ele não é ainda suportado no raiz mais para o que você quer eh excelente, e pelo que li é de otima performace. Compreendo, mais o Alexandre Correa passou uns pontos legais para se pensar. 2008/9/21 Ademir Costa Peixoto [EMAIL PROTECTED] Olá Paulo, Na verdade esse 1Tb é apenas de cache. O FreeBSD e seus acessórios estão em outro HD em separado. É que sempre lemos que partições acima de 10Gb perdem rendimento no FreeBSD. (por isso que queria tentar o XFS) Onde está essa documentação pois não me lembro de ter lido sobre tal problema. Estou pensando em dividir o cache em várias instâncias e amarrá-los em modo pai-filho pra aproveitar o SMP do Quad. Creio ser desnecessáio pois o Squid ele suporta Ptreads pelo que lembro de ter lido, eh dessa forma que ele trabalha com multiprocessamento simetrico. Alguém tem alguma documentação de Squid Intanciado que aceite o modo transparente do IPFW? Parece que XFS ainda é experimental no FreeBSD. Ats, Ademir Peixoto - Original Message - From: Paulo Henrique [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Sunday, September 21, 2008 6:01 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 Já pensou e jogar tudo em uma unica partição, tipo coloca 20Gbs para sistema e afins, uns 30 Gbs para logs, caso o use, e o restante todo para o Cache montado sobre um unico ponto, a io pode ser baixa mais os disco podem estar na capacidade maxima, Outra coisa interessante é se caso tiver dois discos Iguais, poderia implementar RAID 1, pois aumentaria consideravelmente a performace, só que aconselho usar controladoras off-board, pois RAID por software pelo que já li o FreeBSD não encara bem, ainda bem. :D Tá funcionando bem mas mesmo com o cache zerado em poucos minutos começa a ter os famigerados: squidaio_queue_request: WARNING - Queue congestion 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. 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. 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? Ats, Ademir Peixoto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom fica ai a dica, até mais. -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que queremos, contudo não veremos mais o que não queremos. A real definição sobre deus se dá pelo fato do ser humano ser covarde o suficiente, colocando a culpa em algo que não existe para manter a conciência limpa. - 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 -- Atenciosamente Paulo Henrique. Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber A unica forma de todos sentirem-se bem é adotanto o Regime Socialista, não teremos tudo que
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] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [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
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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [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
Re: [FUG-BR] Cache squid de 1 Tb
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. Mais informações em: http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem 8. Examples 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
Re: [FUG-BR] Cache squid de 1 Tb
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 ;-) 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] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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
Re: [FUG-BR] Cache squid de 1 Tb
estes erros de no such file.. ocorrem quando voce mata o processo do squid... ele nao consegue fazer um dump do que esta na memoria para o disco e atualizar o swap.state ... entao ele ACHA que tem o arquivo.. no swap.state (indice) .. porem o arquivo nao existe em disco quanto a usar diskd ou aufs... acredito que aufs seja melhor... e uma sugestão é utilizar COSS para objetos menores que 1mb ... 2008/9/21 Victor [EMAIL PROTECTED]: 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 ;-) 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] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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
Re: [FUG-BR] Cache squid de 1 Tb
, 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 [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@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 [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 - 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 - 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
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 51224, 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
