> On 19/05/2015, at 17:51, Marcelo Gondim <gon...@bsdinfo.com.br> wrote: > > On 19-05-2015 14:04, Patrick Tracanelli wrote: >>> On 18/05/2015, at 20:20, Samuel . <lista.freebsd.bra...@outlook.com> wrote: >>> >>> Mais uma dúvida, o SSD que tenho aqui é um Kingston V300, será que aguenta >>> o rojão? >> Vixi… eu poderia dizer que é o famoso gato por lebre hehehe. Mas é pior. :( >> É um grande e vermelho piscante NAO USE PRA SERVIDOR! >> >> Vamos aos fatos: >> >> O modelo era bom, mas a Kingston mudou o chip da NAND no meio do jogo sem >> mudar o modelo do produto (DELL fazendo escola) e o que era bom ficou >> regular mas a um custo mais acessível. Ainda assim é melhor que um HDD de >> 7200rpm mas não será a experiência de um SSD. Se for numa porta SATA2 vai >> tirar todo proveito da porta mas se for SATA3 o SSD vai patinar antes da >> interface em termos de performance. >> >> Enfim melhor que um HDD mas não é lá essas coisas de SSD. Além disso é MLC e >> não SLC (exatamente pra ser mais barato) então espere aquele cenário da vida >> útil em 80% do esperado pra um HDD, enquanto um SLC teria mais performance e >> mais vida útil. >> >> Mas olhe pro lado bom, é um SSD. E olhe o lado bom 2, já tem tem um recurso >> da Kingston chamado SSDNow VPlus que faz um Wear Leveling muito bom >> automaticamente, eles chamam de Wear Range Delta e da pra monitorar até via >> S.M.A.R.T. os indicadores de wear leveling (rescrita do mesmo arquivo >> ocupando regiões diferentes da memória, de forma eficiente) o que garante >> que realmente a vida útil vai pra 80% ou mais dos ciclos de escrita >> esperados em um HDD. >> >> Agora a luz vermelha e pq vc n deve usar em um servidor: esse SSD tem um >> outro recurso da Kingston chamado Data Life Protection (DLP) e esse DLP >> trava o disco pra operações de escrita paralela após um súbito aumento na >> taxa de escritas paralelas do disco. Segundo a Kingston essa proteção DLP é >> pra evitar virus e outros perfis de uso que não batem com o esperado pra uma >> estação de trabalho, e bla bla bla, bale ble ble que resulta em uma proteção >> anti paralelismo. >> >> Basicamente o SSD espera poucas operações simultâneas de alto desempenho e >> não várias simultâneas. Ao entrar em modo DLP o paralelismo cai e junto cai >> a performance. Ou seja em ambiente servidor voce esta falando de >> multi-usuário portanto está falando de paralelismo portanto está falando de >> um cenário que provavelmente vai ativar a proteção DLP e degradar a >> performance. >> >> Mais detalhes em: >> >> http://ssdendurancetest.com/ssd-endurance-test-report/Kingston-SSDNow-V300-60 >> >> Resumindo: esse SSD não é pra server. > Opa Patrick, > > E o Samsung 850 EVO? Esse presta pra server?
Mano eu uso! hehehe Ele não tem as travas DLP nem nada parecido como tem o V300 Mas olha que tem 2 modelos, o 850 EVO e 850 EVO Pro, o segundo tem TurboWrite SLC e o primeiro li em algum lugar que alguns lotes também tem TurboWrite SLC hahaha mas é cabeça de bacalhau, nunca vi. Os 850 EVO não Pro que vi eram todos MLC. Mas não vejo problemas pra server na versão MLC. Claro o Pro seria mais recomendado… Pessoalmente uso, mas pra comprar pra server compro: - Intel Speed Demon SSD (do capeta! ainda ganha adesivinho do fogo do inferno kkkk) - Crucial MX200 - Corsair GTX (so que muito caro) E pras minhas maquinas pessoais sempre Crucial… creio que tenha o melhor custo/beneficio dos 3. Também tive boas experiencias em performance e numero de TPS paralela com o OCZ um tal de OCZ Vector mas não conheço muito a marca e é minha primeira experiência, por enquanto rodando desde Setembro em produção, sem sinais de problema mas só o tempo dirá se continua de boa. Por enquanto por mim ta aprovado também, se morrer eu aviso hehehe ;) bom custo/beneficio tbm... > > []'s > >> >>> >>> >>> >>> >>> >>> >>> Att, >>> Samuel . >>> >>>> From: lista.freebsd.bra...@outlook.com >>>> To: freebsd@fug.com.br >>>> Date: Mon, 18 May 2015 20:15:08 -0300 >>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1 >>>> >>>> Eita, quanta informação preciosa! >>>> Que dilema! rs >>>> O buraco do tutu é bem mais em baixo que eu imaginava.. >>>> Agora que lembrei, esse servidor irá virtualizar um windows pra gravação >>>> de câmeras (agora ferrou!). >>>> Confesso que estou com dó de usar esse SSD, por mim colocaria ele dentro >>>> de compartimento de vidro em cima da minha mesa (risos...) >>>> Mas vou fazer isso que você disse Patrick! >>>> Muitíssimo obrigado! >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Att, >>>> Samuel . >>>> >>>>> From: eks...@freebsdbrasil.com.br >>>>> Date: Mon, 18 May 2015 19:58:45 -0300 >>>>> To: freebsd@fug.com.br >>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1 >>>>> >>>>> >>>>>> On 18/05/2015, at 19:18, Samuel . <lista.freebsd.bra...@outlook.com> >>>>>> wrote: >>>>>> >>>>>> Patrick, todos sabem, você é o cara! Muitíssimo obrigado pelo comentário. >>>>> Hahaha não sou não, só me coloquei na situação de usuário do seu servidor >>>>> :D >>>>> >>>>>> Com base nessas informações, vou reformular totalmente o cenário aqui. >>>>>> Não abusando da sua boa vontade. Mas eu tenho um SSD de 120 GB e um HDD >>>>>> de 250, queria poder usar os dois para ter espaço sobrando. >>>>>> Qual layout de particionamento você recomenda? >>>>> Minha recomendação principal, o que eu faria, foi oq mencionei em uns >>>>> e-mails pra trás, levantar quais estruturas existem mais operações e >>>>> colocar esses pontos de montagem no SSD. Ou seja o layout de mount points >>>>> deve ser apontado por esse levantamento… >>>>> >>>>> Mas como eu mencionei também antes, se voce ja sabe que é samba o serviço >>>>> principal você ja deve ter alguma ideia, mesmo sem olhar estatísticas, de >>>>> quais shares são os mais críticos em termos de performance. >>>>> >>>>> Então eu teria todas as partições no HDD, incluindo o /usr/home e teria >>>>> um outro volume (se for zfs) ou ou mpoint se for UFS, digamos /usr/home2 >>>>> e esse com o SSD. Todos os shares críticos em termos de performance >>>>> estaria no SSD, digamos (um chute) /usr/home2/producao, >>>>> /usr/home2/desenvolvimento, e os demais no HDD mesmo. >>>>> >>>>> Ou seja difícil sugerir sem conhecer a estrutura funcionam da empresa, >>>>> mas com certeza voce tem subsídios pra mapear e descobrir isso. >>>>> >>>>> Se ja existir um server com essa função hoje, faça o levantamento >>>>> estatístico no atual. >>>>> >>>>> Por exemplo, olhando com fstat no servidor aqui da empresa eu vejo que a >>>>> maior parte das operações de I/O acontecem no /usr/home e no /nfs. O “top >>>>> -mio -o total” me confirma essa noção, mostrando que os processos que >>>>> mais fazem I/O são httpd, nfsd e sshd (nego adora scp aqui hehehe) e >>>>> depois o postgres. >>>>> >>>>> Então aqui no servidor que atende a galera da empresa, certamente se >>>>> fosse pra ter um SSD ele seria no /nfs e no /usr/home. >>>>> >>>>> Mas se o SSD não for grande suficiente, vou olhar com lsof, nfsstat e >>>>> procstat pra saber quem são os que mais fazem esses acessos, e descubro >>>>> que no meu caso os que mais fazem I/O são: >>>>> >>>>> /usr/home/svn >>>>> /usr/home/honorato >>>>> >>>>> Bom no momento aqui parece que quem mais se beneficiaria de um SSD seriam >>>>> o usuário honorato e o Subversion ja que são os top I/O. >>>>> >>>>> Ou seja esse é o perfil que você tem que mapear. Não existe uma receita >>>>> de bolo pq cada server tem os usuários que merece hehehe ;) Às cegas eu >>>>> sugeriria o /usr/home no SSD mas se for insuficiente os 120G você precisa >>>>> ter um plano pra mapear quem fica num /usr/home2 e quem fica num >>>>> /usr/home, sendo um HDD outro SSD. >>>>> >>>>> Se for usar zfs use esse script dtrace pra ter estatísticas por dataset: >>>>> https://github.com/kdavyd/dtrace/blob/master/zfsio.d >>>>> >>>>> []s >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Att, >>>>>> Samuel .Rio Grande do Sul - RS >>>>>> >>>>>>> From: eks...@freebsdbrasil.com.br >>>>>>> Date: Mon, 18 May 2015 12:11:38 -0300 >>>>>>> To: freebsd@fug.com.br >>>>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1 >>>>>>> >>>>>>> >>>>>>>> On 17/05/2015, at 21:03, Samuel . <lista.freebsd.bra...@outlook.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Olá! >>>>>>>> Primeiramente obrigado pelas excelentes respostas. >>>>>>>> Eu pensei em usar o SSD para o sistema operacional e o HDD para /home, >>>>>>>> /var e /tmp. Assim, penso eu, poupo um pouco a sobrecarga no SSD e >>>>>>>> consequentemente aumento a vida útil dele. >>>>>>>> >>>>>>> Você não está poupando está desperdiçando… >>>>>>> >>>>>>> Está deixando de andar de Ferrari pra andar de Gol pq a manutenção é >>>>>>> mais barata. >>>>>>> >>>>>>> Só que a Ferrari não vai quebrar toda semana, só vai ser mais caro >>>>>>> quando quebrar. Se é pra não tirar da garagem melhor não ter. Se é pra >>>>>>> não usar seu SSD e tirar tudo que ele pra oferecer durante toda a vida >>>>>>> útil dele, melhor não ter um SSD só pq ele vai ter uma vida útil 80% >>>>>>> menor. >>>>>>> >>>>>>> Como eu disse no outro e-mail, ter SSD e HDD no seu servidor e usa-los >>>>>>> intensamente, na mesma proporção, é provável que você nunca veja seu >>>>>>> SSD morrer (a não ser que seja um SSD antigo das primeiras gerações), e >>>>>>> troque o servidor como um todo antes disso acontecer. Mas se o perfil >>>>>>> de uso for tão intenso que o SSD morreu 20% antes do tempo, terá valido >>>>>>> cada centavo antecipar uma troca de SSD 20% antes do tempo do HDD. >>>>>>> >>>>>>> Seu sistema operacional não precisa de um SSD! Quem precisa são seus >>>>>>> dados, o volume crítico da aplicação crítica. Seu kernel estará sempre >>>>>>> em memória e ter um SSD pra carregar seu /bin/ls ou /sbin/ifconfig num >>>>>>> read mais rápido pra memória não tem vantagem nenhuma, além do que os >>>>>>> arquivos mais comuns do SO já ficam em cache de RAM mesmo… >>>>>>> >>>>>>> Se eu fosse usuário do seu servidor e soubesse que meu /home está num >>>>>>> HDD lento e o resto do FreeBSD num SSD mega rápido eu tenho duvida se >>>>>>> ficaria triste ou revoltado hehehe ;) Mas certamente não seria um >>>>>>> usuário feliz e satisfeito nem acharia que o investimento no SSD valeu >>>>>>> a pena pra qualidade geral do serviço prestado por esse servidor! >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Att, >>>>>>>> Samuel .Rio Grande do Sul - RS >>>>>>>> >>>>>>>>> From: eks...@freebsdbrasil.com.br >>>>>>>>> Date: Sun, 17 May 2015 14:37:32 -0300 >>>>>>>>> To: freebsd@fug.com.br >>>>>>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On May 17, 2015, at 2:14 PM, Nilton Jose Rizzo <ri...@i805.com.br> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Tenho uma dúvida em relação ao uso de ssd ... >>>>>>>>>> >>>>>>>>>> Como anda a durabilidade deles? Já é seguro utiliza-los >>>>>>>>>> em produção para grande massa de dados? como ficaria esta >>>>>>>>>> durabilidade caso tivesse apenas o SSD e utilizasse o sistema >>>>>>>>>> fazendo a atualização do src e ports semanalmente? >>>>>>>>> Hoje em dia creio que seja besteira se preocupar com a vida útil de >>>>>>>>> um SSD, um SLC suporta mais ciclos de escrita que um HDD e um MLC tem >>>>>>>>> expectativa de durar 80% dos ciclos de escrita de um HDD, ou seja se >>>>>>>>> a expectativa de 7 anos do HDD bate com seu perfil de escrita em >>>>>>>>> disco o SSD seria de 5.6 anos mas um servidor ou laptop como um todo, >>>>>>>>> o mercado trabalha com expectativa de 5 anos até ser substituído. >>>>>>>>> >>>>>>>>> Ou seja todos que só tem SSD num laptop dificilmente verão seu SSD >>>>>>>>> morrer antes de apoderarem a máquina como um todo. >>>>>>>>> >>>>>>>>> Mesma coisa pra maioria dos perfis de servidor em especial os perfis >>>>>>>>> de uso onde a leitura é a maior parte das operações. SSD MLC duram >>>>>>>>> menos ciclos de escrita mas duram mais ciclos de leitura. >>>>>>>>> >>>>>>>>> Ou seja apenas um SGDB com muita escrita ou um servidor de cache >>>>>>>>> veria um SSD MLC morrer 1/5 do tempo antes de um HDD mas convenhamos >>>>>>>>> ganhou tanto em performance que morrer e substituir por outro 20% >>>>>>>>> mais rápido justifica casa centavo :) >>>>>>>>> >>>>>>>>> Antes era gambi, os sistemas operacionais (file system) tinham que se >>>>>>>>> preocupar em fazer wear leveling pra poupar a vida dos SSD etc, hj o >>>>>>>>> próprio drive cuida desses aspectos hehehe do mesmo modo que no >>>>>>>>> passado tínhamos que rodar badsect e mapeadores de Bad block e hj os >>>>>>>>> discos já os isolam sozinhos. >>>>>>>>> >>>>>>>>> Enfim a única coisa a se preocupar com SSD eh o preço :) o resto eh >>>>>>>>> preciosismo hj em dia. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> /************************************************* >>>>>>>>>> **Nilton José Rizzo UFRRJ >>>>>>>>>> **http://www.rizzo.eng.br http://www.ufrrj.br >>>>>>>>>> **http://lattes.cnpq.br/0079460703536198 >>>>>>>>>> **************************************************/ >>>>>>>>>> >>>>>>>>>> ------------------------- >>>>>>>>>> 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 >>>>>>> -- >>>>>>> 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 >> -- >> 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
