[FUGSPBR] Squid e Tunning...

Sáb Dez 15 07:06:13 BRST 2001

 Booo!
 Olá Alessandro :)

> "Alessandro M. S. Sant'Anna" wrote:
> 
> Pessoal,
> 
> Gostaria de uma opinião sobre o Squid. Estou testando o Squid
> 2.4-STABLE3 em uma máquina pouco comum:
> 
> Digital ALPHASERVER 2100A, 512Mb RAM
> 1 x 4Gb SCSI (Sistema)
> 7 x 2.1Gb SCSI (Squid - RAID 0)
> 
> O sistema é o FreeBSD 4.4-RELEASE, atualizado via cvsup hoje e com o
> kernel recompilado, virando assim um kernel 4.4-STABLE.
> Um build world será feito amanhã. A única modificação no kernel foi a
> alteração de MAXUSERS de 32 para 256. Não compilei o Squid com o diskd
> ainda.
> 
> Estava querendo dar um tunning em parametros de kernel e quem sabe em
> algo para melhorar o Squid. Os filesystems estão todos com
> soft-updates habilitados.
> 
> Muitos podem achar estranho a escolha desta ALPHA porém tenho algumas
> para brincar e este "frigobar" que escolhi pode atender para o meu
> propósito.
> Sei que aqui existem algumas pessoas que rodam o FreeBSD em ALPHA, por
> isto quero algumas opiniões.
> 

 Seguinte, a nível de kernel você pode configurar algumas coisinhas pra dar um tuning, mas as principais não precisa de recompilação. Por exemplo, pra boot-time você pode baixar o SCSI_DELAY, tem IDE_DELAY também. 

 As principais alterações que você pode fazer no kernel é alterar o MAXUSERS e o NMBCLUSTERS. No 4.4 você não precisa mais mexer no kernel pra alterar esses valores. Aliás até precisa, mas como diria o tzk você tem o kernel na ponta dos dedos com o sysctl, então vamo aproveita:

root em dashy~# sysctl -a | grep -i mbc
kern.ipc.nmbclusters: 1024
root em dashy~# sysctl -a | grep -i
kern.maxusers: 32

  O maxusers a gente sabe, cai naquela continha de desempenho, se eu não me engano 1024*8198*<max users>, mas você também pode alterar o maxfiles. Mas bom, vejamos o seguinte, pra Squid creio que o fator principal seja acesso a disco (óbvio) e depois espaço do buffer pra enviar/receber pacotes.

  Já que você já aplicou softupdates, ótimo, se você estiver montando o servidor a partir do zero, compensa pensar em alguns valores pra o newfs do /usr/local/squid/ caso seja (recomendado) uma particao distinta, ja que o cache/ sob esse diretorio vai conter arquivos com tamanhos particulares, então, talvez você queira mudar os blocos, inodes etc. "man tuning" da otimas dicas em relação a valores pra se alterar os file system.

 Fora isso, outro fator importante é o size dos pacotes que vão estar sendo armazenados em buffer pra enviar e receber. Essa discussão anda muito ativa na hackers em freebsd.org, e o mestre Matt Dillon anda dando uns showzinhos la... olha só por default o FreeBSD define 16k de buffer pra envio e recebimento de pacotes tcp. 

 Esse valor na grande maioria das vezes é o suficiente pra maioria das formas de se utilizar o FreeBSD, mas quando se trata de HTTP FTP (e as vezes email quando a demanda eh muita) esses valores devem ser alterados. Provavelmente vai se tornar padrão 32k pra espaço de recebimento no freebsd 4.5 como disse o proprio Dillon:
 So I think we can safely  increase the dfeault net.inet.tcp.recvspace from 16384 to 32768 immediately.

 Então altere essas variáveis:

