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

[Ronan Lucio]

Patrick,

Cara, embora alguns anos afastado da lista pude perceber que você não 
muda... que bom... :-)
O que dizer depois de uma resposta como essa?
Excelente.

Apenas um adendo.
O que eu tenho percebido, para a nossa tristeza, no site da MySQL é que 
depois que a Sun a comprou, da a impressão que FreeBSD passou a ficar em 
segundo plano pra eles.

Vira e mexe a gente se depara com uma declaração extremamente 
tendenciosa ao Solaris, olha só:

/"The operating system to use is very important. To get the best use of 
multiple-CPU machines, you should use Solaris (because its threads 
implementation works well) or Linux (because the 2.4 and later kernels 
have good SMP support)."
/http://dev.mysql.com/doc/refman/5.0/en/system-optimization.html

Uma pena. Espero que eles se limitem as declarações.

[]s
Ronan

Patrick Tracanelli escreveu:
> Ronan Lucio escreveu:
>   
>> Thiago,
>>
>> Segue o link:
>> http://people.freebsd.org/~kris/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
>
> 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
>
> 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
>>     
>
>
>