[FUG-BR] Particionamento FreeBSD 10.1
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Terça Maio 19 18:08:22 BRT 2015
> On 19/05/2015, at 17:51, Marcelo Gondim <gondim em bsdinfo.com.br> wrote:
>
> On 19-05-2015 14:04, Patrick Tracanelli wrote:
>>> On 18/05/2015, at 20:20, Samuel . <lista.freebsd.brasil em 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.brasil em outlook.com
>>>> To: freebsd em 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: eksffa em freebsdbrasil.com.br
>>>>> Date: Mon, 18 May 2015 19:58:45 -0300
>>>>> To: freebsd em fug.com.br
>>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1
>>>>>
>>>>>
>>>>>> On 18/05/2015, at 19:18, Samuel . <lista.freebsd.brasil em 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: eksffa em freebsdbrasil.com.br
>>>>>>> Date: Mon, 18 May 2015 12:11:38 -0300
>>>>>>> To: freebsd em fug.com.br
>>>>>>> Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1
>>>>>>>
>>>>>>>
>>>>>>>> On 17/05/2015, at 21:03, Samuel . <lista.freebsd.brasil em 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: eksffa em freebsdbrasil.com.br
>>>>>>>>> Date: Sun, 17 May 2015 14:37:32 -0300
>>>>>>>>> To: freebsd em 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 <rizzo em 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
>>>>>>> 316601 em 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
>>>>> 316601 em 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
>> 316601 em 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
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
Mais detalhes sobre a lista de discussão freebsd