форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Сравнение производительности Linux ядер 2.6.23 и 2..."

Сообщение от opennews (??) on 11-Окт-07, 18:35

Ingo Molnar, чтобы доказать повышение эффективности работы нового планировщика задач (CFS), представил (http://kerneltrap.org/Linux/Measuring_Process_Scheduler_Performance) результаты сравнения производительности Linux ядер 2.6.23 и 2.6.22.9 (график (http://people.redhat.com/mingo/misc/sysbench.jpg)). Тестирование проводилось при помощи утилиты sysbench (http://sysbench.sourceforge.net/) совместно с СУБД MySQL 5.0.45. Днем позже, Ingo опубликовал результаты (http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg), включив в сравнение три дополнительных конфигурации ядра 2.6.23 с подкорректированными параметрами планировщика. URL: http://kerneltrap.org/Linux/Measuring_Process_Scheduler_Performance Новость: http://www.opennet.me/opennews/art.shtml?num=12398

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

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

Сообщение от Nick (??) on 11-Окт-07, 18:35

ну, красота :) что сказать... вещь и вещь отданная под GPL'ем... было бы любопытно взглянуть на тесты .23 ядра со срезами BSDшных высот

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним on 11-Окт-07, 18:56

http://people.freebsd.org/~kris/scaling/ http://people.freebsd.org/~kris/scaling/linux-mysql.png http://people.freebsd.org/~kris/scaling/linux-pgsql.png типа так?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Nick (??) on 11-Окт-07, 19:07
	для начала неплохо но вобщем-то желательно не release candidat рассматривать и в ванильном виде (не знаю чего там Федора подмешала)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от sauron (??) on 11-Окт-07, 21:17
	Ага только вот там про огрехи gnu glibc malloc промолчали. Несколькими новостями ниже есть сравнение ядра linux с tcalloc. Там график ровнее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним on 11-Окт-07, 20:43

А трехкратное падение производительности для одного клиента это типа нормально? Зато OMFG, теперь мы на 20% меньше тупим на десятке клиентов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Аноним on 12-Окт-07, 14:06
	посмотри начало графиков в первой точке, которая соответствует 1 клиенту, транзакций в .23 меньше в 3 раза
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от anonymous (??) on 12-Окт-07, 14:28
	На графиках количество транзакций в секунду не от нуля начинается, а от 400. Так что падение не в три раза, а где-то на 20 процентов (что тоже не очень радует).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Аноним on 12-Окт-07, 14:57
	блин, который раз накалываюсь на этом :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от _Nick_ (??) on 13-Окт-07, 03:48
	да расслабьтесь системе с один запросом в единицу времени пофик производительность ЗАЧАСТУЮ Интересны именно паралельные запросы. Так что даже если пере Инго стоял выбор - он его сделал верно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от pavlinux (??) on 11-Окт-07, 22:14

Все уроды, я 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();

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от pavlinux (??) on 11-Окт-07, 22:16
	Хотя, может на VAX или на ARM  get_seconds() не работает???
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Аноним on 15-Окт-07, 01:50
	>Хотя, может на VAX или на ARM  get_seconds() не работает??? Эй, мокрый куриц, а на мипс?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Ромка on 11-Окт-07, 23:21

Господа, а какой подскажет какой утилиткой такие графички рисуются? Неужтно gnuplot'ом?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от pavlinux (??) on 11-Окт-07, 23:49
	Да ты так не пугайся gnuplot_a, часика три помучаешся,  потом понравиться!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним on 12-Окт-07, 11:48

А есть подобные графики для Соляриса?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним on 12-Окт-07, 13:16

а кто знает, почему в новое ядро не включают tcmalloc, вместо обычного malloc'а?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Anonim on 12-Окт-07, 13:31
	Это не проблема ядра. Это проблема glibc
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Аноним on 12-Окт-07, 13:43
	точно, глупость сказал, сорри. не знаете, почему в glibc его не включают?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Аноним on 12-Окт-07, 16:04
	У него есть свои недостатки. Например (пока) он не возвращает память операционной системе. Как стандартный аллокатор назначения он не годится. Многопоточные программы, постоянно выделяющие/освобождающие память легко могут его использовать вместо стандартного. Остальные программы нечего ломать :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от fresco (??) on 12-Окт-07, 14:56