- sysctl -w net.inet.tcp.sendspace=32768 
- sysctl -w net.inet.tcp.recvspace=32768 

 Algumas pessoas que eu ando conversando tão subindo esses valores direto pra 64K, junto do UDP...

 net.inet.tcp.sendspace=65535
 net.inet.tcp.recvspace=65535
 net.inet.udp.recvspace=65535

 Mas pra você decidir entre fazer ou não fazer isso é preciso algumas considerações. Primeiro, de cara aumentar consideravelmente o nmbclusters no kernel. Pq? Seguinte, nmbclusters define o tanto de espaço que o sistema vai alocar em memória pra trabalhar o stack tcp/ip do FreeBSD. cada cluster vale mais ou menos 2k, então pode assumir por exemplo que o padrão 1024 define 2MB de buffer em memória pro freebsd trabalhar o networking.

 Ou seja, se você tiver mais memória, pode se sentir a vontade pra definir o nmbclusters do tamanho que você achar conveniente pro sistema. Ou pode calcular quanto voce vai precisar pra não colocar na fila antes de ir pro mbuff por exemplo, o padrao de envio e recebimento eh 16k entao multiplique 32k pelo numero de conexoes simultaneas que voce espera, e vai ter o tanto de memoria que voce vai precisar ter definido pro stack tcp/ip pra que todas as requisicoes sejam atendidas imediatamente. Vai ver que nao eh pouca memoria, então ao invez de 16k refaça as contas com 32 e posteriormente 64k... vai ver que não é brincadeira querer dar tuning hehehe mas é puta divertido :) Lembre-se de não deixar seu sistema operacional sem memória até mesmo pro kernel, pq pior do que serviços caindo por falta de memória é o sistema inteiro não ter onde rodar, hehehe...

 O Dillon ta escrevendo recentemente uma forma de alocar dinâmicamente as janelas do stack tcp/ip no mbuff de acordo com as requisições e das definições do send space e receive space, ou seja, uma forma do sistema definir seu nmbclusters automaticamente. Ta em testes no FreeBSD 5 e se dermos sorte fica legal até o 4.5. Vai ser show... 

 Bom, voltando ao raciocínio, eu disse que 64 é o limite máximo pra pensar em alterar pq, é o máximo que você vai poder utilizar em redes normais, depois disso só vai precisar pra redes de alto desempenho. Aí você tem que considerar outras consequências, por exemplo, pra se usar o stack tcp/ip funcionando assim você precisa garantir que o seu FreeBSD tenha suporte a RFC1323 e a RFC2018. Uma não pode ser definida sem a outra. Se você fizer uma consultinha básica pode querer entender essas definiçoes:

Network Working Group        
Request for Comments: 1323   
Obsoletes: RFC 1072, RFC 1185

                  TCP Extensions for High Performance

 Em

http://www.ietf.org/rfc/rfc1323.txt?number=1323

 Então pra garantir o seu FreeBSD de acordo com essas normas:

   net.inet.tcp.rfc1323=1

 Minha opinião ainda é definir tudo pra 32k hehee :)

 Esse email ta ficando meio grande demais, mas vamos tentar resumir, define:

   vfs.vmiodirenable=1

 Vamos fundamentar:

 The vfs.vmiodirenable sysctl defaults to 0 (off) (though soon it will
     default to 1) and may be set to 0 (off) or 1 (on).  This parameter con-
     trols how directories are cached by the system.  Most directories are
     small and use but a single fragment (typically 1K) in the filesystem and
     even less (typically 512 bytes) in the buffer cache.  However, when oper-
     ating in the default mode the buffer cache will only cache a fixed number
     of directories even if you have a huge amount of memory.  Turning on this
     sysctl allows the buffer cache to use the VM Page Cache to cache the
     directories.  The advantage is that all of memory is now available for
     caching directories.  The disadvantage is that the minimum in-core memory
     used to cache a directory is the physical page size (typically 4K) rather
     than 512 bytes.  We recommend turning this option on if you are running
     any services which manipulate large numbers of files.  Such services can
     include web caches, large mail systems, and news systems.  Turning on
     this option will generally not reduce performance even with the wasted
     memory but you should experiment to find out.

 Ou seja: é bom pro seu caso eheheh

 E lembre-se: diskd :)

vo da um tuning na minha cama agora, ciao

Paz Profunda,
[]'z ./patrick

----
+---------------------------------------------------------------+---------+
|              Patrick Leandro Tracanelli do Carmo              | (   )   |
|             RPGw/IRC Nick -- Eksffa Shyranui Kapwam           | (O_O)   |
|        Eeviac host FreeBSD 5.0-CURRENT Dual SMP @444Mhz       | \`-'/  w|
| 4o Ciclo (Fatorial) - Faculdade de Tecnologia de Taquaritinga | (   )__||
|===============================================================| /m`m\   |
|       eksffa em fatectq.com.br  -  Fone: (0xx55) 9972-9465       | FreeBSD |
+---------------------------------------------------------------+---------+
|Administrador de Redes e Sistemas | BSD Unix, System V & Open Source Syst|
+---------------------------------------------------------------+---------+
Long live Hanin Elias, Kim Deal!!!
~
~
----
Para sair da lista envie um e-mail para majordomo em fugspbr.org
com as palavras "unsubscribe fugspbr" no corpo da mensagem.