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 <[EMAIL PROTECTED]> > 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, ([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 > > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > [EMAIL PROTECTED] > 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
