| |
| 2.25, Аноним (25), 14:39, 28/09/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Больше виртуализации. XEN, JVM я надеюсь они как-то хотя бы бизнес логику и тарифы скриптуют хотя бы через ScriptEngine
А потом героический чиним таймеры =)
| | |
|
| |
| 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 от опеннетных Пингвиняш."
| | |
|
| 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 +/– | Если дошло ажно до того что его дерганье тормозит инсерт - да, знаю не дергать ... текст свёрнут, показать | | |
| |
| |
| |
| |
| 12.151, пох. (?), 12:35, 30/09/2021 [^] [^^] [^^^] [ответить] | +/– | то есть целое ОДНО видео в день а в целом так и должно - он же еще в этот день,... текст свёрнут, показать | | |
| |
| |
| 14.153, пох. (?), 14:05, 30/09/2021 [^] [^^] [^^^] [ответить] | +/– | Блин, типовой пользователь за этот час не сделал ровно НИХ-Я Киношку он смотрит... большой текст свёрнут, показать | | |
| |
| |
| 16.155, пох. (?), 15:24, 30/09/2021 [^] [^^] [^^^] [ответить] | +1 +/– | ну ооок зачем мне читать про то как они все сделали через анус Я уже вон начит... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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() явно указывается тип времени под смысл задачи.
> Тип времени и способ получения времени — это разные вещи.
Конечно. Но неправильный выбор типа времени, так же плодит неочевидные эффекты, и влияет на производительность.
И раз начали разбираться с проблемами времени, то счел необходимым заодно напомнить.
| | |
|
|
|
|
| |
| 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 слишком рандомный (и под нагрузкой результаты будут отличаться).
| | |
| |
| |
| 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, про существование более старых архитектур я не слышал и не видел их никогда.
| | |
|
|
|
| 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 ядра, если хочется.
| | |
|
|
| |
| 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 перестанет быть синонимом глючного барахла.
| | |
| 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
| | |
|
|
|
| 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. А сверхзвуковой самолет быстрее тролейбуса из буханки хлеба.
| | |
| |
| |
| 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.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 с переключением контекстов. Но зачем она такая нужна, и зачем было сообщать о том, что убунта медленнее, раз причину не стали искать?
| | |
| |
| |
| 3.111, evk (??), 22:54, 28/09/2021 [^] [^^] [^^^] [ответить]
| +/– |
нифига. В оригинале тоже никто не стал искать причину, почему с xen Ubunta медленне
И никто не проверил что будет если в CentOS поставить tsc
В общем новость о том что Ubunta медленее, но всем лень разбираться почему
| | |
| |
| 4.117, Аноним (117), 23:58, 28/09/2021 [^] [^^] [^^^] [ответить]
| +/– |
Это ты сам выгораживаешь Цент. Просто Цент был правильнее настроен и там сразу был tsc по дефолту
| | |
|
|
|
| 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 в бенчмарках.
| | |
|
|
| 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" еще эпичнее. В смысле там вообще неимоверными усилиями (включая вендоров) добились ненужно через ненужно.
Ну а чотакова, деньги инвестора сами себя не попилят.
| | |
|
|
|
|
|
|
| |
| 2.60, Аноним (54), 16:03, 28/09/2021 [^] [^^] [^^^] [ответить] | +/– | https access redhat com solutions 18627 High Precision Event Timer HPET The ... большой текст свёрнут, показать | | |
|
| |
| 2.69, Интернет_Герой (?), 16:34, 28/09/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>> На языке Си была написана похожая программа, сто миллионов раз вызывающая функцию gettimeofday(), но при её выполнения были получены аналогичные результаты. | | |
|
| 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.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 на разных процессорах? там же разные значения могут быть... или они аффинити зажали на один кристалл?
| | |
| 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.ru/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/
| | |
| 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.119, Аноним (117), 00:00, 29/09/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тогда можно время просто не запрашивать просто прибавлять какой-нибудь счетчик в оперативе и все.
| | |
| |
| 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.133, Аноним (134), 11:35, 29/09/2021 [^] [^^] [^^^] [ответить]
| +/– |
Статья 2014 года в лучшем случае Убунту 14.04 и правки сделали уже тогда причем сам амазон просто поправил свой образ и всё.
| | |
|
|
