The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Система непрерывного тестирования производительности ядра Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Система непрерывного тестирования производительности ядра Linux"  +/
Сообщение от opennews (ok) on 22-Июл-15, 16:26 
Разработчики SUSE Linux  представили (http://www.csn.ul.ie/~mel/blog/index.php?/archives/23-Contin...) проект Marvin (http://www.csn.ul.ie/~mel/results/suse/marvin/), в рамках которого организован процесс непрерывного тестирования производительности ядра Linux. После завершения выполнения очередного набора тестов, Marvin переходит к их повторному выполнению над актуализированными сборками ядра, включающими свежие исправления. Затем результаты сравниваются с прошлым выполнением теста и выявляются регрессивные падения производительности, о которых информируются (http://www.csn.ul.ie/~mel/results/suse/marvin/dashboard-open...) разработчики. Несмотря на то, что система изначально нацелена на тестирование ядра из состава SUSE Enterprise  Linux, она также настроена и на тестирование основного ядра Linux.

URL: http://www.csn.ul.ie/~mel/blog/index.php?/archives/23-Contin...
Новость: http://www.opennet.me/opennews/art.shtml?num=42648

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Система непрерывного тестирования производительности ядра Li..."  +1 +/
Сообщение от A.Stahl (ok) on 22-Июл-15, 16:26 
Что-то по ссылкам я так и не нашёл информации на каких платформах тестируют. Или один лишь AMD64?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Система непрерывного тестирования производительности ядра Li..."  –1 +/
Сообщение от Аноним (??) on 22-Июл-15, 17:03 
А те регрессии, что накапливались 20 лет определить не получится?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Система непрерывного тестирования производительности ядра Li..."  –7 +/
Сообщение от rshadow (ok) on 22-Июл-15, 17:11 
Они уже давно перекрыты повышением в 2^10 раза производительности компов.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Система непрерывного тестирования производительности ядра Li..."  +12 +/
Сообщение от Аноним (??) on 22-Июл-15, 17:37 
Роутеры с вами не согласны
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от Аноним (??) on 22-Июл-15, 18:19 
Вы представитель союза (свободных) роутеров? Огласите ваши требования!
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Система непрерывного тестирования производительности ядра Li..."  +5 +/
Сообщение от Michael Shigorin email(ok) on 22-Июл-15, 18:34 
> Вы представитель союза (свободных) роутеров? Огласите ваши требования!

Это лучше тов. sfstudio спросить, если по существу.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "Система непрерывного тестирования производительности ядра Li..."  +12 +/
Сообщение от sfstudio email(ok) on 22-Июл-15, 21:46 
А чего там спрашивать? Всё от задачи зависит.

Типовая для роутера это роутинг + NAT. С ним дела обстоят так что после 3.4 версии деградация производительности на одноядерных мипсах порядка 40%, большей частью из-за удаления route cache. В итоге в OpenWRT таки бэкпортнули часть route cache  с которой работал контрак это частично решило проблему сократив регресс по скорости где-то до 20%.

В общей сложности сравнивая 2.6.21 и 3.4 (чистые) деградация на mips24kc порядка 30%.

На SMP mips 1004kc так же после 3.4 вплоть до 4.0 наблюдался некоторый завал производительности. С 4.0 стало даже быстрее чем на 3.4 ессно если приюзать XPS/RPS и правильно раскидать прерывания.

Собсно большинство недорогих маршрутизаторов на рынке это именно что-то на mips 24kc.

Но тенденция ясна, всё движется в сторону SMP в итоге оверхид на одноведерных железяках растёт и существенно. Как минимум в части сети, в остальном не тестировал и как бы не особо слежу за остальными подсистемами. Тут пусть другие поделятся.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Система непрерывного тестирования производительности ядра Li..."  +1 +/
Сообщение от Аноним (??) on 22-Июл-15, 23:33 
А появившееся в 3,18 http://www.opennet.me/opennews/art.shtml?num=41210
>В сетевую подсистему внесены оптимизации, направленные на увеличение производительности пакетной передачи данных. Изменения особенно заметны при обработке большого объёма мелких пакетов. Производительность повышена за счёт организации групповых операций блокировки очереди, а также заполнения/очистки очереди и взаимодействия с драйвером сетевой карты не на уровне отдельных пакетов, а манипулируя порциями пакетов. Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;

сказалось положительно на производительности недорогих роутеров?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Система непрерывного тестирования производительности ядра Li..."  +7 +/
Сообщение от sfstudio email(ok) on 22-Июл-15, 23:55 
К сожалению никак не сказалось по сути.

BQL требует поддержку на уровне драйверов (у нас она есть), но как бы производительности не добавляет оно динамически крутит размер очереди в драйвере т.е. по сути влияет на задержки т.к. раньше очереди были всегда фиксированными и длинными, полезно в паре с fq_codel.

qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE из того же набора по сути оптимизация блокировок в qdisc. Более того не работает с GSO.

net: Make dev_hard_start_xmit() work fundamentally on lists идея ясна но разницы на одноведерном мипсе с микроскопом не нашёл.

На SMP основной профит в новых ядрах по производительности на транзитной пакетомолотилки получился из-за отказа от root блокировки в контрак что позволило его распараллелить. Плюс ещё стопка патчей на схожую тему.

Однако всё это не компенсирует даже одного единственного удаления route cache. Так что пока мы остановились на 3.4 и мониторим как развивается ситуация проверяя каждую значимую ветку. А пока приходиться самостоятельно бэкпортить достаточно много кода в 3.4 ибо не смотря на то что оно LTS и до сих пор поддерживается, но многие критичные фиксы по сети и оптимизации в него не перененесли, вообще в LTS традиционно сети уделяется очень мало внимания.

>Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;

Тут видимо просто забыли добавить на SMP системах. =) Домашний компутер о 8ми 2ГГц x86 с DDR3 рамой и с огромным кэшем головах это далеко не средний или дешовый роутер с ~400-600МГц одноведерным mips 24kc у которого и L2 то кэша нет вообще никакого и рама дай бог DDR1.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от 1283648282 on 23-Июл-15, 12:01 
Вендоры специально для таких случаев интегрируют аппаратную обработку NAT в чипы, но нет - будем жевать кактус и использовать чисто программные решения.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "Система непрерывного тестирования производительности ядра Li..."  +1 +/
Сообщение от sfstudio email(ok) on 23-Июл-15, 12:12 
А мы и используем PPE и во все поля, но факт остаётся фактом. Да и далеко не для всех кейзов PPE заюзать удаётся.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от freehck email(ok) on 11-Авг-15, 15:57 
> В итоге в OpenWRT таки бэкпортнули часть route cache

