[FUG-BR] Mysql no linux melhor que no bsd ???

[Bandeira]

Quanto % o ULE ganha por core adicionado como no exemplo abaixo?



http://www.freelists.org/post/haiku/Haikus-SMP

Haiku gained over 80% increased performance when going from
single to dual core in Chart demo with multi-threading ( 2 Threads ).




2008/11/20 Patrick Tracanelli <eksffa em freebsdbrasil.com.br>

> Ronan Lucio escreveu:
> > Thiago,
> >
> > Segue o link:
> > http://people.freebsd.org/~kris/scaling/mysql.html<http://people.freebsd.org/%7Ekris/scaling/mysql.html>
> >
> > Mas na realidade parece que o FreeBSD é mais rápido que o Linux apenas
> > com alta carga.
> >
> > []s
> > Ronan
> >
>
> Na verdade como o link mostra, FreeBSD é pelo menos 14% mais rápido em
> qualquer carga e até 33% em algumas situações. O que é muito bom... bom
> pro Linux :)
>
> Porque quando o processo de finalização do SMPng começou ser concluído
> os resultados eram muito, muito ruins pro Linux:
>
> http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf<http://people.freebsd.org/%7Ekris/scaling/Scalability%20Update.pdf>
>
> A gente consegue ver que comparando ao SCHED_4BSD o Linux era superior
> ao FreeBSD sempre, mas mesmo assim a gente ve uma anomalia, ao começar
> ter 8 threads concorrentes em 8 núcleos (1 em cada) o Linux atingia seu
> topo de performance, dai pra frente, quando começava a haver de fato
> concorrencia por núcleo a degradação no Linux era matematicamente
> escalar. Bem trágico e gritante quando se põe em gráfico.
>
> Ai a gente ve no Slide 8 que o Linux continuava superior ao FBSD7 até o
> checkpoint de 8 threads por núcleo. Veja bem, não quer dizer baixa
> carga. Se fosse um Dual, 2 threads. Num mono, 1 thread era o checkpoint
> de qualidade, depois disso a degradação era absurda enquanto no FreeBSD
> a performance era constante - como era muito adequado.
>
> Quando o pessoal do Linux cansou de rebater e falar mal dos testes
> (mesmo a metodologia sendo simples), a Red Hat disse por e-mail que fez
> os mesmos testes e comprovou mas com outros resultados: com resultados
> ainda piores pro Linux.
>
> O historico disso tem no Kernel Trap e no Blog do Jeff Roberson
>
> Ai o que aconteceu, a Red Hat testou o CFS (novo escalonador do Linux) e
> viu que os resultados eram ainda piores. Focou seus esforços nessa
> melhoria, e inclusive o Roberson disse em seu blog quais primitivas ele
> melhoraria no Linux, e a Red Hat solicitou uma análise com consultoria
> paga à Isilon (empresa de Seattle que "paga" o trabalho do Roberson) com
> mais detalhes.
>
> Um monte de gente disse que os resultados eram tais devido ao fato do
> Greg Lehey havia se tornado ha alguns anos Senior Developer do MySQL e
> funcionário da MySQL-AB e que possivelmente bla bla bla, ble ble ble,
> que ficou claro em entrevista ao BSDTalk que ele otimizava sim, pra
> FreeBSD, mas também para outros BSD e Solaris.
>
> http://derek.trideja.com/bsdtalk/2006-07-18_greg-lehey.html
>
> De qualquer forma a ideia de "FreeBSD só é melhor com MySQL" foi
> plantada, e pra não deixar crescer o Kris tratou logo de fazer os
> benchmarks também com PostgreSQL, resultados na pagina 17:
>
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf<http://people.freebsd.org/%7Ekris/scaling/7.0%20Preview.pdf>
>
> Linux se mostrou pouco (em média 5%) inferior ao FreeBSD em ambiente com
> carga "amigável", ou seja até 8 threads (1 por núcleo), mas com
> performance ainda muito inferior com PostgreSQL quando comparado com
> FreeBSD a partir de 8 threads, e pior, com comportamento anômalo, que
> mostrava degradação escalar de performance a partir de 8. threads, e
> depois perto de 2 threads por núcleo se recuperava.
>
> O que apresentava situação de fato adequada com o que foi plantado, mas
> no sentido contrário: ficou aparente que as melhorias no Linux que o
> tornavam mais "adequados" no MySQL se aplicavam apenas ao MySQL e em
> outro ambiente não correspondia, enquanto o FreeBSD apresentava
> comportamento uniforme, deixando claro que aquela performance era do
> FreeBSD, e não do MySQL no FreeBSD.
>
> David Kelly, (dkelly em hiwaay.net, dkelly em postgresql.org) um desenvolvedor
> PgSQL disse que "não importa o que melhore, e o quanto a aplicação
> implemente workarounds, o OOMKiller do Linux vai eventualmente sempre
> derrubar o PostgreSQL ou outra aplicação, sob grande carga".
>
> David Kelly se referia ao conhecido Memory Overcommit do Linux, que pode
> ser amenizado mas não resolvido, também chamado de OOMKiller:
>
> http://www.postgresql.org/docs/8.3/static/kernel-resources.html
> http://lwn.net/Articles/104179/
>
> > Thiago J. Ruiz escreveu:
> >> me lembro que quando saiu o ULE o pessoal que fez a reportagem falou
> >> que deixou o linux pra trás em MySQL com ULE rodando.
> >>
> >> mas não achei o link pra enviá-los infelizmente.
> >>
> > -------------------------
> > 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
>