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, ([EMAIL PROTECTED], [EMAIL PROTECTED]) 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 >> > > > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
