The OpenNET Project / Index page

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

Анализ влияния на производительность выбранного в системе источника времени

28.09.2021 13:17

Брендан Грег (Brendan Gregg), один из разработчиков DTrace, ныне развивающий средства для анализа производительности на базе BPF в ядре Linux, обобщил опыт, полученный в ходе разбора проблем с производительностью, с которыми компания Netflix столкнулась в 2014 году при переводе СУБД Cassandra c CentOS на Ubuntu в окружениях, выполняемых в облаке Amazon EC2 на базе Xen. После миграции нагрузка на CPU увеличилась на 30% и примерно на столько же возросли задержки при выполнении операций записи. Как оказалось, производительность приложений, интенсивно запрашивающих информацию о времени, очень сильно зависит от выбранного в системе источника точного времени.

Вначале причина снижения производительности была не очевидна и диагностика началась с отслеживания возможного влияния постоянно работающих или периодически запускаемых ресурсоёмких системных процессов при помощи утилит top и execsnoop. Но всё указывало на то, что потребление ресурсов увеличилось именно в СУБД Cassandra, написанной на языке Java. Сравнение показателей профилирования двух процессов Cassandra, параллельно запущенных в CentOS и Ubuntu и обрабатывающих одни и те же запросы, показало, что около 32% всего времени тратится на вызов os::javaTimeMillis(), используемый для получения информации о текущем времени.

После этого был проведён эксперимент, в ходе которого было написано простое приложение на языке Java, в цикле вызывающее сто миллионов раз метод System.currentTimeMillis(). Запуск приложения показал, что в CentOS для его выполнения потребовалось 13 секунд, а в Ubuntu - около 68 секунд, т.е. в 5 раз медленнее. На языке Си была написана похожая программа, сто миллионов раз вызывающая функцию gettimeofday(), но при её выполнения были получены аналогичные результаты.

Так как стало ясно, что источником проблемы является функция возврата текущего времени, внимание переключилось на изменение показателей при выборе в системе разных источников точного времени. Судя по содержимому "/sys/devices/system/clocksource/clocksource0/current_clocksource" по умолчанию при запуске Linux в гостевой системе использовался таймер "xen". После изменения источника времени на "tsc" время выполнения тестового приложения в Ubuntu уменьшилось с 68 до 3.3 секунд, т.е. стало быстрее в 20 раз.


   $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
   xen tsc hpet acpi_pm

   $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
   xen

   $ time java TimeBench
   real    1m8.300s
   user    0m38.337s
   sys 0m29.875s

   $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource

   $ time java TimeBench
   real    0m3.370s
   user    0m3.353s
   sys     0m0.026s

Для получения времени при выборе источника TSC используется процессорная инструкция RDTSC, выполнение которой не требует совершение системного вызова (инструкция не требует повышенных привилегий и выдаёт значение из встроенного в CPU счётчика времени). По умолчанию TSC не активируется так как в былые времена данный источник не исключал постепенный дрейф времени, который в других обработчиках корректируется программно для достижения более точных показаний. По мнению инженера, специализирующегося на разработке процессоров, опасения о сдвигах времени при использовании TSC уже давно не соответствуют действительности и в современных процессорах данный источник может годы выдавать стабильные показания.

