The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9.

11.10.2007 18:15

Ingo Molnar, чтобы доказать повышение эффективности работы нового планировщика задач (CFS), представил результаты сравнения производительности Linux ядер 2.6.23 и 2.6.22.9 (график). Тестирование проводилось при помощи утилиты sysbench совместно с СУБД MySQL 5.0.45.

Днем позже, Ingo опубликовал результаты, включив в сравнение три дополнительных конфигурации ядра 2.6.23 с подкорректированными параметрами планировщика.

  1. Главная ссылка к новости (http://kerneltrap.org/Linux/Me...)
  2. OpenNews: Дуэль по тестированию производительности NetBSD и FreeBSD
  3. Сравнение FreeBSD и Linux: тест MySQL
  4. Сравнение FreeBSD и Linux: тест PotgreSQL
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/12398-linux
Ключевые слова: linux, scheduler, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Nick (??), 18:35, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну, красота :)

    что сказать... вещь

    и вещь отданная под GPL'ем...

    было бы любопытно взглянуть на тесты .23 ядра со срезами BSDшных высот

     
  • 1.2, Аноним (2), 18:56, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://people.freebsd.org/~kris/scaling/

    http://people.freebsd.org/~kris/scaling/linux-mysql.png
    http://people.freebsd.org/~kris/scaling/linux-pgsql.png


    типа так?

     
     
  • 2.3, Nick (??), 19:07, 11/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    для начала неплохо
    но вобщем-то желательно не release candidat рассматривать
    и в ванильном виде (не знаю чего там Федора подмешала)
     
  • 2.7, sauron (??), 21:17, 11/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Ага только вот там про огрехи gnu glibc malloc промолчали. Несколькими новостями ниже есть сравнение ядра linux с tcalloc. Там график ровнее.
     

  • 1.6, Аноним (2), 20:43, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А трехкратное падение производительности для одного клиента это типа нормально? Зато OMFG, теперь мы на 20% меньше тупим на десятке клиентов.
     
     
     
    Часть нити удалена модератором

  • 3.25, Аноним (-), 14:06, 12/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    посмотри начало графиков
    в первой точке, которая соответствует 1 клиенту, транзакций в .23 меньше в 3 раза
     
     
  • 4.26, anonymous (??), 14:28, 12/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    На графиках количество транзакций в секунду не от нуля начинается, а от 400.
    Так что падение не в три раза, а где-то на 20 процентов (что тоже не очень радует).
     
     
  • 5.28, Аноним (-), 14:57, 12/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    блин, который раз накалываюсь на этом :)
     
     
  • 6.32, _Nick_ (??), 03:48, 13/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    да расслабьтесь

    системе с один запросом в единицу времени пофик производительность ЗАЧАСТУЮ


    Интересны именно паралельные запросы.
    Так что даже если пере Инго стоял выбор - он его сделал верно.

     

  • 1.12, pavlinux (??), 22:14, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все уроды, я the best !!!

    Ладно, по делу:

    > ... and i'm definitely interested in more
    > feedback about this:

    asmlinkage long sys_time(time_t __user * tloc)
    {
    - time_t i;
    - struct timespec tv;
    -
    - getnstimeofday(&tv);
    - i = tv.tv_sec;
    + time_t i = get_seconds();

     
     
  • 2.13, pavlinux (??), 22:16, 11/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя, может на VAX или на ARM  get_seconds() не работает???
     
     
  • 3.35, Аноним (2), 01:50, 15/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Хотя, может на VAX или на ARM  get_seconds() не работает???

    Эй, мокрый куриц, а на мипс?

     

  • 1.15, Ромка (?), 23:21, 11/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Господа, а какой подскажет какой утилиткой такие графички рисуются? Неужтно gnuplot'ом?
     
     
  • 2.16, pavlinux (??), 23:49, 11/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Да ты так не пугайся gnuplot_a, часика три помучаешся,  потом понравиться!

     

  • 1.21, Аноним (2), 11:48, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть подобные графики для Соляриса?
     
  • 1.22, Аноним (22), 13:16, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а кто знает, почему в новое ядро не включают tcmalloc, вместо обычного malloc'а?
     
     
  • 2.23, Anonim (?), 13:31, 12/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Это не проблема ядра. Это проблема glibc
     
     
  • 3.24, Аноним (-), 13:43, 12/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    точно, глупость сказал, сорри.
    не знаете, почему в glibc его не включают?
     
     
  • 4.29, Аноним (-), 16:04, 12/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    У него есть свои недостатки.
    Например (пока) он не возвращает память операционной системе.

    Как стандартный аллокатор назначения он не годится.

    Многопоточные программы, постоянно выделяющие/освобождающие память легко могут его использовать вместо стандартного. Остальные программы нечего ломать :)

     

  • 1.27, fresco (??), 14:56, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кроме прочего, в 2.6.23 добавились усовершенствования  производительности в read ahead, reiserfs и XFS. Тоже, ИМХО, немаловажные штучки в плане быстродействия всей системы. Хотя в контексте этого теста они, конечно, не так чувствуются.
     
  • 1.31, pavlinux (??), 23:25, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не успели обругать.... как 2.6.23.1 надворе. :)

    libata: sata_mv: more S/G fixes
        
    * corruption fix: we only want the lower 16 bits of length (0 == 64kb)

    * ditto: the upper layer sets max-phys-segments to LIBATA_MAX_PRD, so we must reset it to own
    hw-specific length.

    * delete unused mv_fill_sg() return value.

     
     
  • 2.34, Аноним (-), 23:02, 14/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    может кучкуются чтобы второй проц ничем не занимать?


     

  • 1.33, pavlinux (??), 13:22, 14/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Vanila 2 6 23 pavel toshka uname -a Linux toshka 2 6 23 3 SMP PREEMPT Thu ... большой текст свёрнут, показать
     
     
  • 2.37, Nick (??), 02:00, 15/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    ИМХО

    в не-RT ядре прерывания нужно обрабатывать сразу, по мере их появления.
    За сим, любой свободный проц чудно подходит для этого.

    А в ядре, где для прерываний свои очереди выполнения имеют - их можно и отложить, выпонив на одном проце. Именно на одном, видать, по кешу выгодно.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру