> On 19/05/2015, at 14:05, Paulo Henrique - BSDs Brasil > <paulo.rd...@bsd.com.br> wrote: > > > On 05/19/15 13:45, Patrick Tracanelli wrote: >>> On 18/05/2015, at 20:19, Paulo Henrique - BSDs Brasil >>> <paulo.rd...@bsd.com.br> wrote: >>> >>> >>> On 05/18/15 19:58, Patrick Tracanelli wrote: >>>>> 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 >>> Aproveitando e engajando na conversa, lembro no passado o ZFS ter suporte a >>> SSD para nivel de cache ( ARC2 ou trim se não me engano ), como não sou >>> adepto dele ( começamos com o pé esquerdo apos uma queda de energia ter >>> perdido todas as minhas musicas ) não posso afirmar se há esse recurso >>> mesmo e se o nome deles é um dos anteriormente citados com plena certeza >>> alguém ai que usa e pode confirmar? >> É isso ai, o ZIL que é o cache de escrita (na verdade é o logging das >> operações de metadata, típico de FS jornada) e L2ARC que é o cache de >> leitura. Ambos podem ser metidos no SSD sim, seria algo como (assumindo que >> SSD seja de 120G no ada2 que é a situação do Samuel e ele queira 8G pro >> L2ARC e 20 pro ZIL e o resto pro samba): >> >> gpart add -t freebsd-zfs -a 4k -l log -s 8G ada2 >> gpart add -t freebsd-zfs -a 4k -l cache -s 20G ada2 >> gpart add -t freebsd-zfs -a 4k -l home2 -s 92G ada2 >> zpool create zstore gpt/home2 log gpt/log cache gpt/cache >> >> > > No caso seria possivel manter o home no HDD em tratar o cache e log só no SSD > ?
Certamente, só é espaço demais… 120G de SSD pra L2ARC+ZIL = desperdício e SSD que nunca será tocado. Lembre-se ZIL é meta-dados e L2ARC é L2, ou seja tem um estágio de Cache que é feito antes na RAM pra so depois ir pra disco. > Creio que para o que ele possua seja mais interessante. Eu discordo vai voltar ao ponto de desperdício ehehe, o benefício será sempre mais sentido se a aplicação crítica tirar proveito do SSD primariamente. Mas enfim acho que a discussão ja deu subsídios suficiente agora é partir pra decisão do que fazer :D > Supondo que o HDD dele seja o ada3. > > gpart add -t freebsd-zfs -a 4k -l log -s 38G ada2 > gpart add -t freebsd-zfs -a 4k -l cache -s 82G ada2 > gpart add -t freebsd-zfs -a 4k -l home -s 200G ada3p3 ( Considerando que ele > deixe 200Gbytes para o home no servidor sobre o HDD e separado do / e swap, > normalmente eu separo o /usr, /var e /tmp tambem ) > zpool create zstore gpt/home log gpt/log cache gpt/cache > > Particionamento do HDD seria > / => (TAM=(HOME - (SWAP*2)))G => ada3p1 > swap => RAM*2 => ada3p2 > /home => 200G => ada3p3 > > Att. >> >> >>> Samuel, não irá colocar nenhum recursos de resiliencia no seu HDD ? se não >>> for colocar coloca todos os dados no SSD simplesmente devido a >>> probabilidade de falha dele comparado com o HDD é bem menor. >>> E aproposito qual o modelo do seu HDD ? se for qualquer HDD de desktop eu >>> desencorajo a utilização, usei muito no passa e ainda tenho dois servidores >>> usando discos da Western Digital contudo o que perco de desempenho e >>> resistencia de operação com eles não vale a pena a economia. >>> >>> Att. >>> >>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>> -- >>> Paulo Henrique. >>> BSDs Brasil - FUG-BR. >>> Grupo de Usuários de FreeBSD do Brasil. >>> Fone: (21) 96713-5042 >>> >>> "Por mais breve que seja a loucura da fé, apegue-se a razão. >>> Ela não tem todas as respostas porém não mente baseado na sua fé". >>> >>> ------------------------- >>> 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 > > -- > Paulo Henrique. > BSDs Brasil - FUG-BR. > Grupo de Usuários de FreeBSD do Brasil. > Fone: (21) 96713-5042 > > "Por mais breve que seja a loucura da fé, apegue-se a razão. > Ela não tem todas as respostas porém não mente baseado na sua fé". > > ------------------------- > 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