Перевод рабочих серверов в Netflix на источник TSC привёл к снижению задержек при записи на 43% и достижению при использовании Ubuntu результатов, превосходящих конфигурации с CentOS с источником времени "xen". Результаты проведённого исследования были переданы компании Amazon, которая официально рекомендовала в окружениях AWS EC2 на базе гипервизора Xen использовать по умолчанию источник времени TSC. В окружениях AWS EC2 на базе гипервизора Nitro остаётся рекомендован kvm-clock, но ранее проведённые тесты источника времени kvm-clock показывали снижение производительности на 20%, по сравнению с TSC.

  1. Главная ссылка к новости (http://www.brendangregg.com/bl...)
  2. OpenNews: Для Linux представлена система динамической отладки BPFtrace (DTrace 2.0)
  3. OpenNews: Сравнение производительности сетевого драйвера в вариантах на 10 языках программирования
  4. OpenNews: Эксперимент по настройке Linux для блокирования 10 млн пакетов в секунду
  5. OpenNews: Оптимизация Linux для обработки 1.2 млн JSON-запросов в секунду
  6. OpenNews: Компания Cloudflare подготовила патчи, кардинально ускоряющие дисковое шифрование в Linux
Лицензия: CC BY 3.0
Наводку на новость прислал Artem S. Tashkinov
Короткая ссылка: https://opennet.ru/55870-linux
Ключевые слова: linux, time, speed, tune, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (142) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:27, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    виртуализация она такая, да
     
     
  • 2.25, Аноним (25), 14:39, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Больше виртуализации. XEN, JVM я надеюсь они как-то хотя бы бизнес логику и тарифы скриптуют хотя бы через ScriptEngine

    А потом героический чиним таймеры =)

     
     
  • 3.85, Аноним (85), 17:30, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Исскусственный интеллект во всей красе!
     

  • 1.2, Аноним (2), 13:28, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    Брендану респект
     
     
  • 2.26, Аноним (25), 14:40, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И от меня. Тоже.
     

  • 1.3, Аноним (3), 13:33, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    Интересно и полезно. Спасибо.
     
  • 1.4, Аноним (4), 13:33, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >CentOS
    >Ubuntu

    Выходит, всё, Netflix уже не использует FreeBSD?

     
     
  • 2.6, A.Stahl (ok), 13:41, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Что значит не использует? Использует. В том же объёме как и последние 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют.
     
     
  • 3.15, Аноним (-), 14:01, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Готовишься к зиме, газифицируя лужи https news ycombinator com item id 285847... большой текст свёрнут, показать
     
  • 3.23, Михрютка (ok), 14:24, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>>последние 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют.

    это которые которые у них в CDN видео стримят по 400 Gb/s с хоста? зачотные маршрутизаторы, я тож такой хочу.

     
  • 3.82, aname (?), 17:18, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нетфликс- не твоя шарага, в которой есть то, что стрёмно трогать, потому что разобраться с этим некому, а ты не умеешь, а организация, в которой есть деньги и желающие поработать над решением задач.
     
     
     
    Часть нити удалена модератором

  • 5.114, Михрютка (ok), 23:50, 28/09/2021 [ответить]  
  • +5 +/
    однажды к Фрейду подошла дочка и сказала:
    - папа! мне сегодня снилось, как наш сосед герр Штольц показывает мне свой сервер. но у него был такой маленький пыльный сервер и непроизводительный и падал каждые пять минут! а потом я подошла к тебе и ты мне показал свой сервер, и он был такой большой, красивый и мощный и очень долго не падал...
    - дура! иногда сервер - это просто сервер! - оборвал дочку Фрейд.
     
  • 4.131, bOOster (ok), 10:06, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно, там прагматичный капитализм, и им дела нет до отмороженных фанатиков в принятии решения о смене FreeBSD на уг.. Так же как и центральное маршрутизируещее ядро в Амазон.
     
  • 2.8, Аноним (-), 13:45, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> при переводе СУБД Cassandra c CentOS на Ubuntu в окружениях, выполняемых в облаке Amazon EC2  на базе Xen
    >> выполняемых в облаке Amazon EC2  на базе Xen
    >>CentOS
    >>Ubuntu
    > Выходит, всё, Netflix уже не использует FreeBSD?

    "Избирательное чтение. Мастеркласс №2983 от опеннетных Пингвиняш."


     
  • 2.14, Михрютка (ok), 14:00, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    https://people.freebsd.org/~gallatin/talks/euro2021.pdf
     
     
  • 3.16, Аноним (4), 14:04, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Спасибо. Как же я был не прав...
     
     
  • 4.135, Аноним (135), 11:54, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для тех кто искал полный доклад:

    https://www.youtube.com/watch?v=_o-HcG8QxPc

    Обсуждение с автором доклада (drewg123):

    https://news.ycombinator.com/item?id=28584738

     

  • 1.5, _kp (ok), 13:39, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –19 +/
    Вот до чего доводит программирование с низким порогом мышления.
    Только что заметили элементарный тормоз. ;)
     
     
     
    Часть нити удалена модератором

  • 3.100, _kp (ok), 20:30, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >>просто никому не рассказывал и тихонечко посмеивался

    Ну как молчал? Писал.
    По началу возмущался, как так, я нашел какой то баг, а всем пофиг.
    Хотя, на многие замечания и багрепорты и сейчас некоторым глубоко пофиг.
    А когда железо было дохлое, что влияние подобных проблем всплывало быстрее, и эта тоже.

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

     
     
     
    Часть нити удалена модератором

  • 5.102, _kp (ok), 20:51, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/

    >  А знаешь, на что не пофиг? На патчи!
    > С дивана-то все умеют советы давать.

    И с патчами бывает... Вот в прошлом месяце поблагодарили в одном проекте за патч аж 2015 года. А поначалу послали. Кто там только в старье копался. :)
    Так не всегда, но для примера, вот.

    А по данной проблеме какой патч? Тут дело в культуре системостроения.

     
     
  • 6.132, пох. (?), 11:27, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А по данной проблеме какой патч?

    банальный - -откатывающий неведомое изменение в ведре между тем что было у центоси и тем что стало в бубунточке (скорее всего дело не в названии а в том что у бубунточки ведро банально на пять лет новее)

    Только вот некому выяснить, что это было за деструктивное изменение.


    Ну и другой банальный патч - исправляющий уродца кашмандра непонятно зачем дергающему таймер с миллисекундными интервалами.

    Только снова некому выяснить что это за нёх и переписать прямыми руками.

    Век тяпляперов.

     
     
  • 7.138, Михрютка (ok), 14:38, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и другой банальный патч - исправляющий уродца кашмандра непонятно зачем дергающему
    > таймер с миллисекундными интервалами.

    дяденька, если в базе есть поле timestamp, вы знаете другие способы получить его значение для инсерта/апдейта, кроме как gettimeofday сотоварищи?

     
     
  • 8.146, пох. (?), 16:20, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если дошло ажно до того что его дерганье тормозит инсерт - да, знаю не дергать ... текст свёрнут, показать
     
     
  • 9.147, Михрютка (ok), 17:04, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    хинт - его дерганье не увеличивало задержки при записи до миграции и перестало у... текст свёрнут, показать
     
     
  • 10.149, пох. (?), 10:36, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    кто сказал И по сравнению с чем увеличивало enlarge your what Оно просто с... текст свёрнут, показать
     
     
  • 11.150, Михрютка (ok), 12:27, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    да он сам и сказал вы его блог-то читали средний нетфликсовский подписчик до ... большой текст свёрнут, показать
     
     
  • 12.151, пох. (?), 12:35, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    то есть целое ОДНО видео в день а в целом так и должно - он же еще в этот день,... текст свёрнут, показать
     
     
  • 13.152, Михрютка (ok), 13:58, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    вы хоть обсарказмируйтесь ровно это изменит факт, что все действия пользователя... большой текст свёрнут, показать
     
     
  • 14.153, пох. (?), 14:05, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Блин, типовой пользователь за этот час не сделал ровно НИХ-Я Киношку он смотрит... большой текст свёрнут, показать
     
     
  • 15.154, Михрютка (ok), 15:17, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    и что все эти сорок минут время подключения и просмотра будут считать, с минутн... большой текст свёрнут, показать
     
     
  • 16.155, пох. (?), 15:24, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну ооок зачем мне читать про то как они все сделали через анус Я уже вон начит... текст свёрнут, показать
     
     
  • 17.158, Михрютка (ok), 17:46, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    та да, на целую ветку сферического трепа про незачем писать у вас время есть, ... текст свёрнут, показать
     
  • 2.27, Аноним (25), 14:43, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хочешь сказать, что качель экономии на инфраструктуре с дифицитом железа опять качнулась в сторону квалификации программистов?

    !()[https://cs6.pikabu.ru/images/big_size_comm/2014-07_6/14063731772929.jpg]

     
     
  • 3.120, Аноним (120), 00:14, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    404
     

     ....большая нить свёрнута, показать (16)

  • 1.9, Нанобот (ok), 13:46, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А каким образом запись в /sys/devices/system/clocksource влияет на способ получения времени обычным процессом? Ведь для получения данных через tsc нужно просто вызывать инструкцию (не обращаясь к ядру с его настройками clocksource), а в остальных случаях - делать syscall
     
     
  • 2.39, Anonnnym (?), 15:20, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    вызов из java в итоге прилетает в ядро, и оно в зависимости от настроек выбирает способ получения времени. Потеря производительности, которая осталась от перехода на Ubuntu как раз из-за того что дергается syscall, который дергает tsc, вместо прямого вызова tsc без переключения контекста
     
     
  • 3.40, Anonnnym (?), 15:21, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    возможно java дергает libc, а уже libc ядро, и тогда в centos прозводительность выше может быть, если в случае с использованием tsc, libc дергает его сама, не уходя в ядро
     
  • 2.47, Михрютка (ok), 15:33, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да нет, вы просто дернете gettimeofday, а тот дернет отмапленную в ваш юзерспейс из ядра функцию.
     
     
  • 3.156, _kp (ok), 15:34, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Главное не смущаться, что gettimeofday() - давно deprecated ;)
    И причины весьма схожие с этой темой, хотя и чуть иные.

    А в clock_gettime() явно указывается тип премени под смысл задачи.

     
     
  • 4.157, Михрютка (ok), 16:08, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Главное не смущаться, что gettimeofday() - давно deprecated ;)
    > И причины весьма схожие с этой темой, хотя и чуть иные.
    > А в clock_gettime() явно указывается тип премени под смысл задачи.

    и куда спрашивается крестьянину податься, если кассандра дергает javaTimeMillis, который реализован как-то так:




    jlong os::javaTimeMillis() {

      timeval time;

      int status = gettimeofday(&time, NULL);

      assert(status != -1, "linux error");

      return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);

    }



     
  • 4.160, Аноним (160), 04:47, 01/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А в clock_gettime() явно указывается тип премени под смысл задачи.

    Тип времени и способ получения времени — это разные вещи.

     
     
  • 5.164, _kp (ok), 13:04, 04/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> А в clock_gettime() явно указывается тип времени под смысл задачи.
    > Тип времени и способ получения времени — это разные вещи.

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

     

  • 1.10, Аноним (10), 13:47, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А что насчёт kvm-clock?
     
     
  • 2.37, Moomintroll (ok), 15:13, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А что насчёт kvm-clock?

    А прочитать новость до конца?

    > Дополнительно был проведён тест производительности источника времени kvm-clock, который показал увеличение задержек на 20%, по сравнению с TSC.

     
     
  • 3.65, Михрютка (ok), 16:22, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    эту новость не надо читать до конца, ее надо сразу в печку.

    > Дополнительно был проведён тест производительности источника времени kvm-clock, который показал увеличение задержек на 20%, по сравнению с TSC.

    things have changed with Nitro where clocksources are much faster (thanks!). In 2019 myself and others tested kvm-clock and found it was only about 20% slower than tsc.

    это вообще про тесты двухлетней давности, 2019, на kvm-based гипере. а сейчас^W Грегг делится опытом, как мерял производительность под зиной в 2014 году.

    PS я тож блин внимательный

     

  • 1.13, Урри (ok), 13:55, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ошибка!

    > Для получения времени при выборе источника TSC используется процессорная инструкция RDTSC, выполнение которой не требует совершение системного вызова (инструкция не требует повышенных привилегий и выдаёт значение из встроенного в CPU счётчика времени).

    RDTSC считает такты процессора с момента его включения (причем не гарантируется, что это именно такты; гарантируется, что этот счетчик монотонно возрастает). Никакого системного времени rdtsc не дает!

    https://en.wikipedia.org/wiki/Time_Stamp_Counter

     
     
  • 2.28, Ordu (ok), 14:43, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Читай внимательнее Константная частота тиков делает из rdtsc именно что часы, в... большой текст свёрнут, показать
     
     
  • 3.80, Урри (ok), 17:13, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, действительно. Мои данные устарели.
    Сходил проверить в интеловский мануал. Пишут буквально следующее:

    17.17.1 Invariant TSC
    The time stamp counter in newer processors may support an enhancement, referred to as invariant TSC.
    Processor’s support for invariant TSC is indicated by CPUID.80000007H:EDX[8].
    The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states. This is the architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition or access to a platform resource.

     
  • 2.34, Аноним (34), 14:55, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Больше похоже на то, что для XEN либо не реализовано vDSO, либо сам таймер кривой.
     
     
  • 3.36, Михрютка (ok), 15:11, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    если б не было, как бы они получили выигрыш во времени при переходе на tsc.

    strace смотреть надо

     

  • 1.17, Аноним (17), 14:05, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Там вроде PIT самый надёжный и производительный, давайте вернёмся во времена хрюши. Только от многоядерности придётся отказаться, PIT работает с 1 ядром. И 32 бита заодно возродите. А hpet это отдельный кварц на плате, чё не используете? Он хотя бы стабильный, TSC слишком рандомный (и под нагрузкой результаты будут отличаться).
     
     
  • 2.24, Аноним (24), 14:31, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    - HPET тормозит на большом числе ядер под Intel, снижает fps в играх
    - Если отключить HPET под linux можно наблюдать деградацию в Windows-госте https://kb.vmware.com/s/article/67175
     
     
  • 3.52, Anon from Mars (?), 15:47, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >  HPET тормозит на большом числе ядер под Intel, снижает fps в играх

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

    Естественно под WINE этой проблемы не было, что вообще сначала сбило с толку, но дало почву для дальнейшего разбирательства.

     
     
  • 4.54, Аноним (54), 15:53, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Но это проблема известна только для Intel. В AMD она в самом начале была исправлена и включение/выключение не влияет на скорость.
     
     
  • 5.162, Бывший АМДшник (?), 03:05, 04/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В какой ещё AMD?

    Что я точно знаю о таймерах у АМД, так это то, что рассинхронизация в многоядерных процессорах у них просто катастрофическая!

    Думаешь, они что-то сделали, чтобы исправить выпускаемое ими оборудование? - Ничего не сделали.

    Зато приложили все усилия чтобы скрыть этот и другие недостатки: выпустили "AMD Dual Core Optimizer", который под видом "оптимизации" переключал таймер тупо на самый медленный, и убогий,  ограниченный на точности в 64 раза в секунду...

    AMD - это бракоделы, и всегда ими были. Факт.

     
     
  • 6.166, Смузи (?), 19:49, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Я говорил в контексте Zen
    Про существование более старых я никогда не слышал и не видел их.
     
  • 5.165, Смузи (?), 19:49, 12/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Я говорил в контексте Zen, про существование более старых архитектур я не слышал и не видел их никогда.
     
  • 3.159, Аноним (54), 04:24, 01/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    + https://kb.vmware.com/s/article/1591
     
  • 2.51, Аноним (54), 15:39, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://deeperf.com/2019/04/30/tsc-clock-missing-caused-performance-issues/
     
  • 2.123, Аноним (123), 02:39, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Открой для себя Windows XP Professional x64 Edition на базе ядра Windows Server 2003 x64. Кто-то уже 20 лет как забыл про 32 бита даже на винде.
     
     
  • 3.124, Аноним (17), 02:54, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я не уверен, что это имеет смысл, потому что все программы того времени 32 бита. Довольно неэффективно. Чтобы использовать больше 3гб памяти в обычной икспи можно просто положить своп на виртуальный диск в невидимой памяти. Но там ещё были PAE ядра, если хочется.
     

  • 1.18, Аноним (18), 14:09, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А что насчёт Spectre с источником TSC?
     
  • 1.19, Аноним (19), 14:12, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Вопрос, зачем переходили на лагучую бунту?
     
     
  • 2.22, Аноним (22), 14:18, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А зачем платить за дорогущий Red Hat или переходить на нестабильный CentOS Stream?
     

  • 1.21, Аноним (22), 14:17, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Самое главное из новости что из-за выкрутасов компании IBM с CentOS нормальные компании стали перебираться на Ubuntu и попутно фиксить баги. Что есть гуд.
     
     
  • 2.31, Аноним (25), 14:47, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну значит в ряды OpenSource прибыло! Теперь Ubuntu через лет 20 перестанет быть синонимом глючного барахла.
     
     
  • 3.42, Аноним (22), 15:26, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Его к тому времени уже продадут.
     
  • 2.41, Anonnnym (?), 15:26, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так ведь ничего не пофиксили. Бубунта как тормозила так и продолжила тормозить, просто теперь на другом счетчике. Тормоза с которым для Netflix не критичны.

    А сам этот счетчик был и раньше

     
     
  • 3.43, Аноним (22), 15:28, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тормозить запуска базы данных, ты серьёзно? Ты часто базу перезапускаешь? Тебе бы голову для начала подлечить.
     
     
  • 4.44, Anonnnym (?), 15:29, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тормозить запуска базы данных, ты серьёзно? Ты часто базу перезапускаешь? Тебе бы
    > голову для начала подлечить.

    Она тормозит на вызове счетчика. Работает в 5 раз медленнее, чем CentOS

     
     
  • 5.63, Аноним (22), 16:09, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже оригинал статьи на английском почитай.
     

  • 1.30, Аноним Анонимович Анонимов (?), 14:47, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    > компания Netflix столкнулась при переводе СУБД Cassandra c CentOS на Ubuntu в окружениях, выполняемых в облаке Amazon EC2 на базе Xen
    > Запуск приложения показал, что в CentOS для его выполнения потребовалось 13 секунд, а в Ubuntu - около 68 секунд, т.е. в 5 раз медленнее

    Под xen Ubuntu в 5 раз медленнее.

    > Интересно, что после смены источника времени на TSC (Time Stamp Counter) производительность одинаково возросла в CentOS и Ubuntu, но относительно CentOS запуск в Ubuntu по-прежнему остался в 5 раз медленнее (0.13 против 0.68 мкс)

    По прежнему Ubuntu в 5 раз медленнее.

    > Перевод рабочих серверов в Netflix на источник TSC привёл к снижению задержек при записи на 43% и достижению при использовании Ubuntu результатов, превосходящих конфигурации с CentOS с источником времени "xen".

    Время увлекательных историй.

     
     
  • 2.45, Аноним (22), 15:29, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Одинаково возросла. Запуск в Убунте остался таким же медленным. Вы троллите все или читать не умеете?
     
     
  • 3.48, Anonnnym (?), 15:34, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Одинаково возросла. Запуск в Убунте остался таким же медленным. Вы троллите все
    > или читать не умеете?

    Это ты читать не умеешь.

    Было: CentOS со счетчиком xen
    Стало: Ubuntu со счетчиком xen

    Проблема: После перехода на Ubuntu вызов счетчика стал в 5 раз медленнее, что снизило производительность на 30%

    Решение: Перешли на счетчик tsc, что повысило производительность на 43%

    Сравнение Ubuntu со счетчиком tsc с CentOS со счетчиком tsc показало, что вызов счетчика все еще медленнее в 5 раз, но т.к. теперь все работает быстро, то на это забили.

    Выводы в новости конечно эпичные: Ubuntu со счетчиком tsc быстрее CentOS со счетчиком xen. А сверхзвуковой самолет быстрее тролейбуса из буханки хлеба.

     
     
  • 4.62, Аноним (22), 16:08, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оригинал почитай переводчик всё врёт.
     
     
  • 5.99, Anonnnym (?), 20:20, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Оригинал почитай переводчик всё врёт.

    Почитал, в оригинале вообще все по другому с момента смены счетчика. Мб переводчик - ИИ, который учится дописывать статьи и ему скормили только часть? Есть же ИИ который генерирует названия.

     
  • 2.143, Stax (ok), 15:13, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что есть энтерпрайз, а есть игрушки :)

    Можно немного сэкономить денег, выбрав игрушку, но за это придется платить производительностью/стабильностью во всяких хитрых ситуациях типа этой (а простые десктопные тесты, конечно, ничего подобного не покажут)

    Дело ведь не в xen vs tsc. Дело в том, что в РХ реально хорошие инженеры с нормальной зарплатой анализируют разные ситуации, находят скользкие моменты и внедряют решения, по возможности до того, как основная масса клиентов на этом наколется. А в убунте в таких масштабах этим никто не занимается.

     
     
  • 3.148, пох. (?), 07:20, 30/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В 2014м году в RH "инженегры" уже так же улыбались и махали хвостами с веток, как и сегодня.

    100% индусская контора, с неработавшей уже тогда техподдержкой и ключевыми проектами, отданными на аутсорс в Бангалор или вообще купленными прям там в бангалоре.

    Хорошие кончились изрядно раньше, лучшие из худших как раз тогда уже сваливали в microsoft - но инерции еще хватало.

    А в убунте точно такие же. Прыгают по веткам, что-то верещат...


     

  • 1.32, Аноним (32), 14:50, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В python похожая беда между datetime.now() и datetime.today()
     
  • 1.35, YetAnotherOnanym (ok), 14:58, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > данный источник не исключал постепенный дрейф времени

    Даже если так, пнуть его раз в секунду или реже, чтобы поправить набежавший дрейф - разве это не даст экономию при >9000 обращений в секунду?

     
     
  • 2.92, n00by (ok), 18:27, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В ядре всё уже отпинано за нас, выглядит это так:

    tsc: Marking TSC unstable due to clocksource watchdog
    clocksource: Switched to clocksource hpet

     
     
  • 3.98, Аноним (54), 20:01, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Intel CoffeeLake уже запрещает hpet из коробки черным списком ядра
     
     
  • 4.104, n00by (ok), 21:01, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Смысл в том, что если счётчик признан нестабильным, он заменяется на менее точный.
     

  • 1.38, Anonnnym (?), 15:16, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А на самое интересное хер забили. Ubuntu как работала в 5 раз медленнее с xen, так и работает в 5 раз медленнее с tsc. Новость о том, что tsc без переключения контекстов работает быстрее чем xen с переключением контекстов. Но зачем она такая нужна, и зачем было сообщать о том, что убунта медленнее, раз причину не стали искать?
     
     
  • 2.55, Аноним (22), 15:54, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это какой-то глюк переводчика числа 0.13 и 0.68 приводятся для состояния до смены источника времени https://www.brendangregg.com/blog/2021-09-26/the-speed-of-time.html параграф 6

     
     
  • 3.111, evk (??), 22:54, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    нифига. В оригинале тоже никто не стал искать причину, почему с xen Ubunta медленне
    И никто не проверил что будет если в CentOS поставить tsc
    В общем новость о том что Ubunta медленее, но всем лень разбираться почему
     
     
  • 4.117, Аноним (117), 23:58, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты сам выгораживаешь Цент. Просто Цент был правильнее настроен и там сразу был tsc по дефолту
     
     
  • 5.126, evk (??), 08:26, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А прочитать? Там четко сказано что в CentOS тоже xen
     

  • 1.49, Аноним (54), 15:37, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > По умолчанию TSC не активируется так как в былые времена данный источник не исключал постепенный дрейф времени, который в других обработчиках корректируется программно для достижения более точных показаний.

    Для решения многих проблем рекомендуется фиксирование потока на конкретном процессоре (cpu affinity) и отключение технологий автоматического изменения частоты (технологий энергосбережения и динамического изменения производительности).

     
  • 1.50, Аноним (50), 15:37, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    парни, я правильно понимаю, для железных серверов надо использовать процессорный таймер, который hpet?
     
     
  • 2.53, Аноним (54), 15:48, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не правильно, этот таймер можно включать но не использовать по-умолчанию для хоста. Хоть этот кварц и дороже, RDTSC поддерживает на аппаратном уровне в кажом ядре ЦПУ со значительно низкими задержками.

    Если сервер старый выбирай сам.

     

  • 1.56, Михрютка (ok), 15:54, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >How long is each time call? Assuming the loop is dominated by the time call, it works out to be about 0.13 us on Centos and 0.68 us on Ubuntu.
    >Запуск приложения показал, что в CentOS для его выполнения потребовалось 13 секунд, а в Ubuntu - около 68 секунд

    надмозги за работой

     
     
  • 2.59, Аноним (22), 15:59, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тут нужен переперевод. Это время до смены источника времени. А переводчик пишет про 13 секунд и 68 секунд для состояния до смены источника. А 13 мкс и 68 мкс после смены источника времени.

    Я уже запутался, но кто-то умный должен распутать этот клубок лжи.

     
     
  • 3.64, Михрютка (ok), 16:15, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а птушо автор новости - надмозг вот чо пишет Грегг Let s try tsc, which should ... большой текст свёрнут, показать
     
     
  • 4.78, Аноним (78), 17:05, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > вот чо пишет Грегг

    Глянь чуть выше в тексте, конкретно значения real в бенчмарках.

     
     
  • 5.84, Михрютка (ok), 17:26, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    внимательнее читайте камент, на который отвечаете.

     
  • 2.77, Аноним (78), 17:04, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Прочитай оригинал внимательнее, в новости процитировано время из этих измерений

    Trying it out:

    centos$ time java TimeBench
    real    0m12.989s
    user    0m3.368s
    sys 0m18.561s

    ubuntu# time java TimeBench
    real    1m8.300s
    user    0m38.337s
    sys 0m29.875s


    real - это как раз 13 и 68 секунд (1 минута + 8 секунд). Не удивительно, что упоминается и  0.13 и 0.68, ведь число итераций кратно 10.

     
     
  • 3.83, Михрютка (ok), 17:24, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    вы это всерьез называете цитированием?

    пока мы беседуем, автор хоть лажу с "запуск в Ubuntu по-прежнему остался в 5 раз медленнее (0.13 против 0.68 мкс)" поправил.

    еще бы он отметил, что речь идет о тестах 7-летней давности, и вообще даты ставил там, где это существенно, цены бы ему не было.

     
     
  • 4.88, Аноним (22), 18:08, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Причем при микросекунды писалось в исходном тексте. А про секунды это автор вывел сам. Очередное: «Учёный изнасиловал журналиста»
     
  • 3.87, Аноним (22), 17:57, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так это до изменения источника времени, а не после. Так что будет после и кто в итоге быстрее с tsc цент или убунту осталось в тайне. Или цент с xen быстрее чем убунту с tsc. Или у цента по дефолту стоит tsc и убунту с tsc быстрее цента в 4 раза. Xen его разберет.

    Бывает статьи, которые в себе содержать больше вопросов чем ответов.

     
     
  • 4.116, Михрютка (ok), 23:58, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    товарищ, если вы не заметили, Грегг не Мишенька с похороникса.

    Грегг не тестировал производительность сентос vs бубунта.

    Грегг траблуштил продуктивный кластер. затык он нашел и воркароунд поставил. поделился опытом с нами.

     
     
  • 5.128, пох. (?), 09:31, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну и заодно ненавязчиво в очередной раз порекламировав ненужноtrace.

    Уровень впопен.... ой, простите - уровень современной IT.

    Костылинг, пердолинг, ради костылинга и пердолинга. Реверс-инженеринг собственного и открытого софта ради костылинга. Любая проблема решается тем молотком, который надежно приклеен скотчем к рукам.

    А почему бубунта тормозит - разбираться некогда, менеджер с кнутом не ждет!

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

     
     
  • 6.144, Михрютка (ok), 15:24, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А почему бубунта тормозит - разбираться некогда, менеджер с кнутом не ждет!

    действительно.

    бездельник из нетфликса решает проблемы нетфликса. да еще в рабочее время!

    нет чтоб помочь каноникалу (на самом деле амазону).

     
     
  • 7.145, пох. (?), 16:10, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    проблему которую сам же себе и создал. Ну да. Инвестору-то такие вещи все равно без разницы.

    > нет чтоб помочь каноникалу (на самом деле амазону).

    на самом деле людям. Но им тоже незачем. Они не заплатят.

    Собственно, вторая история, с "400G ненужного шифрования с freebsd" еще эпичнее. В смысле там вообще неимоверными усилиями (включая вендоров) добились ненужно через ненужно.

    Ну а чотакова, деньги инвестора сами себя не попилят.

     

  • 1.58, Аноним (58), 15:56, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Про HPET чудо программеры и не слышали.
     
     
  • 2.60, Аноним (54), 16:03, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https access redhat com solutions 18627 High Precision Event Timer HPET The ... большой текст свёрнут, показать
     

  • 1.61, пончик (?), 16:06, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А если убрать java то будет ещё быстрее.
     
     
  • 2.69, Интернет_Герой (?), 16:34, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> На языке Си была написана похожая программа, сто миллионов раз вызывающая функцию gettimeofday(), но при её выполнения были получены аналогичные результаты.
     
     
  • 3.109, Аноним (109), 22:27, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вопрос в том, зачем джава стомиллионов раз получает время;)
     

  • 1.66, Вадик (??), 16:24, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уберите пробел!
    > cat /sys/devices/system/clocksource/clocksource0 /available_clocksource
     
     
  • 2.73, Аноним (73), 16:48, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    запоминиается простое: переход возможен, игра режимами на рабочих системах - это созидание.
     

  • 1.68, Аноним (68), 16:30, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Но почему

    > относительно CentOS запуск в Ubuntu в 5 раз медленнее

    осталось не известно.

     
     
  • 2.71, Аноним (22), 16:44, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Логические связи в переводе утеряны. В оригинале Убунту стала быстрее в 4 раза Цента

    >> The change is immediate, and my Java microbenchmark is now running over 20x faster than before! (And nearly 4x faster than on CentOS.) Now that it's reaching 33 ns, the loop instructions are likely inflating this result. If I wanted more accuracy, I'd partially unroll the loop so that the loop instructions become negligible.

     
     
  • 3.72, Аноним (22), 16:46, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Прям хоть сам перепроверяй и перебенчмаркивай.
     
  • 3.112, evk (??), 23:01, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ТОлько похоже имелось в виду Ubunta tsc быстрее CentOS xen
    А ответа почему Ubunta xen vмедленне CentOS xen никто не дал.
    И четкого ответа про Ubunta tsc и CentOS tsc тоже
    Вообще автор правильно постеснялся это выложить в общий доступ сразу.
    Похоже со временем порог критического восприятия сильно упал.
     
     
  • 4.115, Аноним (117), 23:57, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется что Цент из коробки шел с настроенным tsc. А в Убунте оставили xen для совместимости или не тестировали. Потому что Амазон внес правки только в убунту
     

  • 1.70, rm2 (?), 16:44, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > 32% всего времени тратится на вызов os::javaTimeMillis(), используемый для получения информации о текущем времени.

    Осталось неясным, зачем эта хрень прям столько раз это вызывает. Вроде бы в процессе выполнения запросов к БД текущее время может понадобиться только ради дебага (профайлинга), а в продакшене он должен быть отключён.

     
     
  • 2.74, Михрютка (ok), 16:52, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> 32% всего времени тратится на вызов os::javaTimeMillis(), используемый для получения информации о текущем времени.
    > Осталось неясным, зачем эта хрень прям столько раз это вызывает. Вроде бы
    > в процессе выполнения запросов к БД текущее время может понадобиться только
    > ради дебага (профайлинга), а в продакшене он должен быть отключён.

    в БД иногда еще пишут.

    >>>Cassandra database cluster had switched to Ubuntu and noticed write latency increased by over 30%

     
  • 2.129, пох. (?), 09:35, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, ни дтрейс ни bpf неспособны дать ответ 'что обезьянка наобезьянкала в громадном нечеловекочитаемом жабапрожекте или притащила в него в виде готовой библиотеки' - а автор мегаисследования - больше ничего не умел.

    Ну или ему за это не только не платили, но больно п-дили по рукам лопатой, чтоб не лез не в свое дело. Сказано тебе "настроить бубунту чтоб было как в проклятом редхате но денег никому не платить" - выполняй, БЕГОМ!

     

  • 1.76, Штунц (?), 16:59, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    пару лет назад читал статью, так там во много раз ускоили выполнение JAVA программ, заменив источник случайных чисел
     
     
  • 2.90, Аноним (22), 18:08, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Бенчу из статьи 7 лет. Там уже и джава по другому работает небось.
     

  • 1.79, sdkhflskhgl (?), 17:10, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    а как они синхронизировали TSC на разных процессорах? там же разные значения могут быть... или они аффинити зажали на один кристалл?
     
     
  • 2.161, Аноним (160), 04:52, 01/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Время вычисляет ядро, а оно видит все процессоры.
     

  • 1.81, Аноним (81), 17:18, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно
     
  • 1.89, Аноним (89), 18:08, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Вот, рекомендую
    cryptdevice=UUID=.....:label:allow-discards,no-read-workqueue,no-write-workqueue clocksource=tsc

    (не для desktop/secure/virtal-server)
    nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off

    intelHD
    i915.fastboot=1 i915.enable_guc=2 i915.enable_fbc=1

    /etc/crypttab
    ...
    luks-{..uuid..} UUID={..uuid..} none luks,discard,noauto,no-read-workqueue,no-write-workqueue
    ...

    Ссылки
    https://www.opennet.dev/opennews/art.shtml?num=55186
    https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
    https://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_in)_performance
    https://deeperf.com/2019/04/30/tsc-clock-missing-caused-performance-issues/

     
     
  • 2.91, Аноним (22), 18:16, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Единственный полезный коммент ко всей этой старой статье.
     
  • 2.121, Alladin (?), 00:43, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучше еще добавить mitigations=off
     

  • 1.106, Онаним (?), 22:12, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Потыстировал на узком цикле с clock_gettime(CLOCK_MONOTONIC).
    В tsc_mode=1 clocksource xen от clocksource tsc отличается % так на 10 (эмулируемый tsc выигрывает, как ни странно).
    А tsc_mode=2 уже ссыкотно, потому что железо может с tsc косячить.
     
     
  • 2.107, Онаним (?), 22:13, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Но сама проблема есть, если воткнуть clocksource hpet, производительность тестового цикла падает в 2.5 раза...
     

  • 1.108, Аноним (108), 22:20, 28/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Надо аппаратно ускоренный источник времени в виде отдельной платы. Чтоб убунта летала.
     
     
  • 2.110, Аноним (54), 22:50, 28/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Очень глупая идея, где нужны очень низкие задержки...
     
  • 2.119, Аноним (117), 00:00, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда можно время просто не запрашивать просто прибавлять какой-нибудь счетчик в оперативе и все.
     
  • 2.125, Crok (?), 06:01, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Уже сделали, проверяйте: HPET 😃
     
     
  • 3.139, Аноним (54), 15:04, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    HPET устаревший.

    Intel не рекомендует использовать этот аппаратный кварцевый таймер южного моста. HPET снижет эффективность выполнения на многоядерных системах. 10 MHz хуже чем таймеры счетчиков в ядрах процессора.

     
  • 3.141, Аноним (54), 15:08, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В современных процессорах Intel, TSC зависит от индивидуальной частоты процессор... большой текст свёрнут, показать
     

  • 1.122, yamlcoder (?), 00:53, 29/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Later that year I prototyped the c2 frame pointer fix that became -XX:+PreserveFramePointer, which fixes Java stacks in these profiles

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

     
     
  • 2.130, пох. (?), 09:39, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Глубины копания под фонарем, потому что там светлее?

    Проблема, ежу понятно - что-то сломали в ядре/glibc/где-то рядом.
    Но ее искать некому, некогда и вообще, так можно починить что-то конкурентам.

    Давайте патчить jvm!

     
     
  • 3.137, Михрютка (ok), 14:26, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну да, когда у меня rhel6 под hyperv время не держал совсем, то есть вообще, это же однозначно было от того, что сломали ядро или глибцэ.

    а не потому, что hyperv на tsc клал.

     
  • 2.134, Аноним (134), 11:44, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В C# такого нет.
     

  • 1.127, Anonim (??), 08:39, 29/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ubuntu 19-20. Tsc as default.
     
     
  • 2.133, Аноним (134), 11:35, 29/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Статья 2014 года в лучшем случае Убунту 14.04 и правки сделали уже тогда причем сам амазон просто поправил свой образ и всё.
     

  • 1.163, Линус не Торвальдс (?), 03:34, 04/10/2021 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     

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



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

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