On 07/11/2010 03:58, sergio wrote: > Patrick, muito obrigado pelas informações, neste caso de usar o Lusca com > Thunder Cache Pro com FreeBSD, estou pensando se vale a pena fazer o > redirecionamento para porta http apartir de um roteador Mikrotik ou se devo > usar o FreeBSD como roteador/cache.
Da na mesma. Ambas topologias são igualmente funcionais. Em poucos casos vi o MK sobrecarregando com as regras de mangle. Mas pq ja estava sobrecarregado mesmo hehe. So piorou. > A última vez que tentei usar o o Cache com um Link de 300Mbps, um Mikrotik > redirecionando o tráfego http para uma máquina com FreeBSD + Lusca + Thunder > Cache tive problema com I/O de disco (Disco SAS), acabei não focando mais > nisso, mas estou com vontade de voltar. Pois é. Certamente o problema de I/O de disco aconteceria em qualquer topologia. Mal dimensionamento :( > Fiz testes de download em um circuito da Intelig com 100Mbps de banda livre e > tive uma taxa de transferência variando entre 20Mbps e 38Mbps, já em um > circuito da GVT com 50Mbps tive uma taxa entre 40Mbps e 50Mbps. Não entendi. Taxas de economia? > É notável que a GVT tem muitos Cache, notamos que os downloads pela GVT > geralmente são mais rápidos, atingem taxas de transferência altas mais > rapidamente etc. O cache da GVT não é transparente. É baseado em rewrite. Dai a importância de usar o thunder. Tem plugins pra GVT que sem eles você perde o cache que a GVT faz. > > >> -----Original Message----- >> From: [email protected] >> Sent: Sun, 07 Nov 2010 03:30:33 -0200 >> To: [email protected] >> Subject: Re: [FUG-BR] Harware para Cache >> >> On 06/11/2010 18:55, sergio wrote: >>> Alguém recomenda algum hardware ou solução para cache profissional para >>> provedor ? >> >> Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro. >> >> Quanto a hardware depende de muitos fatores. O principal é quantos >> usuários você vai pendurar atrás desse proxy. >> >> O mais importante gargalo a ser evitado é o de I/O de disco. Considere >> que de forma geral você tem dois limites em um disco. O mais óbvio, >> espaço. O menos, número de operações por segundo (TPS). Um disco >> SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de >> acordo com as taxas de operações de escrita e leitura. Isso vai resultar >> numa taxa de 80MB/s a 120MB/s. >> >> Em um cache já rodando há alguns dias, as operações de disco são em sua >> maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados >> em disco, maior a taxa de operações de leitura. Óbvio. >> >> Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com >> cerca de 550, 600GB provavelmente você vai bater no limite de TPS do >> disco. Dessa forma imagine o que acontece se você usar um disco de 1TB >> por exemplo, mas com performance SATA2/7200rpm. >> >> Ou seja discos muito grandes são excelente pra backup. Pra cache vão >> gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2, >> discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um >> pouco pra cima, mas já passa do ponto de segurança. >> >> Outra consideração é ser seletivo no que cachear. Não cachear qualquer >> coisa e em especial não cachear arquivos muito pequenos. Arquivos >> pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso >> dos discos é mais rápido busca-los na internet do que no disco. >> Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no >> Thunder. >> >> O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória >> em sua maior taxa barramento. Mas a velocidade nesse caso é menos >> relevante que a quantidade. A regra é bem simples: quanto mais memória >> melhor! >> >> Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o >> tamanho do seu cache_dir com base em quanto você tem de memória RAM. >> >> Note que a ordem é diferente do que todos pensam. Você não configura o >> tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o >> primeiro erro, e o principal fator de fracasso. Você define quanto usar >> de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que >> envolve quanto de RAM você tem, quanto será usado por MB de cache_dir, >> quanto você quer usar pro cache_mem e quanto seu sistema operacional vai >> consumir. >> >> Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de >> memória o thunder vai consumir. E isso vai variar com a sua expectativa >> máxima de threads. >> >> Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso. >> >> Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar >> seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é >> bom evitar). Mas lembre-se que cache_mem não é quanto de memória o >> Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects. >> >> De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo, >> em tese não aproveitando a meória pros Hot Objects, no FreeBSD e graças >> ao UFS_DIRHASH e também ao cache de dados do sistema de arquivo que o >> FreeBSD vai fazer sozinho por padrão (kernel GENERIC), você vai ter >> compensação de I/O de disco com esse cache de memória. Nesse caso, com >> bastante RAM, da até pra fugir desses limites de tamanho de disco, pois >> quanto mais RAM pro FreeBSD, menos TPS consumidos nos seus discos. >> >> Ou seja quanto você puder investir em RAM vai orientar todas as outras >> suas decisões. >> >> Voltando aos discos, tente ter um ou dois discos pro sistema, isolados >> (se for 2, em RAID-1 com gmirror), e os demais discos em RAID-0. Faça >> RAID-0 com Geom Stripe. >> >> Faça RAID-0 com Geom Stripe. >> >> Sei que repeti. É pra dar ênfase ;-) Eu testei muito RAID-0 com >> controladoras típicas no percado tupiniquim, em especial as P4X vendidas >> com servidores HP e PERC vendidas com DELL. O RAID-0 delas não chega nem >> perto em performance do Gstripe. Fuja como o diabo corre da cruz, de >> RAID de BIOS. RAID de BIOS são esses RAID... de BIOS sabe? Que vem na >> placa mãe. Os linuxers chamam de FakeRAID, eu chamo de qualquer RAID que >> o "atacontrol" controle e o FreeBSD reconheça como ar(4). Nem considere >> usar! Você tem Geom Stripe ;-) >> >> RAID-0 por hardware que substituiria o Gstripe só se for com >> controladora LSI Logic ou QLogic. Essas podem dar mais performance que o >> Gstripe. De todas que tive o prazer de testar, só elas. >> >> Dê uma lida na man page do stripe pra considerar tuning através das >> sysctl documentadas. Se você conseguir diminuir a relação de espaço em >> disco por TPS (por exemplo, discos SAS são em geral mais caros e >> normalmente você vai investir em discos SAS de tamanho abaixo do que >> eles poderiam ser, especialmente pq SAS de 1TB ainda são bem caros). >> Nesse caso diminua o stripesize na hora de fazer o gstripe. >> >> Se quiser arriscar discos maiores do que os que eu mencionei, por >> exemplo, usar discos de 750GB SATA2/7200rpm, aumente o stripesize pra >> tentar aliviar o TPS. O quanto aumentar vai depender do número de >> discos. Não tem uma formula pra isso, infelizmente. >> >> Não use discos SATA de 5400rpm, a não ser pro sistema. Senão você vai >> perder a referência de taxa de I/O em TPS com taxa de transferência em >> bytes. >> >> Quanto a placa mãe o fundamental é que ela tenha canais independentes >> pros discos. Seja SAS, SATA, SSD... não adianta nada ter discos que dão >> 140MB/s em um disco mas dão 70MB/s quando 2 estão em uso simultâneamente. >> >> Da mesma forma, claro, corra de discos slave. Cuidado porque o conceito >> de slave é especialmente deturpado com discos SATA/SAS em relação aos >> PATA. Você pode achar que são todos master mas estão dividindo canal. >> >> Eu gosto de placas mãe supermicro pra isso. Mas claro Intel Server e >> Gigabyte Server vão atender. >> >> Quanto a CPU, com Lusca você consegue pelo menos 400Mbit/s atendendo >> alguns milhares de clientes, com um Quad Core de 2.0Ghz. Acima disso >> talvez você precise rodar multiplos lusca. >> >> Evite usar regex, senão você vai encontrar limite por voltados 30Mbit/s. >> Infelizmente o processamento de regex do Lusca ainda é uma das heranças >> malditas do Squid: ruim e pesado. E monothread o que é ainda pior. No >> Lusca o Chadd conseguiu[3] mitigar um problema de exaustão de fila >> quando você usa o recurso de external_acl_type pra processas as regex. >> Então use-o! >> >> Acho que com base nessas observações você vai conseguir dimensionar bem >> seu hardware :-) >> >> [1]http://wiki.squid-cache.org/SquidFaq/SquidMemory#How_much_memory_do_I_need_in_my_Squid_server.3F >> [2]http://www.thundercache.com.br/faq-leia.html >> [3]http://code.google.com/p/lusca-cache/issues/detail?id=120 >> >> -- >> Patrick Tracanelli >> FreeBSD Brasil LTDA >> http://www.freebsdbrasil.com.br >> ------------------------- >> 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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
