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: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 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 > > __________ NOD32 3458 (20080921) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > __________ NOD32 3458 (20080921) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- 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