Небольшой оффтоп по терминологии: не бэкпортнули, а именно портировали. Бэкпорт -- это когда из новых версий в старые переносят.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

20. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от sfstudio email(ok) on 11-Авг-15, 16:04 
>> В итоге в OpenWRT таки бэкпортнули часть route cache
> Небольшой оффтоп по терминологии: не бэкпортнули, а именно портировали. Бэкпорт -- это
> когда из новых версий в старые переносят.

Ну тут даже не портировали, а привернули/родили/написали лишь отчасти аналогичную логику. Как бы не легче от этого.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

15. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от CSRedRat email(ok) on 23-Июл-15, 08:55 
Почему нет? Код ядра открыт, архивы доступны - пожалуйста.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Система непрерывного тестирования производительности ядра Li..."  –9 +/
Сообщение от Аноним (??) on 22-Июл-15, 18:32 
Выглядит отвратно html4, на NodeJS им слабо?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от Аноним (??) on 22-Июл-15, 19:06 
Вам шашечки или ехать?
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от Аноним (??) on 22-Июл-15, 19:10 
Нам нормальную систему проведения тестов, BuildBot вполне.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

16. "Система непрерывного тестирования производительности ядра Li..."  –1 +/
Сообщение от iPony on 23-Июл-15, 10:00 
нам надо ехать с шашечками
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Система непрерывного тестирования производительности ядра Li..."  +/
Сообщение от Аноним (??) on 22-Июл-15, 23:39 
> NodeJS

нет, спасибо.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

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

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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