Кроме прочего, в 2.6.23 добавились усовершенствования  производительности в read ahead, reiserfs и XFS. Тоже, ИМХО, немаловажные штучки в плане быстродействия всей системы. Хотя в контексте этого теста они, конечно, не так чувствуются.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от pavlinux (??) on 12-Окт-07, 23:25

Не успели обругать.... как 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.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Аноним on 14-Окт-07, 23:02
	может кучкуются чтобы второй проц ничем не занимать?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от pavlinux (??) on 14-Окт-07, 13:22

Vanila 2.6.23 pavel@toshka:~> uname -a Linux toshka 2.6.23 #3 SMP PREEMPT Thu Oct 11 21:59:37 MSD 2007 x86_64 x86_64 x86_64 GNU/Linux pavel@toshka:~> cat /proc/interrupts            CPU0       CPU1   0:     101550          0   IO-APIC-edge      timer   1:          9        108   IO-APIC-edge      i8042   8:          1          0   IO-APIC-edge      rtc   9:         95         59   IO-APIC-fasteoi   acpi 12:        132          0   IO-APIC-edge      i8042 14:       2507       4513   IO-APIC-edge      libata 15:        178        769   IO-APIC-edge      libata 16:          1       4190   IO-APIC-fasteoi   uhci_hcd:usb4, nvidia 18:         31        801   IO-APIC-fasteoi   uhci_hcd:usb3, tifm_7xx1, sdhci:slot0 19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb2 20:          9        353   IO-APIC-fasteoi   eth0 22:        627          0   IO-APIC-fasteoi   HDA Intel 23:         60          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5 NMI:          0          0 LOC:     101436     100914 ERR:          0 Vanila (2.6.23) + Ingo Monlar RT Patch (2.6.23-rt1) pavel@toshka:~> uname -a Linux toshka 2.6.23-rt1 #5 SMP PREEMPT RT Fri Oct 12 23:45:03 MSD 2007 x86_64 x86_64 x86_64 GNU/Linux pavel@toshka:~> cat /proc/interrupts            CPU0       CPU1   0:        116          0   IO-APIC-edge      timer   1:         45          0   IO-APIC-edge      i8042   8:          1          0   IO-APIC-edge      rtc   9:        223          0   IO-APIC-fasteoi   acpi 12:        135          0   IO-APIC-edge      i8042 14:      21295          0   IO-APIC-edge      libata 15:       2069          0   IO-APIC-edge      libata 16:      12560          1   IO-APIC-fasteoi   uhci_hcd:usb5, nvidia 18:       3618          0   IO-APIC-fasteoi   uhci_hcd:usb4, tifm_7xx1 19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3 20:       1906          0   IO-APIC-fasteoi   eth0 22:        836          0   IO-APIC-fasteoi   HDA Intel 23:         31          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2 NMI:          0          0 LOC:     109061     110664 ERR:          0 pavel@toshka:~> cat /proc/cpuinfo | grep "model name" model name      : Intel(R) Core(TM)2 CPU         T7400  @ 2.16GHz model name      : Intel(R) Core(TM)2 CPU         T7400  @ 2.16GHz Какие мысли? Почему все прерывания на первом ядре кучкуются?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Сравнение производительности Linux ядер 2.6.23 и 2.6.22.9."
	Сообщение от Nick (??) on 15-Окт-07, 02:00
	ИМХО в не-RT ядре прерывания нужно обрабатывать сразу, по мере их появления. За сим, любой свободный проц чудно подходит для этого. А в ядре, где для прерываний свои очереди выполнения имеют - их можно и отложить, выпонив на одном проце. Именно на одном, видать, по кешу выгодно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема