[FUG-BR] Particionamento FreeBSD 10.1
Samuel .
lista.freebsd.brasil em outlook.com
Segunda Maio 18 20:15:08 BRT 2015
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
Mais detalhes sobre a lista de discussão freebsd