The OpenNET Project / Index page

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



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

"В ядре Linux 7.0 выявили регрессию, в два раза снижающую производительность PostgreSQL"  +/
Сообщение от opennews (??), 04-Апр-26, 18:52 
Инженер из компании Amazon выявил регрессию, специфичную для ядра Linux 7.0, релиз которого ожидается 13 апреля. Изменение настроек планировщика задач привело к существенному снижению пропускной способности и отзывчивости при работе  СУБД PostgreSQL на системах с архитектурой ARM64. При использовании ядра 7.0 показатели производительности при прохождении теста pgbench "simple-update" снизились почти в два раза - с 98565 до 50751...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=65143

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

Оглавление

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


1. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –3 +/
Сообщение от Аноним (1), 04-Апр-26, 18:52 
>снизились почти в два раза

Будут исправлять, что ещё делать.
С другой стороны "enterprise" и так не побежит обновляться на свежие версии.

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

6. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +4 +/
Сообщение от Аноним (6), 04-Апр-26, 19:01 
Они дали совет из разряда "купите более мощный комп".
Ответить | Правка | Наверх | Cообщить модератору

7. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –1 +/
Сообщение от Аноним (7), 04-Апр-26, 19:02 
И вот такое вот мы несём в Ubuntu 26.04 LTS?
Ответить | Правка | Наверх | Cообщить модератору

11. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (1), 04-Апр-26, 19:08 
Будут ждать корректирующего выпуска 26.04.1
Ответить | Правка | Наверх | Cообщить модератору

12. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (1), 04-Апр-26, 19:10 
https://opennet.ru/64240-ubuntu
Ответить | Правка | Наверх | Cообщить модератору

46. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +7 +/
Сообщение от Sem (??), 05-Апр-26, 00:32 
Справедливости ради, много ли у вас серверов на архитектуре ARM64?
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

47. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –4 +/
Сообщение от Аноним (6), 05-Апр-26, 00:37 
Как бы даже в top500 есть на 7-ом месте.
Ответить | Правка | Наверх | Cообщить модератору

50. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Фняк (?), 05-Апр-26, 03:09 
Из разряда дать абсолютно верный, но бесполезный ответ. Кто в здравом уме на числодробилках из топ500 постгрес будет запускать?
Ответить | Правка | Наверх | Cообщить модератору

58. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +2 +/
Сообщение от Anoni (?), 05-Апр-26, 08:13 
В Амазоне большинство постгресов крутится на Гравитоне...
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

77. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (-), 05-Апр-26, 11:27 
> Справедливости ради, много ли у вас серверов на архитектуре ARM64?

У вас может и немного. А у гуглов-амазонов-тенсентов и кого там еще - их уже очень даже.

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

82. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Анонисссм (?), 05-Апр-26, 12:33 
>много ли у вас серверов на архитектуре ARM64?

на самом деле Ampere Altra Max M128-30 окуенные.
встречаются и у провайдеров VDS

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

105. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (105), 06-Апр-26, 07:09 
> на самом деле Ampere Altra Max M128-30 окуенные.

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

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

8. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (8), 04-Апр-26, 19:03 
Будет причина сервера обновить. Стандартный подход.
Ответить | Правка | Наверх | Cообщить модератору

10. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +4 +/
Сообщение от Tron is Whistling (?), 04-Апр-26, 19:08 
Так ядро не ухудшило работу и совместимость не сломало, надо править излишне заточенные на поведение ядра блокировки собственно.
Ответить | Правка | Наверх | Cообщить модератору

13. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –2 +/
Сообщение от Аноним (-), 04-Апр-26, 19:24 
Stable API is nonsence, короче.
Ответить | Правка | Наверх | Cообщить модератору

67. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Tron is Whistling (?), 05-Апр-26, 08:55 
А там где-то API изменилось, или я что-то пропустил?
Ответить | Правка | Наверх | Cообщить модератору

75. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (-), 05-Апр-26, 10:43 
В широком смысле. От ядра ожидается предсказуемое поведение вообще-то.
Ответить | Правка | Наверх | Cообщить модератору

83. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +2 +/
Сообщение от Tron is Whistling (?), 05-Апр-26, 13:02 
Так оно и предсказуемое: всё работает.
А вот то, что затюнили на конкретное микроповедение (тайминг), да ещё и конкретной платформы - ну это уже извиняйте, не проблемы ядра.
Ответить | Правка | Наверх | Cообщить модератору

97. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (-), 05-Апр-26, 22:41 
В два раза — это, извините, не «микро». Отдельно доставляет то, что ведь не какая-то поделка васяна с гитхаба отвалилась.
Ответить | Правка | Наверх | Cообщить модератору

102. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от анон (?), 06-Апр-26, 01:30 
Это про интерфейс между ядром и модулями, а не ядром и юзерспейсом.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

14. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +12 +/
Сообщение от Аноним (14), 04-Апр-26, 19:25 
В новости так расписано как PREEMPT_LAZY плохо влияет на постгрю, но при этом совсем не сказано для чего его добавляли и на что оно влияет позитивно.

The introduction of PREEMPT_LAZY was for multiple reasons:
- PREEMPT_RT suffered from over-scheduling, hurting performance compared to !PREEMPT_RT.
- the introduction of (more) features that rely on preemption; like folio_zero_user() which can do large memset() without preemption checks.
(Xen already had a horrible hack to deal with long running hypercalls)
- the endless and uncontrolled sprinkling of cond_resched()

Поэтому "решать" проблему через "вернуть по умолчанию режим PREEMPT_NONE" это фуфло. Ядро используется не только чтобы какие-то постри крутить. И они не должны быть приколачивать работу к дефолту.

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

52. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (52), 05-Апр-26, 03:29 
А почему не PREEMPT_DYNAMIC?
Ответить | Правка | Наверх | Cообщить модератору

74. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (74), 05-Апр-26, 09:54 
PREEMPT и всякие RT это абсурд на многоядерных системах.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

78. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (-), 05-Апр-26, 11:29 
> PREEMPT и всякие RT это абсурд на многоядерных системах.

Вообще-то PREEMPT_RT начиная с ядра 6.1 примерно дает именно RTOS'овые гарантии. Т.е что например на интервале X задача получит не менее Y процессорного времении.

И ядро прошло довольно длинный путь чтобы достичь этого состояния. Потому что это не столько про 1 ядро и несколько, сколько про шедулинг, начинку ядра, blocking и проч.

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

90. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (90), 05-Апр-26, 18:20 
Звукорежиссёры не согласны.
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

15. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от FSA (ok), 04-Апр-26, 19:43 
Отличные новости! Выявили! Значит исправят! Тем более даже у меня, на Fedora 44 до сих пор ядро 6.19. А другие дистрибутивы вообще более древние версии ядер используют. Так что когда они перейдут на версию 7.0 уже всё будет исправлено.
Вспоминается, как глючил переключатель раскладки в Windows. Он глючил в Windows 2000, XP... и даже в Vista.
Ответить | Правка | Наверх | Cообщить модератору

16. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (1), 04-Апр-26, 19:48 
>до сих пор ядро 6.19

А какие ещё были ?
https://www.kernel.org

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

17. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –1 +/
Сообщение от Аноним (17), 04-Апр-26, 20:10 
>А какие ещё были ?

Мог бы и сходить по своей то ссылке
mainline:     7.0-rc6     2026-03-29

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

18. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +3 +/
Сообщение от Аноним (1), 04-Апр-26, 20:19 
Ну ? Это же "RC" (release candidate).
"Linux 7.0 релиз которого ожидается 13 апреля".
Ответить | Правка | Наверх | Cообщить модератору

87. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (17), 05-Апр-26, 15:08 
>Ну ? Это же "RC" (release candidate).

Ну, терминалогические споры нас конечно заведут в метафизический тупик, но только сабжевых регрессий в ядрах 6.19 не будет.

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

35. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от dannyD (?), 04-Апр-26, 22:30 
>>до сих пор ядро 6.19

как бэ не совсем понятно - вы жалуетесь или хвастаетесь?

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

56. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (56), 05-Апр-26, 08:10 
В старых нету закладок.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

64. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Zloy (ok), 05-Апр-26, 08:33 
ничего никогда не глючило) Вообще выбор ядра зависит от требований, я перешел на линукс, когда увидел изменения в 6.19 которые мне были нужны. Не думаю, что стоит сразу перескакивать на новое ядро, обычно там много багов, которые обычные пользователи скорее всего не заметят.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

80. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от ShpurloS (?), 05-Апр-26, 11:53 
Так переключатель и в Windows 11 продолжает глючить.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

81. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от zionist (ok), 05-Апр-26, 12:08 
> даже у меня, на Fedora 44 до сих пор ядро 6.19

Fedora 44 ещё не вышла, у тебя максимум бета. А вот у меня на Fedora 43 ядро тоже 6.19 и со временем будет 7.0 ибо ядра тут обновляются всегда.

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

19. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +6 +/
Сообщение от eugener (ok), 04-Апр-26, 20:21 
Так это на arm, расходимся. Главное чтобы десктоп работал, а что там с БД — проблема сисадминов.
Ответить | Правка | Наверх | Cообщить модератору

21. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –1 +/
Сообщение от Аноним (1), 04-Апр-26, 20:30 
>Так это на arm

https://newsroom.ibm.com/2026-04-02-ibm-announces-strategic-...

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

34. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –10 +/
Сообщение от dannyD (?), 04-Апр-26, 22:28 
>>Так это на arm, расходимся. Главное чтобы десктоп работал....

Вы до сих пор на x86 ? Вам еще не приташнивает? Мне уже давно, еще до эплсиликон...

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

94. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Anonim (??), 05-Апр-26, 20:02 
Судя по минусам - местные эксперты ничего старше XP не видели ;)
Ответить | Правка | Наверх | Cообщить модератору

20. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +3 +/
Сообщение от Аноним (20), 04-Апр-26, 20:26 
>Perf profiling shows 55% of CPU time is consumed spinning in PostgreSQL's userspace spinlock (s_lock()) under PREEMPT_LAZY

если в постгресе запилили спинлок в юзерспейсе (на что намекает этот коммент), то они по умолчанию не правы. Не надо так делать.

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

43. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +2 +/
Сообщение от Аноним (43), 04-Апр-26, 23:59 
Ты прав. В юзерспейсе вообще не надо использовать ничего из того, что предоставляет ядро.
Ответить | Правка | Наверх | Cообщить модератору

22. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –7 +/
Сообщение от Аноним324 (ok), 04-Апр-26, 20:31 
> Пока не ясно какое решение примет Линус Торвальдс, который придерживается правила, что ядро не должно ухудшать работу и ломать совместимость с пространством пользователя.

Так он каждый релиз ядра её ухудшает, и вообще стейб апи из нонсенс.

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

23. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (23), 04-Апр-26, 20:36 
> Линус Торвальдс, который придерживается правила, что ядро не должно ухудшать работу и ломать совместимость с пространством пользователя.

Опять читаем новость не тем местом...

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

28. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +5 +/
Сообщение от Аноним (28), 04-Апр-26, 21:42 
Тут API не меняется. Вы, очевидно, не в курсе, что такое API.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

38. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (6), 04-Апр-26, 23:12 
Ещё как меняется:

> автор изменений, из-за которых возникла регрессия ... заявил, что исправление нужно вносить в код PostgreSQL. ... посоветовал задействовать ... недавно добавленное в ядро расширение "rseq slice"

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

42. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (28), 04-Апр-26, 23:53 
Даже слов не нахожу. Существующее API не изменилось. Как было так и осталось. Поменялись внутренние алгоритмы и добавилось новое API. Очевидно, вы никаком боком к разработке отношения не имеете.
Ответить | Правка | Наверх | Cообщить модератору

51. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Фняк (?), 05-Апр-26, 03:12 
Ты бы хоть открыл тот файлик, на который ссылаешься. Там про внутриядерный апи
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

59. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (56), 05-Апр-26, 08:16 
А ты что древние тексты читать умеешь
Ответить | Правка | Наверх | Cообщить модератору

24. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (24), 04-Апр-26, 20:36 
А потом наёдут грязные хаки в PostgreSQL, обходящие планировщик. 146%
Ответить | Правка | Наверх | Cообщить модератору

25. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от User (??), 04-Апр-26, 21:12 
Этот Питер он вот откуда? Тут серьёзные человеки из платиновых спонсоров сказали, что "регрессия", а всякие там с @infraded.org говорят что "и так сойдет" - сейчас ГЛАВНЫЙ разберется как следует и "с присущим ему своеобразием" примет ПРАВИЛЬНОЕ решение.
Ответить | Правка | Наверх | Cообщить модератору

26. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (26), 04-Апр-26, 21:25 
Можно выпустить и так, но добавится гемор строителям дистров, т.к. при установке PostgeSQL им придется капсом писать для пользователей, что для корректной работы нужно другая версия ядра с PREEMPT_NONE или самим включать PREEMPT_NONE по дефолту. Да и вообще может выясниться, что на PREEMPT_LAZY можно забить.
Ответить | Правка | Наверх | Cообщить модератору

60. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (56), 05-Апр-26, 08:19 
Поэтому Майки финансируют Генту. Они лучше знают что лучше.
Ответить | Правка | Наверх | Cообщить модератору

68. Скрыто модератором  +1 +/
Сообщение от Tron is Whistling (?), 05-Апр-26, 08:57 
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

79. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (-), 05-Апр-26, 11:31 
> нужно другая версия ядра с PREEMPT_NONE или самим включать PREEMPT_NONE

