[FUG-BR] Problema com ACPI?
Olás! Desde o FreeBSD 7 tenho um problema que faz quebrar a cabeça: minha máquina nunca desliga! Recentemente tentei usar o PC-BSD 8.1 e vejo que o problema aqui em casa persiste. Tanto no notebook quanto no netbook, indo pela linha de comando ou pela interface gráfica (qualquer), a máquina faz o shutdown dos scripts e processos em andamento mas o hardware continua ligado (luzes acesas, cooler rodando)... Isso é problema de ACPI? Alguém já passou por isso? Espero que possam me ajudar, enquanto isso vou usando o pinguim... Até + Zendrael www.zendrael.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema com ACPI?
On 11/06/10 09:16, Zendrael wrote: Olás! Desde o FreeBSD 7 tenho um problema que faz quebrar a cabeça: minha máquina nunca desliga! Recentemente tentei usar o PC-BSD 8.1 e vejo que o problema aqui em casa persiste. Tanto no notebook quanto no netbook, indo pela linha de comando ou pela interface gráfica (qualquer), a máquina faz o shutdown dos scripts e processos em andamento mas o hardware continua ligado (luzes acesas, cooler rodando)... Isso é problema de ACPI? Alguém já passou por isso? Sim é ACPI caso haja o problema, mas voce tenta desligar como? No FreeBSD tem que ser shutdown -p (power) diferente de Linux que se nao me engano um -h (halt) ja corta energia tambem. No FreeBSD tem que ser mais explicito pois em tese não é pra se desligar um FreeBSD nunca mesmo hehehe e um halt faz ele voltar com um ENTER. Espero que possam me ajudar, enquanto isso vou usando o pinguim... Poxa você vai de penguim gordo, monotono, passivo e desanimado, ao inves do capetinha socialmente ativo, simpatico de representacao lasciva, lubrica, como uma boa balada regada de boa musica, bebida, mulheres e amigos, simplesmente porque sua maquina não desliga? Mantenha ela ligada! hehehe Mas falando sério, seu e-mail não esclareceu se simplesmente não desliga ou se da algum pau no processo de shutdown. Tente com -p caso nao esteja fazendo, se não der certo nos informe ao menos as ultimas 3 linhas de texto o que aparece escrito. Ate. Até + Zendrael www.zendrael.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
Re: [FUG-BR] Problema com ACPI?
Olá! Ah, eu estava usando shutdown -h... e de fato, ao usar halt, teclo enter e ele volta a funcionar... sempre achei estranho... Vou dar um exemplo mais simples da situação: Estou no PC-BSD, vou ao menu K (o menu inical do KDE) e vou em Desligar... daí ele faz o que eu disse no mail anterior: fecha tudo, apaga monitor... mas os leds do notebook continuam acesos e o cooler do processador também funcionando! Se desligar o ACPI (no boot, por exemplo) fico sem monitorar a bateria e qualquer toque no botão liga/desliga físico... bom... já imagina o que acontece com o hd tendo energia cortada toda hora... O problema é só esse. Meio besta eu sei, mas não consegui resolver ainda... Boa essa do pinguim gordo Patrick! hahaha mas eu uso o TinycoreLinux que é um pinguim mais magrinho! Hahahahah Tem alguma outra idéia? Obrigado por enquanto Zendrael www.zendrael.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema com ACPI?
On 11/06/10 12:15, Zendrael wrote: Olá! Ah, eu estava usando shutdown -h... e de fato, ao usar halt, tecloenter e ele volta a funcionar... sempre achei estranho... Vou dar um exemplo mais simples da situação: Estou no PC-BSD, vou ao menu K (o menu inical do KDE) e vou em Desligar... daí ele faz o que eu disse no mail anterior: fecha tudo, apaga monitor... mas os leds do notebook continuam acesos e o cooler do processador também funcionando! Se desligar o ACPI (no boot, por exemplo) fico sem monitorar a bateria e qualquer toque no botão liga/desliga físico... bom... já imagina o que acontece com o hd tendo energia cortada toda hora... O problema é só esse. Meio besta eu sei, mas não consegui resolver ainda... Boa essa do pinguim gordo Patrick! hahaha mas eu uso o TinycoreLinux que é um pinguim mais magrinho! Hahahahah Tem alguma outra idéia? Tentou com -p? shutdown -p now Obrigado por enquanto Zendrael www.zendrael.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
Re: [FUG-BR] newfs para disco de 1TB
Patrick, Neste caso, quando você comentou sobre stress no disco, quais aplicativos recomenda para realizar este teste? Marcus Lahr Supervisor Setor de Informática - IEL Em 04/11/2010 10:14, Patrick Tracanelli escreveu: Em 04/11/2010, às 10:03, Renato Frederick escreveu: Chute aqui, desculpa se for bobagem: Não teria nada a ver com a BIOS não? HD muito grande em PC relativamente velho? lembro que em 1900 e bolinha tinha BIOS que não achava HD grande e dava mensagens exóticas assim :) Pois é, pode ser sim, nesse caso limite da controladora ou ainda o cabo, ja que é um erro de CRC de acordo com os logs. ICRC shall be set to one if an interface CRC error has occurred during an Ultra DMA data transfer. The content of this bit is not applicable for Multiword DMA transfers. Uma outra opção de teste é a Renata desabilitar udma. Nesse caso Renata boote com: hw.ata.ata_dma=0 (via loader prompt ou no loader.conf) E tente o newfs. Se funcionar é cabo ou conjunto. Se der problema certamente é disco mesmo. []s -Mensagem Original- From: Patrick Tracanelli Sent: Thursday, November 04, 2010 9:22 AM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] newfs para disco de 1TB Em 04/11/2010, às 09:18, Renata Dias escreveu: Patrick, Particionei o disco utilizando apenas 100GB e não obtive erro. Posso concluir então que o erro está em alguns setores do disco e não na controladora ou cabo? Os erros são sim em posições mais altas da geometria de acordo com os logs, mas se quiser tirar a limpo mesmo use o stress rodando simultaneamente operações de read e write nesse disco, com esses 100GB iniciais. Obrigada. Em 4 de novembro de 2010 09:09, Patrick Tracanelli eks...@freebsdbrasil.com.br escreveu: Em 04/11/2010, às 09:04, Renata Dias escreveu: Caros, Adicionei ao servidor FreeBSD 7.2-STABLE um disco de 1TB, porém na hora de criar a partição recebo um erro inesperado. DISCO: ad7: 953869MBWDC WD10EARS-00Y5B1 80.00A80 at ata3-slave SATA150 ERRO: ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=196832319 ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=234467519 ad7: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=290920319 ad7: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=290920319 Preciso atualizar o FreeeBSD pra 8.0? Alterar alguma opção na BIOS? Não Renata, o problema é fisico mesmo. Ou disco ou conjunto. Felizmente o FreeBSD testa os superblocks com um lookup direto. Se fosse Windows ou Linux a formatação poderia passar e depois começar travar ou perder dados em produção. Se o disco for novo cheque cabos, controladora... Obrigada; -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - 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 -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - 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
[FUG-BR] Squid + Delay Pools
/Pessoal, estou utilizando delay pools no meu squid, mas minha duvida é a seguinte, até mesmos os arquivos que estão no cache (TCP_HIT) eles também sao limitados? na verdade preciso limitar somente o que é TCP_MISS (que o cache precisa baixar da web). Obrigado / - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Harware para Cache
Alguém recomenda algum hardware ou solução para cache profissional para provedor ? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Harware para Cache
24G + 6 Hds (sas ou sata 7200) + 2 processadores sixcore acima de 3Ghz lusca + thundercache Em 06/11/2010 17:55, sergio escreveu: Alguém recomenda algum hardware ou solução para cache profissional para provedor ? - 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
Re: [FUG-BR] Harware para Cache
Em 6 de novembro de 2010 21:42, Ciro Cardoso de Meneses cir...@sergipenet.com.br escreveu: 24G + 6 Hds (sas ou sata 7200) + 2 processadores sixcore acima de 3Ghz lusca + thundercache Em 06/11/2010 17:55, sergio escreveu: Alguém recomenda algum hardware ou solução para cache profissional para provedor ? - 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 Acrescentaria: os discos sas ou sata em com ZFS + 1 disco SSD SATA para cache do ZFS - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] newfs para disco de 1TB
On 06/11/2010 13:14, Marcus Lahr wrote: Patrick, Neste caso, quando você comentou sobre stress no disco, quais aplicativos recomenda para realizar este teste? Marcus Lahr Supervisor Setor de Informática - IEL Fala Lahr. Marcus, o aplicativo stress mesmo. Além do dd e cat. Em 04/11/2010 10:14, Patrick Tracanelli escreveu: Em 04/11/2010, às 10:03, Renato Frederick escreveu: Chute aqui, desculpa se for bobagem: Não teria nada a ver com a BIOS não? HD muito grande em PC relativamente velho? lembro que em 1900 e bolinha tinha BIOS que não achava HD grande e dava mensagens exóticas assim :) Pois é, pode ser sim, nesse caso limite da controladora ou ainda o cabo, ja que é um erro de CRC de acordo com os logs. ICRC shall be set to one if an interface CRC error has occurred during an Ultra DMA data transfer. The content of this bit is not applicable for Multiword DMA transfers. Uma outra opção de teste é a Renata desabilitar udma. Nesse caso Renata boote com: hw.ata.ata_dma=0 (via loader prompt ou no loader.conf) E tente o newfs. Se funcionar é cabo ou conjunto. Se der problema certamente é disco mesmo. []s -Mensagem Original- From: Patrick Tracanelli Sent: Thursday, November 04, 2010 9:22 AM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] newfs para disco de 1TB Em 04/11/2010, às 09:18, Renata Dias escreveu: Patrick, Particionei o disco utilizando apenas 100GB e não obtive erro. Posso concluir então que o erro está em alguns setores do disco e não na controladora ou cabo? Os erros são sim em posições mais altas da geometria de acordo com os logs, mas se quiser tirar a limpo mesmo use o stress rodando simultaneamente operações de read e write nesse disco, com esses 100GB iniciais. Obrigada. Em 4 de novembro de 2010 09:09, Patrick Tracanelli eks...@freebsdbrasil.com.br escreveu: Em 04/11/2010, às 09:04, Renata Dias escreveu: Caros, Adicionei ao servidor FreeBSD 7.2-STABLE um disco de 1TB, porém na hora de criar a partição recebo um erro inesperado. DISCO: ad7: 953869MBWDC WD10EARS-00Y5B1 80.00A80 at ata3-slave SATA150 ERRO: ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=196832319 ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=234467519 ad7: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=290920319 ad7: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=290920319 Preciso atualizar o FreeeBSD pra 8.0? Alterar alguma opção na BIOS? Não Renata, o problema é fisico mesmo. Ou disco ou conjunto. Felizmente o FreeBSD testa os superblocks com um lookup direto. Se fosse Windows ou Linux a formatação poderia passar e depois começar travar ou perder dados em produção. Se o disco for novo cheque cabos, controladora... Obrigada; -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - 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 -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - 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
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
Re: [FUG-BR] Harware para Cache
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. 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. 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. É 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. -Original Message- From: eks...@freebsdbrasil.com.br Sent: Sun, 07 Nov 2010 03:30:33 -0200 To: freebsd@fug.com.br 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
