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
