Obrigado Gustavo pela sua resposta! Quanto a quantidade de cache que está na configuração do squid, eu coloquei 256 MB mas estou inclinado a mudar para 10 GB o que o senhor acha? O Mysar também traz relatórios em ambiente web? Quanto a tunar eu tenho algumas dúvidas o que vc quis dizer com "ver a quantidade do cache em memória e em disco"? Com o perdão da minha ignorância como vejo isso? E quanto ao "escalonador de objetos" O que seria isto e como faço isto? Desde já agradeço a sua atenção.
Moksha Em 17 de novembro de 2010 13:52, Leonardo Carneiro <[email protected]>escreveu: > Recomendo o uso do MySar ao inves do sarg. Ele é mais eficiente em > termos de uso de máquina que o Sarg. Acho tb fundamental vc tunar o > seu proxy!!! Vc tem mtos usuários. > > Para começar, acho mto importante que vc veja quantidade de cache em > memória e em disco, tamanho dos objetos em memória e em disco, > escalonador de objetos e ordernar corretamente as ACLs para maior > eficiencia. > > 2010/11/17 Gustavo Soares [SLot] <[email protected]>: > > Uma maneira que utilizo muito é a instalação dos servidores utilizando as > > imagens do kmuto[1], um devel do debian. > > > > [1] http://kmuto.jp/debian/d-i/ > > > > > > > > Em 17-11-2010 12:02, Luiz Felipe escreveu: > >> > >> Veja só: o comando lshw mostra as configurações do hardware (memoria, > >> versão, firmware etc). Isso não quer dizer q o seu software esteja > adaptado > >> pra isso. > >> > >> Tente as duas outras dicas. Use a recompilação do kernel só em ultimo > >> caso. > >> > >> E eu não conheço o Ubunto Server. Essa é uma lista de Debian ;) > >> > >> Att, > >> Luiz Felipe de Souza Gomes. > >> > >> > >> > >> Moksha Tux escreveu: > >>> > >>> Muito obrigado Luiz Felipe pelas sugestões, esqueci de mencionar que o > >>> meu proxy é autenticado sim e faz autenticação para esses 2500 usuários > sim. > >>> A idéia de aumentar o cache eu achei interessante, quanto ao kernel, > bem, > >>> quando eu executo o comando lshw o sumário da CPU que eu vejo é > exatamente > >>> as do fabricante, mas agora, se estiver genérico eu teria que compilar > o > >>> kernel? Que lastima eu nunca tive sorte com compilações de kernel. O > fato de > >>> eu ter escolhido o Ubuntu server ao invés do Debian também teria alguma > >>> coisa a ver? O Debian stable não tinha a maioria dos dirvers do > hardware do > >>> servidor. Abraços, > >>> > >>> Moksha > >>> > >>> Em 17 de novembro de 2010 09:17, Luiz Felipe <[email protected] > >>> <mailto:[email protected]>> escreveu: > >>> > >>> Moksha Tux escreveu: > >>> > >>> Boa noite queridos amigos da lista! > >>> > >>> Gostaria de tirar uma dúvida com vcs... Recentemente levantei > >>> um novo servidor proxy aqui na empresa, eu considero o > >>> servidor bem parrudo é um IBM da série *"system x3650"* com > >>> 1.5 TG em RIAD 5, 4 GB de RAM e uma CPU quad core xeon, ele > >>> atende uma rede de + ou - 2600 hosts e cerca de 2500 usuários. > >>> O ponto é que pela manhã e início da tarde o que seria o > >>> horário de pico o uso da CPU oscila entre 30% a 75% o que eu > >>> acho muito para um servidor deste porte e quando eu rodo o > >>> sarg chega a 100% de uso de CPU mole e o SO é o novo Ubuntu > >>> server 10.10. O que vcs acham? Essa porcentagem de uso da CPU > >>> é normal para a demanda? seria muito para a demanda? O server > >>> não é tão parrudo assim? Deveria eu providenciar um server > >>> mais parrudo? O que vcs acham? Grato, > >>> > >>> Moksha > >>> > >>> Em termos gerais, atender 2600 hosts e 2500 usuários é muita > >>> coisa. Vc usa autenticação? Se sim, mais um motivo pra ele ficar > >>> topado. Aí o uso do SARG eh proporcional a esse número de > >>> usuários/hosts, pq ele vai fazer o relatório em cima disso. > >>> > >>> No seu caso, eu recomendaria 3 coisas: > >>> 1 - Aumentar o cache do squid. O padrão do squid é 80MB, se eu não > >>> me engano. Numa rede do tamanho da sua, isso vai embora rapidinho. > >>> Aumentar o cache pra alguns gigas incrementaria a performance > >>> significativamente; > >>> > >>> 2 - Agendar o SARG para rodar em um horário que não seja de pico; > >>> > >>> 3 - Em ultimo caso, se você quiser se aventurar, confira se o > >>> kernel está adaptado pra esse tipo do seu processador. Talvez ele > >>> esteja sendo mais genérico e não usando todas as capacidades da > >>> sua CPU. > >>> > >>> Era isso. > >>> > >>> Att, > >>> Luiz Felipe. > >>> > >> > >> > >> Missao Embrapa Meio-Norte > >> > >> Viabilizar solucoes de pesquisa, desenvolvimento e inovacao para > >> sustentabilidade da agricultura da regiao Meio-Norte do Brasil, em > beneficio > >> da sociedade. > >> > >> Aviso de confidencialidade > >> Esta mensagem da Empresa Brasileira de Pesquisa Agropecuaria > (Embrapa), > >> empresa publica federal regida pelo disposto na Lei Federal no. 5.851, > >> de > >> 7 de dezembro de 1972, eh enviada exclusivamente a seu destinatario e > >> pode > >> conter informacoes confidenciais, protegidas por sigilo profissional. > >> Sua > >> utilizacao desautorizada eh ilegal e sujeita o infrator as penas da > lei. > >> Se > >> voce a recebeu indevidamente, queira, por gentileza, reenvia-la ao > >> emitente, esclarecendo o equivoco. > >> > >> Confidentiality note > >> > >> This message from Empresa Brasileira de Pesquisa Agropecuaria > >> (Embrapa), > >> a government company established under Brazilian law (5.851/72), is > >> directed exclusively to its addressee and may contain confidential > >> data, > >> protected under professional secrecy rules. Its unauthorized use is > >> illegal and may > >> subject the transgressor to the law's penalties. If you are not the > >> addressee, please send it back, elucidating the failure. > >> > >> > > > > > > -- > > ------------------- > > SLot > > UIN: 19596909 > > Linux User: 124842 > > Jabber: [email protected] > > Emails: [email protected] | [email protected] > > > > > > -- > > To UNSUBSCRIBE, email to [email protected] > > with a subject of "unsubscribe". Trouble? Contact > > [email protected] > > Archive: http://lists.debian.org/[email protected] > > > > > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: > http://lists.debian.org/[email protected] > >