Блин, MSDOS поставьте - никто не будет вам preempt делать :)

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

36. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –14 +/
Сообщение от дворник (?), 04-Апр-26, 22:48 
Я так понимаю из-за этой шляпы сейчас "колбасит" (платежи не проходят, банкоматы наличку не дают) все банки, они-же с оракела переползли на постгри, и с интеля на арм.

сбербанка и втбанка, если читаете эту новость, напишите, что это не так.

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

37. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (1), 04-Апр-26, 22:54 
Погугли, узнаешь почему.
Ответить | Правка | Наверх | Cообщить модератору

39. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –1 +/
Сообщение от ПростойФермерДжон (?), 04-Апр-26, 23:15 
Не не так,  сочетании с телеметрией нового Firefox, и profile-sync-daemon 7, пропускная способность осталась такой же, вот только данные дико сливают, не то чтобы мне жалко, но жалко траффика, и ого, я смотрел iotop, в новом firefox, за минуту наверное метров 500 скачивает).
А да, точно, и все это на замечательном ядре 7.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

40. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (40), 04-Апр-26, 23:42 
А что там за телеметрия?В релизе 149 ничего такого указано не было.
Ответить | Правка | Наверх | Cообщить модератору

54. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от ПростойФермерДжон (?), 05-Апр-26, 06:17 
Карочи щас не помню, какой то процесс, именно телеметрия.
В iotop видно.
Пробовал в firefox tarball.
Те Firefox + Кеш + Какой то процесс именно телеметрия, отдельный, он непрерывно пишет на диск.
Тоесть даже если отключить кеш, то этот процесс еще больше пишет чем кеш. А ну да, версия 151.
Если оставить браузер, не листать интернет, то пишет непрерывно на диск, это уничтожает ресусрс ssd, ну и вообще номральн ли это, все равно что непрерывно копировать файлы в простое.
Ответить | Правка | Наверх | Cообщить модератору

62. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (62), 05-Апр-26, 08:29 
В последнюю версию ещё АИ добавили
Ответить | Правка | Наверх | Cообщить модератору

85. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (85), 05-Апр-26, 13:47 
Так а в чём проблема?

user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
user_pref("browser.newtabpage.activity-stream.telemetry", false);
user_pref("app.normandy.enabled", false);
user_pref("app.normandy.api_url", "");
user_pref("datareporting.policy.dataSubmissionEnabled", false);
user_pref("datareporting.healthreport.uploadEnabled", false);
user_pref("toolkit.telemetry.unified", false);
user_pref("toolkit.telemetry.enabled", false);
user_pref("toolkit.telemetry.server", "data:,");
user_pref("toolkit.telemetry.archive.enabled", false);
user_pref("toolkit.telemetry.newProfilePing.enabled", false);
user_pref("toolkit.telemetry.shutdownPingSender.enabled", false);
user_pref("toolkit.telemetry.updatePing.enabled", false);
user_pref("toolkit.telemetry.bhrPing.enabled", false);
user_pref("toolkit.telemetry.firstShutdownPing.enabled", false);
user_pref("toolkit.telemetry.coverage.opt-out", true);
user_pref("toolkit.coverage.opt-out", true);
user_pref("toolkit.coverage.endpoint.base", "");

Вот то, что каждые 5 секунд шебуршит жёсткими дисками, хотя никак их не касается, это отдельная проблема. Я долго думал, что это может быть запасной своп, но нет. Помогает убить контентные и гпу процессы.

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

41. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (1), 04-Апр-26, 23:43 
Что ?
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

45. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (45), 05-Апр-26, 00:13 
Да все так ты прав. Эта хрень снизила в два раза перформанс всех тг прокси. Особенно 2.0beta которая из официального докера вообще не запускается.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

65. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (62), 05-Апр-26, 08:34 
На Марс лети. Там нету блокировок интернета.
Ответить | Правка | Наверх | Cообщить модератору

53. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  –1 +/
Сообщение от Аноним (53), 05-Апр-26, 04:18 
и ютуб, ютую поломала еще... до того как вышла
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

69. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Tron is Whistling (?), 05-Апр-26, 09:00 
Правильное название такое: в спинлоках постгрыза выявлена проблема, приводящая к снижению производительности на ядре 7 и арм.
Ответить | Правка | Наверх | Cообщить модератору

71. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +1 +/
Сообщение от Аноним (71), 05-Апр-26, 09:06 
ядро внезапно стало честно выдавать ресурсы, нужные для выполнения бесконечного цикла)
Ответить | Правка | Наверх | Cообщить модератору

70. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (71), 05-Апр-26, 09:04 
в линуксе настолько всратый IPC, что накостылить детсадовский спинлок лучше, чем пользоваться мутексами, семафорами и т.п.?
Ответить | Правка | Наверх | Cообщить модератору

86. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +2 +/
Сообщение от Аноним (86), 05-Апр-26, 14:04 
Это, скорее, говорит о качестве кода в постгре
Ответить | Правка | Наверх | Cообщить модератору

72. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (71), 05-Апр-26, 09:09 
> Для устранения падения производительности он посоветовал задействовать в PostgreSQL недавно добавленное в ядро расширение "rseq slice" (Restartable Sequences) для ограничения вероятности вытеснения держателя блокировки.

Пока дилетанты разбираются с костылями, профессионалы вовсю орудуют подпорками для костылей.

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

73. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (74), 05-Апр-26, 09:50 
> Питер Зейлстра (Peter Zijlstra), автор изменений, из-за которых возникла регрессия, и мэйнтейнер планировщика задач и связанных с блокировками подсистем ядра, заявил, что исправление нужно вносить в код PostgreSQL.

Удалять PREEMPT_NONE идиотизм, а совет переделать постгре показывает уровень разраба.
Надеюсь Линус примет его стандартное в таким случаях решение.

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

84. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Tron is Whistling (?), 05-Апр-26, 13:03 
Если проблемы только у одной поделки - переделывать придётся её, такие дела.
Ответить | Правка | Наверх | Cообщить модератору

92. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (6), 05-Апр-26, 19:39 
> проблемы только у одной поделки

в винде таких регрессий нету.

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

91. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (91), 05-Апр-26, 18:57 
да там того спинлока 200 строк кода всего. поправят за чашкой чая.
Ответить | Правка | Наверх | Cообщить модератору

93. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от уп (?), 05-Апр-26, 19:47 
Учёный вновь изнасиловал журналиста.

https://lore.kernel.org/lkml/20260405144425.36044-1-kondo.mi.../

Проблема в конкретном коде Постгри для конкретной архитектуры.

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

95. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от zionist (ok), 05-Апр-26, 20:07 
Цитата от туда же:

So I agree that the patch to retain PREEMPT_NONE is the right approach.

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

96. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от уп (?), 05-Апр-26, 20:25 
Не апстрим следует даунстриму, а даунстрим следует апстриму.
Ответить | Правка | Наверх | Cообщить модератору

98. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от zionist (ok), 05-Апр-26, 23:23 
Причём тут это? Mitsumasa говорит, что правильным решением, по его мнению, является патч ядра, возвращающий PREEMPT_NONE по дефолту.
Ответить | Правка | Наверх | Cообщить модератору

101. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от уп (?), 06-Апр-26, 01:23 
> Причём тут это? Mitsumasa говорит, что правильным решением, по его мнению, является
> патч ядра, возвращающий PREEMPT_NONE по дефолту.

А я сказал, как должно быть.

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

99. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (99), 05-Апр-26, 23:38 
Во-первых то сообщение опубликовано уже после выхода новости. Во-вторых по вашей ссылке ерунда написана, которую уже раскритиковали:

https://lore.kernel.org/lkml/ccux4fgjcr626swwjwtdstxddkqjyxv.../

If I remove the rep nop on x86-64, the performance of the 4kB pages workload
is basically unaffected, even with PREEMPT_LAZY.

The spinning helps with workloads that are contended for very short amounts of
time. But that's not the case in this workload without huge pages, instead of
low 10s of cycles, we regularly spend a few orders of magnitude more cycles
holding the lock.

That's not to say the arm64 spin delay implementation is good. It just doesn't
seem like it affects this case much.

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

104. "В ядре Linux 7.0 выявили регрессию, в два раза снижающую про..."  +/
Сообщение от Аноним (104), 06-Апр-26, 05:27 
>Пока не ясно какое решение примет Линус Торвальдс, который придерживается правила, что ядро не должно ухудшать работу и ломать совместимость с пространством пользователя.

Правило хорошее, но каждый случай надо расматривать отдельно. Конкретно эта ситуация с PostgreSQL не является ломкой совместимости. Это другой случай.

>С одной стороны ядро 7.0 находится на финальной стадии тестирования перед релизом и откат настроек планировщика может привести к другим регрессиям, а с другой стороны пользователи могут столкнуться с двухкратным снижением производительности одной из самых популярных СУБД.

И это дополнительный причина к тому чтобы всё оставить как надо. Пусть разработчики PostgreSQL оптимизируют свой код. В данном случае, это проблема программистов из PostgreSQL.

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

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

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




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

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