forum.opennet.ru - "Анализ влияния на производительность выбранного в системе источника времени" (142)

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

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

"Анализ влияния на производительность выбранного в системе источника времени"	+/–
Сообщение от opennews (??), 28-Сен-21, 13:27
Брендан Грег (Brendan Gregg), один из разработчиков DTrace, ныне развивающий средства для анализа производительности на базе BPF в ядре Linux, обобщил опыт, полученный в ходе разбора проблем с производительностью, с которыми компания Netflix столкнулась при переводе СУБД Cassandra c CentOS на Ubuntu в окружениях, выполняемых в облаке Amazon EC2 на базе Xen. После миграции нагрузка на CPU увеличилась на 30% и примерно на столько же возросли задержки при выполнении операций записи. Как оказалось производительность приложений, интенсивно запрашивающих информацию о времени, очень сильно зависит от выбранного в системе источника точного времени... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55870
Ответить \| Правка \| Cообщить модератору

Оглавление

виртуализация она такая, да, Аноним (1), 13:27 , 28-Сен-21, (1) +11

Больше виртуализации XEN, JVM я надеюсь они как-то хотя бы бизнес логику и тари, Аноним (25), 14:39 , 28-Сен-21, (25)

Исскусственный интеллект во всей красе , Аноним (85), 17:30 , 28-Сен-21, (85) +2

Брендану респект, Аноним (2), 13:28 , 28-Сен-21, (2) +20

И от меня Тоже , Аноним (25), 14:40 , 28-Сен-21, (26) +3

Интересно и полезно Спасибо , Аноним (3), 13:33 , 28-Сен-21, (3) +15
Выходит, всё, Netflix уже не использует FreeBSD , Аноним (4), 13:33 , 28-Сен-21, (4) –3

Что значит не использует Использует В том же объёме как и последние 10 лет па, A.Stahl (ok), 13:41 , 28-Сен-21, (6) –5

Готовишься к зиме, газифицируя лужи https news ycombinator com item id 2858473, Аноним (-), 14:01 , 28-Сен-21, (15) +1
это которые которые у них в CDN видео стримят по 400 Gb s с хоста зачотные марш, Михрютка (ok), 14:24 , 28-Сен-21, (23) +1
Нетфликс- не твоя шарага, в которой есть то, что стрёмно трогать, потому что раз, aname (?), 17:18 , 28-Сен-21, (82) –3

однажды к Фрейду подошла дочка и сказала - папа мне сегодня снилось, как наш со, Михрютка (ok), 23:50 , 28-Сен-21, (114) +5

Правильно, там прагматичный капитализм, и им дела нет до отмороженных фанатиков , bOOster (ok), 10:06 , 29-Сен-21, (131)

Избирательное чтение Мастеркласс 8470 2983 от опеннетных Пингвиняш , Аноним (-), 13:45 , 28-Сен-21, (8) +2
https people freebsd org gallatin talks euro2021 pdf, Михрютка (ok), 14:00 , 28-Сен-21, (14) +3

Спасибо Как же я был не прав , Аноним (4), 14:04 , 28-Сен-21, (16) +2

Для тех кто искал полный доклад https www youtube com watch v _o-HcG8QxPcОбсуж, Аноним (135), 11:54 , 29-Сен-21, (135) –1

Вот до чего доводит программирование с низким порогом мышления Только что замети, _kp (ok), 13:39 , 28-Сен-21, (5) –19

Ну как молчал Писал По началу возмущался, как так, я нашел какой то баг, а все, _kp (ok), 20:30 , 28-Сен-21, (100)

И с патчами бывает Вот в прошлом месяце поблагодарили в одном проекте за патч, _kp (ok), 20:51 , 28-Сен-21, (102) +3

банальный - -откатывающий неведомое изменение в ведре между тем что было у центо, пох. (?), 11:27 , 29-Сен-21, (132) –1

дяденька, если в базе есть поле timestamp, вы знаете другие способы получить его, Михрютка (ok), 14:38 , 29-Сен-21, (138)

Если дошло ажно до того что его дерганье тормозит инсерт - да, знаю не дергать , пох. (?), 16:20 , 29-Сен-21, (146) –2

хинт - его дерганье не увеличивало задержки при записи до миграции и перестало у, Михрютка (ok), 17:04 , 29-Сен-21, (147)

кто сказал И по сравнению с чем увеличивало enlarge your what Оно просто ст, пох. (?), 10:36 , 30-Сен-21, (149)

да он сам и сказал вы его блог-то читали средний нетфликсовский подписчик до к, Михрютка (ok), 12:27 , 30-Сен-21, (150)

то есть целое ОДНО видео в день а в целом так и должно - он же еще в этот день,, пох. (?), 12:35 , 30-Сен-21, (151)
вы хоть обсарказмируйтесь ровно это изменит факт, что все действия пользователя, Михрютка (ok), 13:58 , 30-Сен-21, (152)
Блин, типовой пользователь за этот час не сделал ровно НИХ-Я Киношку он смотрит, пох. (?), 14:05 , 30-Сен-21, (153)
и что все эти сорок минут время подключения и просмотра будут считать, с минутн, Михрютка (ok), 15:17 , 30-Сен-21, (154)
ну ооок зачем мне читать про то как они все сделали через анус Я уже вон начита, пох. (?), 15:24 , 30-Сен-21, (155) +1
та да, на целую ветку сферического трепа про незачем писать у вас время есть, , Михрютка (ok), 17:46 , 30-Сен-21, (158)

Хочешь сказать, что качель экономии на инфраструктуре с дифицитом железа опять к, Аноним (25), 14:43 , 28-Сен-21, (27) –2

404, Аноним (120), 00:14 , 29-Сен-21, (120) +1

А каким образом запись в sys devices system clocksource влияет на способ получе, Нанобот (ok), 13:46 , 28-Сен-21, (9) +1

вызов из java в итоге прилетает в ядро, и оно в зависимости от настроек выбирает, Anonnnym (?), 15:20 , 28-Сен-21, (39) +4

возможно java дергает libc, а уже libc ядро, и тогда в centos прозводительность , Anonnnym (?), 15:21 , 28-Сен-21, (40) +2

да нет, вы просто дернете gettimeofday, а тот дернет отмапленную в ваш юзерспейс, Михрютка (ok), 15:33 , 28-Сен-21, (47) +1

Главное не смущаться, что gettimeofday - давно deprecated И причины весьма с, _kp (ok), 15:34 , 30-Сен-21, (156) +1

и куда спрашивается крестьянину податься, если кассандра дергает javaTimeMillis,, Михрютка (ok), 16:08 , 30-Сен-21, (157) +3
Тип времени и способ получения времени 8212 это разные вещи , Аноним (160), 04:47 , 01-Окт-21, (160)

Конечно Но неправильный выбор типа времени, так же плодит неочевидные эффекты, , _kp (ok), 13:04 , 04-Окт-21, (164)

А что насчёт kvm-clock , Аноним (10), 13:47 , 28-Сен-21, (10) –2

А прочитать новость до конца , Moomintroll (ok), 15:13 , 28-Сен-21, (37) +2

эту новость не надо читать до конца, ее надо сразу в печку things have changed , Михрютка (ok), 16:22 , 28-Сен-21, (65)

Ошибка RDTSC считает такты процессора с момента его включения причем не гаранти, Урри (ok), 13:55 , 28-Сен-21, (13) +1

Читай внимательнее Константная частота тиков делает из rdtsc именно что часы, вс, Ordu (ok), 14:43 , 28-Сен-21, (28) +4

Да, действительно Мои данные устарели Сходил проверить в интеловский мануал Пи, Урри (ok), 17:13 , 28-Сен-21, (80) +3

Больше похоже на то, что для XEN либо не реализовано vDSO, либо сам таймер криво, Аноним (34), 14:55 , 28-Сен-21, (34) –1

если б не было, как бы они получили выигрыш во времени при переходе на tsc strac, Михрютка (ok), 15:11 , 28-Сен-21, (36) –1

Там вроде PIT самый надёжный и производительный, давайте вернёмся во времена хрю, Аноним (17), 14:05 , 28-Сен-21, (17) –3

- HPET тормозит на большом числе ядер под Intel, снижает fps в играх- Если отклю, Аноним (24), 14:31 , 28-Сен-21, (24)

кстати, не совсем снижает, скорее ограничивает Сам лично столкнулся с таким при, Anon from Mars (?), 15:47 , 28-Сен-21, (52)

Но это проблема известна только для Intel В AMD она в самом начале была исправл, Аноним (54), 15:53 , 28-Сен-21, (54)

В какой ещё AMD Что я точно знаю о таймерах у АМД, так это то, что рассинхрониза, Бывший АМДшник (?), 03:05 , 04-Окт-21, (162) +1

Я говорил в контексте ZenПро существование более старых я никогда не слышал и не, Смузи (?), 19:49 , 12-Окт-21, (166)

Я говорил в контексте Zen, про существование более старых архитектур я не слышал, Смузи (?), 19:49 , 12-Окт-21, (165)

https kb vmware com s article 1591, Аноним (54), 04:24 , 01-Окт-21, (159)

https deeperf com 2019 04 30 tsc-clock-missing-caused-performance-issues , Аноним (54), 15:39 , 28-Сен-21, (51)
Открой для себя Windows XP Professional x64 Edition на базе ядра Windows Server , Аноним (123), 02:39 , 29-Сен-21, (123) –2

Я не уверен, что это имеет смысл, потому что все программы того времени 32 бита , Аноним (17), 02:54 , 29-Сен-21, (124) –1

А что насчёт Spectre с источником TSC , Аноним (18), 14:09 , 28-Сен-21, (18) –2
Вопрос, зачем переходили на лагучую бунту , Аноним (19), 14:12 , 28-Сен-21, (19) –2

А зачем платить за дорогущий Red Hat или переходить на нестабильный CentOS Strea, Аноним (22), 14:18 , 28-Сен-21, (22) +4

Самое главное из новости что из-за выкрутасов компании IBM с CentOS нормальные к, Аноним (22), 14:17 , 28-Сен-21, (21) +8

Ну значит в ряды OpenSource прибыло Теперь Ubuntu через лет 20 перестанет быть , Аноним (25), 14:47 , 28-Сен-21, (31)

Его к тому времени уже продадут , Аноним (22), 15:26 , 28-Сен-21, (42) +1

Так ведь ничего не пофиксили Бубунта как тормозила так и продолжила тормозить, , Anonnnym (?), 15:26 , 28-Сен-21, (41)

Тормозить запуска базы данных, ты серьёзно Ты часто базу перезапускаешь Тебе б, Аноним (22), 15:28 , 28-Сен-21, (43) –1

Она тормозит на вызове счетчика Работает в 5 раз медленнее, чем CentOS, Anonnnym (?), 15:29 , 28-Сен-21, (44) –1

Тоже оригинал статьи на английском почитай , Аноним (22), 16:09 , 28-Сен-21, (63)

Под xen Ubuntu в 5 раз медленнее По прежнему Ubuntu в 5 раз медленнее Время увле, Аноним Анонимович Анонимов (?), 14:47 , 28-Сен-21, (30) +10

Одинаково возросла Запуск в Убунте остался таким же медленным Вы троллите все , Аноним (22), 15:29 , 28-Сен-21, (45) –7

Это ты читать не умеешь Было CentOS со счетчиком xenСтало Ubuntu со счетчиком , Anonnnym (?), 15:34 , 28-Сен-21, (48) +5

Оригинал почитай переводчик всё врёт , Аноним (22), 16:08 , 28-Сен-21, (62) +1

Почитал, в оригинале вообще все по другому с момента смены счетчика Мб переводч, Anonnnym (?), 20:20 , 28-Сен-21, (99)

Потому что есть энтерпрайз, а есть игрушки Можно немного сэкономить денег, выб, Stax (ok), 15:13 , 29-Сен-21, (143)

В 2014м году в RH инженегры уже так же улыбались и махали хвостами с веток, ка, пох. (?), 07:20 , 30-Сен-21, (148)

В python похожая беда между datetime now и datetime today , Аноним (32), 14:50 , 28-Сен-21, (32) –2
Даже если так, пнуть его раз в секунду или реже, чтобы поправить набежавший дрей, YetAnotherOnanym (ok), 14:58 , 28-Сен-21, (35)

В ядре всё уже отпинано за нас, выглядит это так tsc Marking TSC unstable due t, n00by (ok), 18:27 , 28-Сен-21, (92)

Intel CoffeeLake уже запрещает hpet из коробки черным списком ядра, Аноним (54), 20:01 , 28-Сен-21, (98)

Смысл в том, что если счётчик признан нестабильным, он заменяется на менее точны, n00by (ok), 21:01 , 28-Сен-21, (104)

А на самое интересное хер забили Ubuntu как работала в 5 раз медленнее с xen, т, Anonnnym (?), 15:16 , 28-Сен-21, (38) +1

Это какой-то глюк переводчика числа 0 13 и 0 68 приводятся для состояния до смен, Аноним (22), 15:54 , 28-Сен-21, (55) +2

нифига В оригинале тоже никто не стал искать причину, почему с xen Ubunta медле, evk (??), 22:54 , 28-Сен-21, (111)

Это ты сам выгораживаешь Цент Просто Цент был правильнее настроен и там сразу б, Аноним (117), 23:58 , 28-Сен-21, (117)

А прочитать Там четко сказано что в CentOS тоже xen, evk (??), 08:26 , 29-Сен-21, (126)

Для решения многих проблем рекомендуется фиксирование потока на конкретном проце, Аноним (54), 15:37 , 28-Сен-21, (49) –1
парни, я правильно понимаю, для железных серверов надо использовать процессорный, Аноним (50), 15:37 , 28-Сен-21, (50) –1

Не правильно, этот таймер можно включать но не использовать по-умолчанию для хос, Аноним (54), 15:48 , 28-Сен-21, (53) +1

надмозги за работой, Михрютка (ok), 15:54 , 28-Сен-21, (56) –1

Тут нужен переперевод Это время до смены источника времени А переводчик пишет , Аноним (22), 15:59 , 28-Сен-21, (59)

а птушо автор новости - надмозг вот чо пишет ГреггLet s try tsc, which should be, Михрютка (ok), 16:15 , 28-Сен-21, (64) –1

Глянь чуть выше в тексте, конкретно значения real в бенчмарках , Аноним (78), 17:05 , 28-Сен-21, (78)

внимательнее читайте камент, на который отвечаете , Михрютка (ok), 17:26 , 28-Сен-21, (84) –2

Прочитай оригинал внимательнее, в новости процитировано время из этих измеренийT, Аноним (78), 17:04 , 28-Сен-21, (77)

вы это всерьез называете цитированием пока мы беседуем, автор хоть лажу с запус, Михрютка (ok), 17:24 , 28-Сен-21, (83)

Причем при микросекунды писалось в исходном тексте А про секунды это автор выве, Аноним (22), 18:08 , 28-Сен-21, (88)

Так это до изменения источника времени, а не после Так что будет после и кто в , Аноним (22), 17:57 , 28-Сен-21, (87)

товарищ, если вы не заметили, Грегг не Мишенька с похороникса Грегг не тестиров, Михрютка (ok), 23:58 , 28-Сен-21, (116)

Ну и заодно ненавязчиво в очередной раз порекламировав ненужноtrace Уровень впоп, пох. (?), 09:31 , 29-Сен-21, (128) –1

действительно бездельник из нетфликса решает проблемы нетфликса да еще в рабоч, Михрютка (ok), 15:24 , 29-Сен-21, (144) –1

проблему которую сам же себе и создал Ну да Инвестору-то такие вещи все равно , пох. (?), 16:10 , 29-Сен-21, (145) –1

Про HPET чудо программеры и не слышали , Аноним (58), 15:56 , 28-Сен-21, (58) –2

https access redhat com solutions 18627High Precision Event Timer HPET The HP, Аноним (54), 16:03 , 28-Сен-21, (60)

А если убрать java то будет ещё быстрее , пончик (?), 16:06 , 28-Сен-21, (61) +1

Анализ влияния на производительность выбранного в системе ис..., Интернет_Герой (?), 16:34 , 28-Сен-21, (69) +1

Вопрос в том, зачем джава стомиллионов раз получает время , Аноним (109), 22:27 , 28-Сен-21, (109) +2

Уберите пробел , Вадик (??), 16:24 , 28-Сен-21, (66)

запоминиается простое переход возможен, игра режимами на рабочих системах - это, Аноним (73), 16:48 , 28-Сен-21, (73)

Но почему осталось не известно , Аноним (68), 16:30 , 28-Сен-21, (68)

Логические связи в переводе утеряны В оригинале Убунту стала быстрее в 4 раза Ц, Аноним (22), 16:44 , 28-Сен-21, (71)

Прям хоть сам перепроверяй и перебенчмаркивай , Аноним (22), 16:46 , 28-Сен-21, (72)
ТОлько похоже имелось в виду Ubunta tsc быстрее CentOS xenА ответа почему Ubunta, evk (??), 23:01 , 28-Сен-21, (112) +1

Мне кажется что Цент из коробки шел с настроенным tsc А в Убунте оставили xen д, Аноним (117), 23:57 , 28-Сен-21, (115)

Осталось неясным, зачем эта хрень прям столько раз это вызывает Вроде бы в проц, rm2 (?), 16:44 , 28-Сен-21, (70) +1

в БД иногда еще пишут , Михрютка (ok), 16:52 , 28-Сен-21, (74) –2
К сожалению, ни дтрейс ни bpf неспособны дать ответ что обезьянка наобезьянкала, пох. (?), 09:35 , 29-Сен-21, (129)

пару лет назад читал статью, так там во много раз ускоили выполнение JAVA програ, Штунц (?), 16:59 , 28-Сен-21, (76) +1

Бенчу из статьи 7 лет Там уже и джава по другому работает небось , Аноним (22), 18:08 , 28-Сен-21, (90)

а как они синхронизировали TSC на разных процессорах там же разные значения мог, sdkhflskhgl (?), 17:10 , 28-Сен-21, (79) +1

Время вычисляет ядро, а оно видит все процессоры , Аноним (160), 04:52 , 01-Окт-21, (161)

Интересно, Аноним (81), 17:18 , 28-Сен-21, (81) –1
Вот, рекомендуюcryptdevice UUID label allow-discards,no-read-workqueue,no-, Аноним (89), 18:08 , 28-Сен-21, (89) +2

Единственный полезный коммент ко всей этой старой статье , Аноним (22), 18:16 , 28-Сен-21, (91)
Лучше еще добавить mitigations off, Alladin (?), 00:43 , 29-Сен-21, (121) +1

Потыстировал на узком цикле с clock_gettime CLOCK_MONOTONIC В tsc_mode 1 clocks, Онаним (?), 22:12 , 28-Сен-21, (106) +1

Но сама проблема есть, если воткнуть clocksource hpet, производительность тестов, Онаним (?), 22:13 , 28-Сен-21, (107)

Надо аппаратно ускоренный источник времени в виде отдельной платы Чтоб убунта л, Аноним (108), 22:20 , 28-Сен-21, (108) –1

Очень глупая идея, где нужны очень низкие задержки , Аноним (54), 22:50 , 28-Сен-21, (110)
Тогда можно время просто не запрашивать просто прибавлять какой-нибудь счетчик в, Аноним (117), 00:00 , 29-Сен-21, (119) +1
Уже сделали, проверяйте HPET 128515 , Crok (?), 06:01 , 29-Сен-21, (125) –2

HPET устаревший Intel не рекомендует использовать этот аппаратный кварцевый тайм, Аноним (54), 15:04 , 29-Сен-21, (139)
В современных процессорах Intel, TSC зависит от индивидуальной частоты процессор, Аноним (54), 15:08 , 29-Сен-21, (141) +1

Сейчас таких специалистов не делают Не было стактрейсов, запатчил JVM, чтобы бы, yamlcoder (?), 00:53 , 29-Сен-21, (122)

Глубины копания под фонарем, потому что там светлее Проблема, ежу понятно - что-, пох. (?), 09:39 , 29-Сен-21, (130) –2

ну да, когда у меня rhel6 под hyperv время не держал совсем, то есть вообще, это, Михрютка (ok), 14:26 , 29-Сен-21, (137) –2

В C такого нет , Аноним (134), 11:44 , 29-Сен-21, (134) –1

Ubuntu 19-20 Tsc as default , Anonim (??), 08:39 , 29-Сен-21, (127)

Статья 2014 года в лучшем случае Убунту 14 04 и правки сделали уже тогда причем , Аноним (134), 11:35 , 29-Сен-21, (133)

Скрыто модератором, Линус не Торвальдс (?), 03:34 , 04-Окт-21, (163) +1

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

1. "Анализ влияния на производительность выбранного в системе ис..." +11 +/–

Сообщение от Аноним (1), 28-Сен-21, 13:27

виртуализация она такая, да

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

25. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (25), 28-Сен-21, 14:39

Больше виртуализации. XEN, JVM я надеюсь они как-то хотя бы бизнес логику и тарифы скриптуют хотя бы через ScriptEngine
А потом героический чиним таймеры =)

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

85. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Аноним (85), 28-Сен-21, 17:30

Исскусственный интеллект во всей красе!

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

2. "Анализ влияния на производительность выбранного в системе ис..." +20 +/–

Сообщение от Аноним (2), 28-Сен-21, 13:28

Брендану респект

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

26. "Анализ влияния на производительность выбранного в системе ис..." +3 +/–

Сообщение от Аноним (25), 28-Сен-21, 14:40

И от меня. Тоже.

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

3. "Анализ влияния на производительность выбранного в системе ис..." +15 +/–

Сообщение от Аноним (3), 28-Сен-21, 13:33

Интересно и полезно. Спасибо.

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

4. "Анализ влияния на производительность выбранного в системе ис..." –3 +/–

Сообщение от Аноним (4), 28-Сен-21, 13:33

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

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

6. "Анализ влияния на производительность выбранного в системе ис..." –5 +/–

Сообщение от A.Stahl (ok), 28-Сен-21, 13:41

Что значит не использует? Использует. В том же объёме как и последние 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют.

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

15. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (-), 28-Сен-21, 14:01

> Что значит не использует? Использует. В том же объёме как и последние
> 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют.
Готовишься к зиме, газифицируя лужи?
https://news.ycombinator.com/item?id=28584738
> 8 days ago
> Serving Netflix Video at 400Gb/s on FreeBSD
> ...
> polskibus 8 days ago [–]
> Was FreeBSD your first choice? Or did you try with Linux first? What were the numbers for Linux-based solution, if there was one?
.
> drewg123 8 days ago [–]
> FreeBSD was selected at the outset of the Open Connect CDN (~2012 or so).
> We did a bake off a few years ago, and FOR THIS WORKLOAD FreeBSD outperformed Linux. I don't want to get into an OS war, that's not productive.
...
> drewg123 8 days ago [–]
> Yes. I ran it for a bake off ~2 years ago. At the time, the code in linux was pretty raw, and I had to fix a bug in their SW kTLS that caused data corruption that was visible to clients. So I worry that it was not in frequent use at the time, though it may be now.
>

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

23. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 14:24

>>>последние 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют.
это которые которые у них в CDN видео стримят по 400 Gb/s с хоста? зачотные маршрутизаторы, я тож такой хочу.

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

82. "Анализ влияния на производительность выбранного в системе ис..." –3 +/–

Сообщение от aname (?), 28-Сен-21, 17:18

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

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

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

114. "Анализ влияния на производительность выбранного в системе ис..." +5 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 23:50

однажды к Фрейду подошла дочка и сказала:
- папа! мне сегодня снилось, как наш сосед герр Штольц показывает мне свой сервер. но у него был такой маленький пыльный сервер и непроизводительный и падал каждые пять минут! а потом я подошла к тебе и ты мне показал свой сервер, и он был такой большой, красивый и мощный и очень долго не падал...
- дура! иногда сервер - это просто сервер! - оборвал дочку Фрейд.

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

131. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от bOOster (ok), 29-Сен-21, 10:06

Правильно, там прагматичный капитализм, и им дела нет до отмороженных фанатиков в принятии решения о смене FreeBSD на уг.. Так же как и центральное маршрутизируещее ядро в Амазон.

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

8. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Аноним (-), 28-Сен-21, 13:45

>> при переводе СУБД Cassandra c CentOS на Ubuntu в окружениях, выполняемых в облаке Amazon EC2  на базе Xen
>> выполняемых в облаке Amazon EC2  на базе Xen
>>CentOS
>>Ubuntu
> Выходит, всё, Netflix уже не использует FreeBSD?
"Избирательное чтение. Мастеркласс №2983 от опеннетных Пингвиняш."

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

14. "Анализ влияния на производительность выбранного в системе ис..." +3 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 14:00

https://people.freebsd.org/~gallatin/talks/euro2021.pdf

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

16. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Аноним (4), 28-Сен-21, 14:04

Спасибо. Как же я был не прав...

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

135. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (135), 29-Сен-21, 11:54

Для тех кто искал полный доклад:
https://www.youtube.com/watch?v=_o-HcG8QxPc
Обсуждение с автором доклада (drewg123):
https://news.ycombinator.com/item?id=28584738

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

5. "Анализ влияния на производительность выбранного в системе ис..." –19 +/–

Сообщение от _kp (ok), 28-Сен-21, 13:39

Вот до чего доводит программирование с низким порогом мышления.
Только что заметили элементарный тормоз. ;)

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

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

100. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от _kp (ok), 28-Сен-21, 20:30

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

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

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

102. "Анализ влияния на производительность выбранного в системе ис..." +3 +/–

Сообщение от _kp (ok), 28-Сен-21, 20:51

>  А знаешь, на что не пофиг? На патчи!
> С дивана-то все умеют советы давать.
И с патчами бывает... Вот в прошлом месяце поблагодарили в одном проекте за патч аж 2015 года. А поначалу послали. Кто там только в старье копался. :)
Так не всегда, но для примера, вот.
А по данной проблеме какой патч? Тут дело в культуре системостроения.

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

132. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от пох. (?), 29-Сен-21, 11:27

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

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

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

138. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 29-Сен-21, 14:38

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

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

146. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от пох. (?), 29-Сен-21, 16:20

Если дошло ажно до того что его дерганье тормозит инсерт - да, знаю: не дергать. Это gettimeofday с разрешением в 1/100 секунды. Что и само по себе скорее всего ненужное ненужно и хорошо если в базу не записывается округленным до секунд.
Отдельный вопрос что вы такое там пишете с такой частотой и нахрена же, но его следует задавать претенденту на роль архитектора. А вот вопрос как не дергать с наносекундным интервалом - джуниор сопливытирателям. И при неправильном ответе даже на роль уборщицы не брать.

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

147. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 29-Сен-21, 17:04

> Если дошло ажно до того что его дерганье тормозит инсерт - да,
хинт - его дерганье не увеличивало задержки при записи до миграции и перестало увеличивать после смены clocksource после миграции.
> Отдельный вопрос что вы такое там пишете с такой частотой
дяденька, это нетфликс, у которого 200 лямов субскрайберов, и который отдает по америке трафика больше, чем ютуп с амазон стримингом вместе взятые.

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

149. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от пох. (?), 30-Сен-21, 10:36

> хинт - его дерганье не увеличивало задержки при записи до миграции
кто сказал? И по сравнению с чем "увеличивало" ? enlarge your what?
Оно просто стало укладываться в допустимые их инфраструктурой задержки, разбираться с причиной некогда, надсмотрщик машет кнутом.
> дяденька, это нетфликс, у которого 200 лямов субскрайберов, и который отдает по америке трафика
> больше
отдает он этот траффик совсем не из тазы банных, а вот теми самыми полутора уцелевшими freebsd. и 200лямов сабскрайберов это ни разу не все двести что-то лихорадочно кликают, они вообще могут неделями туда не заглядывать. А если и заглянут - видео - оно часами смотрится. Никакого сверххайлоада на _базу_ там нет и быть не может. Ну если только обезьянки его сами себе не наобезьянкали.

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

150. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 30-Сен-21, 12:27

>> хинт - его дерганье не увеличивало задержки при записи до миграции
> кто сказал? И по сравнению с чем "увеличивало" ? enlarge your what?
да он сам и сказал. вы его блог-то читали?

> отдает он этот траффик совсем не из тазы банных, а вот теми
> самыми полутора уцелевшими freebsd. и 200лямов сабскрайберов это ни разу не
> все двести что-то лихорадочно кликают, они вообще могут неделями туда не
> заглядывать. А если и заглянут - видео - оно часами смотрится.
> Никакого сверххайлоада на _базу_ там нет и быть не может. Ну
> если только обезьянки его сами себе не наобезьянкали.
средний нетфликсовский подписчик до карантина смотрел 2 часа видео в день (допустим, что нефликс учел одновременные просмотры на нескольких устройствах). в 2014 у нетфликса было 50 миллионов подписчиков. это 4 миллиона часов просмотра в час, на минутку.
для просмотра инфраструктура на амазоне должна подписчика
(высосано из моего пальца)
- аутентифицировать
- проверить биллинг
- проверить, сколько гавриков уже смотрят под этим аккаунтом (до пяти на премиуме)
- вытащить список просмотренного видео
- вытащить список того, что ему хочется посмотреть и еще кучу других списков
- следить, что он бровзит, и корректировать все эти списки соответственно
- если он кликнул плей - проверить, есть ли в cdn это видео, если нет - отдать из библиотеки
- а да - все это залогировать для статистики, и считать, сколько времени он смотрит
- а подписчик посмотрел пять минут, видит - тягомотина какая-то, стопает и начинает снова копаться, что бы такого посмотреть
то есть в 2014 году это как раз все для одного зрителя за миллисекунду надо было обработать, даже если он просто открыл нетфликс, и кликнул плей. хотя бы чтоб записать, сколько он времени смотрит данное видео.
я нигде не напутал?
это для вас достаточный хайлоад?

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

151. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от пох. (?), 30-Сен-21, 12:35

> средний нетфликсовский подписчик до карантина смотрел 2 часа видео в день
то есть целое ОДНО видео в день (а в целом так и должно - он же еще в этот день, наверное, работал чтобы оплатить подписочное рабство)? Ахеренная нагрузка на базу.
> (высосано из моего пальца)
заметно. А теперь пробуем включить мозг и подумать - а где тут нужна _запись_ в базу да еще с микросекундными таймстемпами.
Не "где макак побырому нагoвнякал", а где НУЖНА.

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

152. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 30-Сен-21, 13:58

> то есть целое ОДНО видео в день (а в целом так и
> должно - он же еще в этот день, наверное, работал чтобы
> оплатить подписочное рабство)? Ахеренная нагрузка на базу.
вы хоть обсарказмируйтесь. ровно это изменит факт, что все действия пользователя в течение часа желательно было бы обработать за одну миллисекунду (на самом деле еще меньше, т.к. 40% нетфликса - это сша/канада).
>> (высосано из моего пальца)
> заметно. А теперь пробуем включить мозг и подумать - а где тут
> нужна _запись_ в базу да еще с микросекундными таймстемпами.
> Не "где макак побырому нагoвнякал", а где НУЖНА.
везде, начиная от авторизации. где мы должны хотя бы зафиксировать факт логина, добавить плюсик к числу подключенных устройств и записать, с какого адреса и какого устройства залогинились.
про микросекундные таймстампы вообще не понял, к чему это? у вас есть ультрабыстрый способ дернуть System.currentTimeMillis, при котором она возвращает только целые секунды?

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

153. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от пох. (?), 30-Сен-21, 14:05

Блин, типовой пользователь за этот час не сделал ровно НИХ-Я! Киношку он смотрит, и НИЧЕГО в это время больше не делает. И еще сорок минут будет ничего не делать. А потом пойдет спать.
На паузу может поставить, но об этом факте незачем записывать в базу с наносекундной точностью чтоб потом героически бороться с ней.
> везде, начиная от авторизации. где мы должны хотя бы зафиксировать факт логина, добавить плюсик к
> числу подключенных устройств и записать, с какого адреса и какого устройства залогинились.
то есть раз в неделю или реже. Потому что никто, разумеется, устройство не выключает.
> про микросекундные таймстампы вообще не понял, к чему это? у вас есть ультрабыстрый способ
> дернуть System.currentTimeMillis, при котором она возвращает только целые секунды?
"вы не прошли собеседование на ассистента второго младшего помощника junior developer"
Попробуйте устроиться менеджером проекта, там таких берут.

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

154. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 30-Сен-21, 15:17

> Блин, типовой пользователь за этот час не сделал ровно НИХ-Я! Киношку он
> смотрит, и НИЧЕГО в это время больше не делает. И еще
> сорок минут будет ничего не делать. А потом пойдет спать.
и что? все эти сорок минут время подключения и просмотра будут считать, с минутной точностью, но будут. вы бы почитали что-нить общедоступное про нетфликсовские метрики.
> На паузу может поставить, но об этом факте незачем записывать в базу
> с наносекундной точностью чтоб потом героически бороться с ней.
дядя, вы уже подзадрали с вашими наносекундами. я там вопрос задал про способ получить время из джавы быстрее, жаль, что ваши растопыренные пальцы помешали вам попасть по клаве и ответить.
>> везде, начиная от авторизации. где мы должны хотя бы зафиксировать факт логина, добавить плюсик к
>> числу подключенных устройств и записать, с какого адреса и какого устройства залогинились.
> то есть раз в неделю или реже. Потому что никто, разумеется, устройство
> не выключает.
дооо. кому там мозги включить надо? устройств обычно больше одного. и даже больше, чем допустимое по тарифному плану число одновременных сеансов.

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

155. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от пох. (?), 30-Сен-21, 15:24

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

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

158. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 30-Сен-21, 17:46

> малыш, если тебе не приходит в голову хотя бы одного ответа на
> этот вопрос - ты профнепригоден, и незачем терять на тебя время.
та да, на целую ветку сферического трепа про "незачем писать" у вас время есть, а как носом ткнуть молодого в конкретику, так сразу и заняты.

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

27. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (25), 28-Сен-21, 14:43

Хочешь сказать, что качель экономии на инфраструктуре с дифицитом железа опять качнулась в сторону квалификации программистов?
!()[https://cs6.pikabu.ru/images/big_size_comm/2014-07_6/1406373...

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

120. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (120), 29-Сен-21, 00:14

404

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

9. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Нанобот (ok), 28-Сен-21, 13:46

А каким образом запись в /sys/devices/system/clocksource влияет на способ получения времени обычным процессом? Ведь для получения данных через tsc нужно просто вызывать инструкцию (не обращаясь к ядру с его настройками clocksource), а в остальных случаях - делать syscall

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

39. "Анализ влияния на производительность выбранного в системе ис..." +4 +/–

Сообщение от Anonnnym (?), 28-Сен-21, 15:20

вызов из java в итоге прилетает в ядро, и оно в зависимости от настроек выбирает способ получения времени. Потеря производительности, которая осталась от перехода на Ubuntu как раз из-за того что дергается syscall, который дергает tsc, вместо прямого вызова tsc без переключения контекста

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

40. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Anonnnym (?), 28-Сен-21, 15:21

возможно java дергает libc, а уже libc ядро, и тогда в centos прозводительность выше может быть, если в случае с использованием tsc, libc дергает его сама, не уходя в ядро

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

47. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 15:33

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

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

156. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от _kp (ok), 30-Сен-21, 15:34

Главное не смущаться, что gettimeofday() - давно deprecated ;)
И причины весьма схожие с этой темой, хотя и чуть иные.
А в clock_gettime() явно указывается тип премени под смысл задачи.

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

157. "Анализ влияния на производительность выбранного в системе ис..." +3 +/–

Сообщение от Михрютка (ok), 30-Сен-21, 16:08

> Главное не смущаться, что 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);
}

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

160. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (160), 01-Окт-21, 04:47

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

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

164. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от _kp (ok), 04-Окт-21, 13:04

>> А в clock_gettime() явно указывается тип времени под смысл задачи.
> Тип времени и способ получения времени — это разные вещи.
Конечно. Но неправильный выбор типа времени, так же плодит неочевидные эффекты, и влияет на производительность.
И раз начали разбираться с проблемами времени, то счел необходимым заодно напомнить.

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

10. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (10), 28-Сен-21, 13:47

А что насчёт kvm-clock?

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

37. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Moomintroll (ok), 28-Сен-21, 15:13

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

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

65. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 28-Сен-21, 16:22

эту новость не надо читать до конца, ее надо сразу в печку.
> Дополнительно был проведён тест производительности источника времени 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 я тож блин внимательный

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

13. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Урри (ok), 28-Сен-21, 13:55

Ошибка!
> Для получения времени при выборе источника TSC используется процессорная инструкция RDTSC, выполнение которой не требует совершение системного вызова (инструкция не требует повышенных привилегий и выдаёт значение из встроенного в CPU счётчика времени).
RDTSC считает такты процессора с момента его включения (причем не гарантируется, что это именно такты; гарантируется, что этот счетчик монотонно возрастает). Никакого системного времени rdtsc не дает!
https://en.wikipedia.org/wiki/Time_Stamp_Counter

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

28. "Анализ влияния на производительность выбранного в системе ис..." +4 +/–

Сообщение от Ordu (ok), 28-Сен-21, 14:43

Читай внимательнее:
> The specific processor configuration determines the behavior. Constant TSC behavior ensures that the duration of each clock tick is uniform and makes it possible to use of the TSC as a wall clock timer even if the processor core changes frequency. This is the architectural behavior for all later Intel processors.
> AMD processors [...]. Since the family 10h (Barcelona/Phenom), AMD chips feature a constant TSC, which can be driven either by the HyperTransport speed or the highest P state. A CPUID bit (Fn8000_0007:EDX_8) advertises this; Intel-CPUs also report their invariant TSC on that bit.
Константная частота тиков делает из rdtsc именно что часы, всё что тебе надо -- это знать t0 и коэффициент для перевода из тиков в секунды. Причём это гораздо более интересные часы, поскольку все эти acpi и hpet часы на меньшей частоте тикают, то есть точности меньше дают.

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

80. "Анализ влияния на производительность выбранного в системе ис..." +3 +/–

Сообщение от Урри (ok), 28-Сен-21, 17:13

Да, действительно. Мои данные устарели.
Сходил проверить в интеловский мануал. Пишут буквально следующее:
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.

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

34. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (34), 28-Сен-21, 14:55

Больше похоже на то, что для XEN либо не реализовано vDSO, либо сам таймер кривой.

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

36. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 15:11

если б не было, как бы они получили выигрыш во времени при переходе на tsc.
strace смотреть надо

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

17. "Анализ влияния на производительность выбранного в системе ис..." –3 +/–

Сообщение от Аноним (17), 28-Сен-21, 14:05

Там вроде PIT самый надёжный и производительный, давайте вернёмся во времена хрюши. Только от многоядерности придётся отказаться, PIT работает с 1 ядром. И 32 бита заодно возродите. А hpet это отдельный кварц на плате, чё не используете? Он хотя бы стабильный, TSC слишком рандомный (и под нагрузкой результаты будут отличаться).

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

24. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (24), 28-Сен-21, 14:31

- HPET тормозит на большом числе ядер под Intel, снижает fps в играх
- Если отключить HPET под linux можно наблюдать деградацию в Windows-госте https://kb.vmware.com/s/article/67175

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

52. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Anon from Mars (?), 28-Сен-21, 15:47

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

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

54. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 28-Сен-21, 15:53

Но это проблема известна только для Intel. В AMD она в самом начале была исправлена и включение/выключение не влияет на скорость.

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

162. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Бывший АМДшник (?), 04-Окт-21, 03:05

В какой ещё AMD?
Что я точно знаю о таймерах у АМД, так это то, что рассинхронизация в многоядерных процессорах у них просто катастрофическая!
Думаешь, они что-то сделали, чтобы исправить выпускаемое ими оборудование? - Ничего не сделали.
Зато приложили все усилия чтобы скрыть этот и другие недостатки: выпустили "AMD Dual Core Optimizer", который под видом "оптимизации" переключал таймер тупо на самый медленный, и убогий,  ограниченный на точности в 64 раза в секунду...
AMD - это бракоделы, и всегда ими были. Факт.

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

166. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Смузи (?), 12-Окт-21, 19:49

Я говорил в контексте Zen
Про существование более старых я никогда не слышал и не видел их.

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

165. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Смузи (?), 12-Окт-21, 19:49

Я говорил в контексте Zen, про существование более старых архитектур я не слышал и не видел их никогда.

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

159. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 01-Окт-21, 04:24

+ https://kb.vmware.com/s/article/1591

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

51. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 28-Сен-21, 15:39

https://deeperf.com/2019/04/30/tsc-clock-missing-caused-perf.../

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

123. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (123), 29-Сен-21, 02:39

Открой для себя Windows XP Professional x64 Edition на базе ядра Windows Server 2003 x64. Кто-то уже 20 лет как забыл про 32 бита даже на винде.

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

124. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (17), 29-Сен-21, 02:54

Я не уверен, что это имеет смысл, потому что все программы того времени 32 бита. Довольно неэффективно. Чтобы использовать больше 3гб памяти в обычной икспи можно просто положить своп на виртуальный диск в невидимой памяти. Но там ещё были PAE ядра, если хочется.

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

18. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (18), 28-Сен-21, 14:09

А что насчёт Spectre с источником TSC?

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

19. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (19), 28-Сен-21, 14:12

Вопрос, зачем переходили на лагучую бунту?

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

22. "Анализ влияния на производительность выбранного в системе ис..." +4 +/–

Сообщение от Аноним (22), 28-Сен-21, 14:18

А зачем платить за дорогущий Red Hat или переходить на нестабильный CentOS Stream?

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

21. "Анализ влияния на производительность выбранного в системе ис..." +8 +/–

Сообщение от Аноним (22), 28-Сен-21, 14:17

Самое главное из новости что из-за выкрутасов компании IBM с CentOS нормальные компании стали перебираться на Ubuntu и попутно фиксить баги. Что есть гуд.

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

31. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (25), 28-Сен-21, 14:47

Ну значит в ряды OpenSource прибыло! Теперь Ubuntu через лет 20 перестанет быть синонимом глючного барахла.

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

42. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (22), 28-Сен-21, 15:26

Его к тому времени уже продадут.

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

41. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Anonnnym (?), 28-Сен-21, 15:26

Так ведь ничего не пофиксили. Бубунта как тормозила так и продолжила тормозить, просто теперь на другом счетчике. Тормоза с которым для Netflix не критичны.
А сам этот счетчик был и раньше

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

43. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (22), 28-Сен-21, 15:28

Тормозить запуска базы данных, ты серьёзно? Ты часто базу перезапускаешь? Тебе бы голову для начала подлечить.

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

44. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Anonnnym (?), 28-Сен-21, 15:29

> Тормозить запуска базы данных, ты серьёзно? Ты часто базу перезапускаешь? Тебе бы
> голову для начала подлечить.
Она тормозит на вызове счетчика. Работает в 5 раз медленнее, чем CentOS

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

63. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 16:09

Тоже оригинал статьи на английском почитай.

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

30. "Анализ влияния на производительность выбранного в системе ис..." +10 +/–

Сообщение от Аноним Анонимович Анонимов (?), 28-Сен-21, 14:47

> компания 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".
Время увлекательных историй.

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

45. "Анализ влияния на производительность выбранного в системе ис..." –7 +/–

Сообщение от Аноним (22), 28-Сен-21, 15:29

Одинаково возросла. Запуск в Убунте остался таким же медленным. Вы троллите все или читать не умеете?

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

48. "Анализ влияния на производительность выбранного в системе ис..." +5 +/–

Сообщение от Anonnnym (?), 28-Сен-21, 15:34

> Одинаково возросла. Запуск в Убунте остался таким же медленным. Вы троллите все
> или читать не умеете?
Это ты читать не умеешь.
Было: CentOS со счетчиком xen
Стало: Ubuntu со счетчиком xen
Проблема: После перехода на Ubuntu вызов счетчика стал в 5 раз медленнее, что снизило производительность на 30%
Решение: Перешли на счетчик tsc, что повысило производительность на 43%
Сравнение Ubuntu со счетчиком tsc с CentOS со счетчиком tsc показало, что вызов счетчика все еще медленнее в 5 раз, но т.к. теперь все работает быстро, то на это забили.
Выводы в новости конечно эпичные: Ubuntu со счетчиком tsc быстрее CentOS со счетчиком xen. А сверхзвуковой самолет быстрее тролейбуса из буханки хлеба.

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

62. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (22), 28-Сен-21, 16:08

Оригинал почитай переводчик всё врёт.

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

99. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Anonnnym (?), 28-Сен-21, 20:20

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

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

143. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Stax (ok), 29-Сен-21, 15:13

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

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

148. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от пох. (?), 30-Сен-21, 07:20

В 2014м году в RH "инженегры" уже так же улыбались и махали хвостами с веток, как и сегодня.
100% индусская контора, с неработавшей уже тогда техподдержкой и ключевыми проектами, отданными на аутсорс в Бангалор или вообще купленными прям там в бангалоре.
Хорошие кончились изрядно раньше, лучшие из худших как раз тогда уже сваливали в microsoft - но инерции еще хватало.
А в убунте точно такие же. Прыгают по веткам, что-то верещат...

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

32. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (32), 28-Сен-21, 14:50

В python похожая беда между datetime.now() и datetime.today()

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

35. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от YetAnotherOnanym (ok), 28-Сен-21, 14:58

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

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

92. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от n00by (ok), 28-Сен-21, 18:27

В ядре всё уже отпинано за нас, выглядит это так:
tsc: Marking TSC unstable due to clocksource watchdog
clocksource: Switched to clocksource hpet

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

98. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 28-Сен-21, 20:01

Intel CoffeeLake уже запрещает hpet из коробки черным списком ядра

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

104. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от n00by (ok), 28-Сен-21, 21:01

Смысл в том, что если счётчик признан нестабильным, он заменяется на менее точный.

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

38. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Anonnnym (?), 28-Сен-21, 15:16

А на самое интересное хер забили. Ubuntu как работала в 5 раз медленнее с xen, так и работает в 5 раз медленнее с tsc. Новость о том, что tsc без переключения контекстов работает быстрее чем xen с переключением контекстов. Но зачем она такая нужна, и зачем было сообщать о том, что убунта медленнее, раз причину не стали искать?

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

55. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Аноним (22), 28-Сен-21, 15:54

Это какой-то глюк переводчика числа 0.13 и 0.68 приводятся для состояния до смены источника времени https://www.brendangregg.com/blog/2021-09-26/the-speed-of-ti... параграф 6

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

111. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от evk (??), 28-Сен-21, 22:54

нифига. В оригинале тоже никто не стал искать причину, почему с xen Ubunta медленне
И никто не проверил что будет если в CentOS поставить tsc
В общем новость о том что Ubunta медленее, но всем лень разбираться почему

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

117. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (117), 28-Сен-21, 23:58

Это ты сам выгораживаешь Цент. Просто Цент был правильнее настроен и там сразу был tsc по дефолту

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

126. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от evk (??), 29-Сен-21, 08:26

А прочитать? Там четко сказано что в CentOS тоже xen

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

49. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (54), 28-Сен-21, 15:37

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

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

50. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (50), 28-Сен-21, 15:37

парни, я правильно понимаю, для железных серверов надо использовать процессорный таймер, который hpet?

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

53. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (54), 28-Сен-21, 15:48

Не правильно, этот таймер можно включать но не использовать по-умолчанию для хоста. Хоть этот кварц и дороже, RDTSC поддерживает на аппаратном уровне в кажом ядре ЦПУ со значительно низкими задержками.
Если сервер старый выбирай сам.

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

56. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 15:54

>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 секунд
надмозги за работой

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

59. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 15:59

Тут нужен переперевод. Это время до смены источника времени. А переводчик пишет про 13 секунд и 68 секунд для состояния до смены источника. А 13 мкс и 68 мкс после смены источника времени.
Я уже запутался, но кто-то умный должен распутать этот клубок лжи.

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

64. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 16:15

а птушо автор новости - надмозг.
вот чо пишет Грегг
Let's try tsc, which should be the fastest:
# echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
$ time java TimeBench
real    0m3.370s
user    0m3.353s
sys     0m0.026s
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.
а вот что пишет надмозг:
после смены источника времени на TSC (Time Stamp Counter) производительность одинаково возросла в CentOS и Ubuntu, но относительно CentOS запуск в Ubuntu по-прежнему остался в 5 раз медленнее (0.13 против 0.68 мкс), хотя задержки теперь стали слишком малы, чтобы оказывать заметное влияние на производительность.
я не знаю, как можно распутать этот заворот мозгов.

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

78. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (78), 28-Сен-21, 17:05

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

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

84. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 17:26

внимательнее читайте камент, на который отвечаете.

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

77. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (78), 28-Сен-21, 17:04

Прочитай оригинал внимательнее, в новости процитировано время из этих измерений
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.

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

83. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 28-Сен-21, 17:24

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

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

88. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 18:08

Причем при микросекунды писалось в исходном тексте. А про секунды это автор вывел сам. Очередное: «Учёный изнасиловал журналиста»

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

87. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 17:57

Так это до изменения источника времени, а не после. Так что будет после и кто в итоге быстрее с tsc цент или убунту осталось в тайне. Или цент с xen быстрее чем убунту с tsc. Или у цента по дефолту стоит tsc и убунту с tsc быстрее цента в 4 раза. Xen его разберет.
Бывает статьи, которые в себе содержать больше вопросов чем ответов.

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

116. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Михрютка (ok), 28-Сен-21, 23:58

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

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

128. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от пох. (?), 29-Сен-21, 09:31

Ну и заодно ненавязчиво в очередной раз порекламировав ненужноtrace.
Уровень впопен.... ой, простите - уровень современной IT.
Костылинг, пердолинг, ради костылинга и пердолинга. Реверс-инженеринг собственного и открытого софта ради костылинга. Любая проблема решается тем молотком, который надежно приклеен скотчем к рукам.
А почему бубунта тормозит - разбираться некогда, менеджер с кнутом не ждет!
Если кому-то были нужны аргументы вынести убунту нахрен с прода, точно так же, не разбираясь - то вот они.

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

144. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Михрютка (ok), 29-Сен-21, 15:24

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

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

145. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от пох. (?), 29-Сен-21, 16:10

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

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

58. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Аноним (58), 28-Сен-21, 15:56

Про HPET чудо программеры и не слышали.

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

60. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 28-Сен-21, 16:03

https://access.redhat.com/solutions/18627
High Precision Event Timer (HPET)
The HPET is a timer chip that in some future time is expected to completely replace the PIT. It provides a number of hardware timers that can be exploited by the kernel. Basically the chip includes up to eight 32 bit or 64 bit independent counters. Each counter is driven by its own clock signal, whose frequency must be at least 10 MHz; therefore the counter is increased at least once in 100 nanoseconds. Any counter is associated with at most 32 timers, each of which composed by a comparator and a match register. The HPET registers allow the kernel to read and write the values of the counters and of the match registers, to program one-shot interrupts, and to enable or disable periodic interrupts on the timers that support them.

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

61. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от пончик (?), 28-Сен-21, 16:06

А если убрать java то будет ещё быстрее.

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

69. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Интернет_Герой (?), 28-Сен-21, 16:34

>> На языке Си была написана похожая программа, сто миллионов раз вызывающая функцию gettimeofday(), но при её выполнения были получены аналогичные результаты.

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

109. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Аноним (109), 28-Сен-21, 22:27

Вопрос в том, зачем джава стомиллионов раз получает время;)

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

66. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Вадик (??), 28-Сен-21, 16:24

Уберите пробел!
> cat /sys/devices/system/clocksource/clocksource0 /available_clocksource

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

73. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (73), 28-Сен-21, 16:48

запоминиается простое: переход возможен, игра режимами на рабочих системах - это созидание.

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

68. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (68), 28-Сен-21, 16:30

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

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

71. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 16:44

Логические связи в переводе утеряны. В оригинале Убунту стала быстрее в 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.

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

72. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 16:46

Прям хоть сам перепроверяй и перебенчмаркивай.

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

112. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от evk (??), 28-Сен-21, 23:01

ТОлько похоже имелось в виду Ubunta tsc быстрее CentOS xen
А ответа почему Ubunta xen vмедленне CentOS xen никто не дал.
И четкого ответа про Ubunta tsc и CentOS tsc тоже
Вообще автор правильно постеснялся это выложить в общий доступ сразу.
Похоже со временем порог критического восприятия сильно упал.

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

115. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (117), 28-Сен-21, 23:57

Мне кажется что Цент из коробки шел с настроенным tsc. А в Убунте оставили xen для совместимости или не тестировали. Потому что Амазон внес правки только в убунту

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

70. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от rm2 (?), 28-Сен-21, 16:44

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

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

74. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Михрютка (ok), 28-Сен-21, 16:52

>> 32% всего времени тратится на вызов os::javaTimeMillis(), используемый для получения информации о текущем времени.
> Осталось неясным, зачем эта хрень прям столько раз это вызывает. Вроде бы
> в процессе выполнения запросов к БД текущее время может понадобиться только
> ради дебага (профайлинга), а в продакшене он должен быть отключён.
в БД иногда еще пишут.
>>>Cassandra database cluster had switched to Ubuntu and noticed write latency increased by over 30%

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

129. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от пох. (?), 29-Сен-21, 09:35

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

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

76. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Штунц (?), 28-Сен-21, 16:59

пару лет назад читал статью, так там во много раз ускоили выполнение JAVA программ, заменив источник случайных чисел

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

90. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 18:08

Бенчу из статьи 7 лет. Там уже и джава по другому работает небось.

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

79. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от sdkhflskhgl (?), 28-Сен-21, 17:10

а как они синхронизировали TSC на разных процессорах? там же разные значения могут быть... или они аффинити зажали на один кристалл?

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

161. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (160), 01-Окт-21, 04:52

Время вычисляет ядро, а оно видит все процессоры.

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

81. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (81), 28-Сен-21, 17:18

Интересно

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

89. "Анализ влияния на производительность выбранного в системе ис..." +2 +/–

Сообщение от Аноним (89), 28-Сен-21, 18:08

Вот, рекомендую
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#Disabl...
https://deeperf.com/2019/04/30/tsc-clock-missing-caused-perf.../

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

91. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (22), 28-Сен-21, 18:16

Единственный полезный коммент ко всей этой старой статье.

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

121. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Alladin (?), 29-Сен-21, 00:43

Лучше еще добавить mitigations=off

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

106. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Онаним (?), 28-Сен-21, 22:12

Потыстировал на узком цикле с clock_gettime(CLOCK_MONOTONIC).
В tsc_mode=1 clocksource xen от clocksource tsc отличается % так на 10 (эмулируемый tsc выигрывает, как ни странно).
А tsc_mode=2 уже ссыкотно, потому что железо может с tsc косячить.

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

107. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Онаним (?), 28-Сен-21, 22:13

Но сама проблема есть, если воткнуть clocksource hpet, производительность тестового цикла падает в 2.5 раза...

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

108. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (108), 28-Сен-21, 22:20

Надо аппаратно ускоренный источник времени в виде отдельной платы. Чтоб убунта летала.

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

110. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 28-Сен-21, 22:50

Очень глупая идея, где нужны очень низкие задержки...

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

119. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (117), 29-Сен-21, 00:00

Тогда можно время просто не запрашивать просто прибавлять какой-нибудь счетчик в оперативе и все.

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

125. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Crok (?), 29-Сен-21, 06:01

Уже сделали, проверяйте: HPET 😃

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

139. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (54), 29-Сен-21, 15:04

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

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

141. "Анализ влияния на производительность выбранного в системе ис..." +1 +/–

Сообщение от Аноним (54), 29-Сен-21, 15:08

В современных процессорах Intel, TSC зависит от индивидуальной частоты процессора, которая не меняется. Точность составляет менее 1 наносекунды на современных CPU.
HPET - это таймеры в чипе на материнской плате. Частота этих таймеров составляет не менее 10 МГц, что намного ниже частоты процессора.
Инвариантный TSC будет работать с постоянной скоростью во всех состояниях ACPI P-, C- и T. Это архитектурное поведение в дальнейшем. На процессорах с поддержкой неизменного TSC ОС может использовать TSC для обслуживания таймеров настенных часов (вместо таймеров ACPI или HPET). Чтение TSC намного эффективнее и не несет накладных расходов, связанных с переходом кольца или доступом к ресурсу платформы.
-------------------
Изменение Intel, отправленное в Linux 5.4 и подлежащее возврату в текущую стабильную серию, - отключение HPET для систем Coffee Lake.
https://bugzilla.kernel.org/show_bug.cgi?id=203183
В связи с сообщениями об ошибках, полученными как минимум за полгода, а также с тем, что обходные пути не дали результатов, разработчики ядра решили внести таймер высокоточных событий (HPET) в черный список на системах Coffee Lake.
Некоторые системы Coffee Lake имеют перекошенный таймер HPET при входе в состояние питания PC10, что в свою очередь отмечает счетчик временных меток (TSC) как нестабильный.

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

122. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от yamlcoder (?), 29-Сен-21, 00:53

> Later that year I prototyped the c2 frame pointer fix that became -XX:+PreserveFramePointer, which fixes Java stacks in these profiles
Сейчас таких специалистов не делают. Не было стактрейсов, запатчил JVM, чтобы были, потом ещё и заапстримил. Степень глубины копания поражает.

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

130. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от пох. (?), 29-Сен-21, 09:39

Глубины копания под фонарем, потому что там светлее?
Проблема, ежу понятно - что-то сломали в ядре/glibc/где-то рядом.
Но ее искать некому, некогда и вообще, так можно починить что-то конкурентам.
Давайте патчить jvm!

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

137. "Анализ влияния на производительность выбранного в системе ис..." –2 +/–

Сообщение от Михрютка (ok), 29-Сен-21, 14:26

ну да, когда у меня rhel6 под hyperv время не держал совсем, то есть вообще, это же однозначно было от того, что сломали ядро или глибцэ.
а не потому, что hyperv на tsc клал.

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

134. "Анализ влияния на производительность выбранного в системе ис..." –1 +/–

Сообщение от Аноним (134), 29-Сен-21, 11:44

В C# такого нет.

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

127. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Anonim (??), 29-Сен-21, 08:39

Ubuntu 19-20. Tsc as default.

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

133. "Анализ влияния на производительность выбранного в системе ис..." +/–

Сообщение от Аноним (134), 29-Сен-21, 11:35

Статья 2014 года в лучшем случае Убунту 14.04 и правки сделали уже тогда причем сам амазон просто поправил свой образ и всё.

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

163. Скрыто модератором +1 +/–

Сообщение от Линус не Торвальдс (?), 04-Окт-21, 03:34

Выход есть!✨
Внимание! ⚠️ Не рекомендуется начинать просмотр видео без защиты от радиации!💀
☢️ https://www.youtube-nocookie.com/embed/JK3eTGkX6qY?autoplay=... ☢️

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Анализ влияния на производительность выбранного в системе ис..."	+11 +/–
Сообщение от Аноним (1), 28-Сен-21, 13:27
виртуализация она такая, да
Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от Аноним (25), 28-Сен-21, 14:39
	Больше виртуализации. XEN, JVM я надеюсь они как-то хотя бы бизнес логику и тарифы скриптуют хотя бы через ScriptEngine А потом героический чиним таймеры =)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Анализ влияния на производительность выбранного в системе ис..."	+2 +/–
	Сообщение от Аноним (85), 28-Сен-21, 17:30
	Исскусственный интеллект во всей красе!
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Анализ влияния на производительность выбранного в системе ис..."	+20 +/–
Сообщение от Аноним (2), 28-Сен-21, 13:28
Брендану респект
Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Анализ влияния на производительность выбранного в системе ис..."	+3 +/–
	Сообщение от Аноним (25), 28-Сен-21, 14:40
	И от меня. Тоже.
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Анализ влияния на производительность выбранного в системе ис..."	+15 +/–
Сообщение от Аноним (3), 28-Сен-21, 13:33
Интересно и полезно. Спасибо.
Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Анализ влияния на производительность выбранного в системе ис..."	–3 +/–
Сообщение от Аноним (4), 28-Сен-21, 13:33
>CentOS >Ubuntu Выходит, всё, Netflix уже не использует FreeBSD?
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Анализ влияния на производительность выбранного в системе ис..."	–5 +/–
	Сообщение от A.Stahl (ok), 28-Сен-21, 13:41
	Что значит не использует? Использует. В том же объёме как и последние 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Анализ влияния на производительность выбранного в системе ис..."	+1 +/–
	Сообщение от Аноним (-), 28-Сен-21, 14:01
	> Что значит не использует? Использует. В том же объёме как и последние > 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют. Готовишься к зиме, газифицируя лужи? https://news.ycombinator.com/item?id=28584738 > 8 days ago > Serving Netflix Video at 400Gb/s on FreeBSD > ... > polskibus 8 days ago [–] > Was FreeBSD your first choice? Or did you try with Linux first? What were the numbers for Linux-based solution, if there was one? . > drewg123 8 days ago [–] > FreeBSD was selected at the outset of the Open Connect CDN (~2012 or so). > We did a bake off a few years ago, and FOR THIS WORKLOAD FreeBSD outperformed Linux. I don't want to get into an OS war, that's not productive. ... > drewg123 8 days ago [–] > Yes. I ran it for a bake off ~2 years ago. At the time, the code in linux was pretty raw, and I had to fix a bug in their SW kTLS that caused data corruption that was visible to clients. So I worry that it was not in frequent use at the time, though it may be now. >
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Анализ влияния на производительность выбранного в системе ис..."	+1 +/–
	Сообщение от Михрютка (ok), 28-Сен-21, 14:24
	>>>последние 10 лет: пара маршрутизаторов, которые стрёмно трогать, но свою задачу выполняют. это которые которые у них в CDN видео стримят по 400 Gb/s с хоста? зачотные маршрутизаторы, я тож такой хочу.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	82. "Анализ влияния на производительность выбранного в системе ис..."	–3 +/–
	Сообщение от aname (?), 28-Сен-21, 17:18
	Нетфликс- не твоя шарага, в которой есть то, что стрёмно трогать, потому что разобраться с этим некому, а ты не умеешь, а организация, в которой есть деньги и желающие поработать над решением задач.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	114. "Анализ влияния на производительность выбранного в системе ис..."	+5 +/–
	Сообщение от Михрютка (ok), 28-Сен-21, 23:50
	однажды к Фрейду подошла дочка и сказала: - папа! мне сегодня снилось, как наш сосед герр Штольц показывает мне свой сервер. но у него был такой маленький пыльный сервер и непроизводительный и падал каждые пять минут! а потом я подошла к тебе и ты мне показал свой сервер, и он был такой большой, красивый и мощный и очень долго не падал... - дура! иногда сервер - это просто сервер! - оборвал дочку Фрейд.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	131. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от bOOster (ok), 29-Сен-21, 10:06
	Правильно, там прагматичный капитализм, и им дела нет до отмороженных фанатиков в принятии решения о смене FreeBSD на уг.. Так же как и центральное маршрутизируещее ядро в Амазон.
	Ответить \| Правка \| К родителю #82 \| Наверх \| Cообщить модератору


	8. "Анализ влияния на производительность выбранного в системе ис..."	+2 +/–
	Сообщение от Аноним (-), 28-Сен-21, 13:45
	>> при переводе СУБД Cassandra c CentOS на Ubuntu в окружениях, выполняемых в облаке Amazon EC2 на базе Xen >> выполняемых в облаке Amazon EC2 на базе Xen >>CentOS >>Ubuntu > Выходит, всё, Netflix уже не использует FreeBSD? "Избирательное чтение. Мастеркласс №2983 от опеннетных Пингвиняш."
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	14. "Анализ влияния на производительность выбранного в системе ис..."	+3 +/–
	Сообщение от Михрютка (ok), 28-Сен-21, 14:00
	https://people.freebsd.org/~gallatin/talks/euro2021.pdf
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	16. "Анализ влияния на производительность выбранного в системе ис..."	+2 +/–
	Сообщение от Аноним (4), 28-Сен-21, 14:04
	Спасибо. Как же я был не прав...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	135. "Анализ влияния на производительность выбранного в системе ис..."	–1 +/–
	Сообщение от Аноним (135), 29-Сен-21, 11:54
	Для тех кто искал полный доклад: https://www.youtube.com/watch?v=_o-HcG8QxPc Обсуждение с автором доклада (drewg123): https://news.ycombinator.com/item?id=28584738
	Ответить \| Правка \| Наверх \| Cообщить модератору

5. "Анализ влияния на производительность выбранного в системе ис..."	–19 +/–
Сообщение от _kp (ok), 28-Сен-21, 13:39
Вот до чего доводит программирование с низким порогом мышления. Только что заметили элементарный тормоз. ;)
Ответить \| Правка \| Наверх \| Cообщить модератору


	100. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от _kp (ok), 28-Сен-21, 20:30
	>>просто никому не рассказывал и тихонечко посмеивался Ну как молчал? Писал. По началу возмущался, как так, я нашел какой то баг, а всем пофиг. Хотя, на многие замечания и багрепорты и сейчас некоторым глубоко пофиг. А когда железо было дохлое, что влияние подобных проблем всплывало быстрее, и эта тоже. А тут даже багом не пахнет, а просто не задумывались что скрывается под капотом изящных решений. Реально думал, что кто занимается мало мальски производительными системами, все в курсе. И очень давно.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	102. "Анализ влияния на производительность выбранного в системе ис..."	+3 +/–
	Сообщение от _kp (ok), 28-Сен-21, 20:51
	> А знаешь, на что не пофиг? На патчи! > С дивана-то все умеют советы давать. И с патчами бывает... Вот в прошлом месяце поблагодарили в одном проекте за патч аж 2015 года. А поначалу послали. Кто там только в старье копался. :) Так не всегда, но для примера, вот. А по данной проблеме какой патч? Тут дело в культуре системостроения.
	Ответить \| Правка \| К родителю #135 \| Наверх \| Cообщить модератору


	132. "Анализ влияния на производительность выбранного в системе ис..."	–1 +/–
	Сообщение от пох. (?), 29-Сен-21, 11:27
	> А по данной проблеме какой патч? банальный - -откатывающий неведомое изменение в ведре между тем что было у центоси и тем что стало в бубунточке (скорее всего дело не в названии а в том что у бубунточки ведро банально на пять лет новее) Только вот некому выяснить, что это было за деструктивное изменение. Ну и другой банальный патч - исправляющий уродца кашмандра непонятно зачем дергающему таймер с миллисекундными интервалами. Только снова некому выяснить что это за нёх и переписать прямыми руками. Век тяпляперов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	138. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от Михрютка (ok), 29-Сен-21, 14:38
	> Ну и другой банальный патч - исправляющий уродца кашмандра непонятно зачем дергающему > таймер с миллисекундными интервалами. дяденька, если в базе есть поле timestamp, вы знаете другие способы получить его значение для инсерта/апдейта, кроме как gettimeofday сотоварищи?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	146. "Анализ влияния на производительность выбранного в системе ис..."	–2 +/–
	Сообщение от пох. (?), 29-Сен-21, 16:20
	Если дошло ажно до того что его дерганье тормозит инсерт - да, знаю: не дергать. Это gettimeofday с разрешением в 1/100 секунды. Что и само по себе скорее всего ненужное ненужно и хорошо если в базу не записывается округленным до секунд. Отдельный вопрос что вы такое там пишете с такой частотой и нахрена же, но его следует задавать претенденту на роль архитектора. А вот вопрос как не дергать с наносекундным интервалом - джуниор сопливытирателям. И при неправильном ответе даже на роль уборщицы не брать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	147. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от Михрютка (ok), 29-Сен-21, 17:04
	> Если дошло ажно до того что его дерганье тормозит инсерт - да, хинт - его дерганье не увеличивало задержки при записи до миграции и перестало увеличивать после смены clocksource после миграции. > Отдельный вопрос что вы такое там пишете с такой частотой дяденька, это нетфликс, у которого 200 лямов субскрайберов, и который отдает по америке трафика больше, чем ютуп с амазон стримингом вместе взятые.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	149. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от пох. (?), 30-Сен-21, 10:36
	> хинт - его дерганье не увеличивало задержки при записи до миграции кто сказал? И по сравнению с чем "увеличивало" ? enlarge your what? Оно просто стало укладываться в допустимые их инфраструктурой задержки, разбираться с причиной некогда, надсмотрщик машет кнутом. > дяденька, это нетфликс, у которого 200 лямов субскрайберов, и который отдает по америке трафика > больше отдает он этот траффик совсем не из тазы банных, а вот теми самыми полутора уцелевшими freebsd. и 200лямов сабскрайберов это ни разу не все двести что-то лихорадочно кликают, они вообще могут неделями туда не заглядывать. А если и заглянут - видео - оно часами смотрится. Никакого сверххайлоада на _базу_ там нет и быть не может. Ну если только обезьянки его сами себе не наобезьянкали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	150. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от Михрютка (ok), 30-Сен-21, 12:27
	>> хинт - его дерганье не увеличивало задержки при записи до миграции > кто сказал? И по сравнению с чем "увеличивало" ? enlarge your what? да он сам и сказал. вы его блог-то читали? > отдает он этот траффик совсем не из тазы банных, а вот теми > самыми полутора уцелевшими freebsd. и 200лямов сабскрайберов это ни разу не > все двести что-то лихорадочно кликают, они вообще могут неделями туда не > заглядывать. А если и заглянут - видео - оно часами смотрится. > Никакого сверххайлоада на _базу_ там нет и быть не может. Ну > если только обезьянки его сами себе не наобезьянкали. средний нетфликсовский подписчик до карантина смотрел 2 часа видео в день (допустим, что нефликс учел одновременные просмотры на нескольких устройствах). в 2014 у нетфликса было 50 миллионов подписчиков. это 4 миллиона часов просмотра в час, на минутку. для просмотра инфраструктура на амазоне должна подписчика (высосано из моего пальца) - аутентифицировать - проверить биллинг - проверить, сколько гавриков уже смотрят под этим аккаунтом (до пяти на премиуме) - вытащить список просмотренного видео - вытащить список того, что ему хочется посмотреть и еще кучу других списков - следить, что он бровзит, и корректировать все эти списки соответственно - если он кликнул плей - проверить, есть ли в cdn это видео, если нет - отдать из библиотеки - а да - все это залогировать для статистики, и считать, сколько времени он смотрит - а подписчик посмотрел пять минут, видит - тягомотина какая-то, стопает и начинает снова копаться, что бы такого посмотреть то есть в 2014 году это как раз все для одного зрителя за миллисекунду надо было обработать, даже если он просто открыл нетфликс, и кликнул плей. хотя бы чтоб записать, сколько он времени смотрит данное видео. я нигде не напутал? это для вас достаточный хайлоад?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	151. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от пох. (?), 30-Сен-21, 12:35
	> средний нетфликсовский подписчик до карантина смотрел 2 часа видео в день то есть целое ОДНО видео в день (а в целом так и должно - он же еще в этот день, наверное, работал чтобы оплатить подписочное рабство)? Ахеренная нагрузка на базу. > (высосано из моего пальца) заметно. А теперь пробуем включить мозг и подумать - а где тут нужна _запись_ в базу да еще с микросекундными таймстемпами. Не "где макак побырому нагoвнякал", а где НУЖНА.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	152. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от Михрютка (ok), 30-Сен-21, 13:58
	> то есть целое ОДНО видео в день (а в целом так и > должно - он же еще в этот день, наверное, работал чтобы > оплатить подписочное рабство)? Ахеренная нагрузка на базу. вы хоть обсарказмируйтесь. ровно это изменит факт, что все действия пользователя в течение часа желательно было бы обработать за одну миллисекунду (на самом деле еще меньше, т.к. 40% нетфликса - это сша/канада). >> (высосано из моего пальца) > заметно. А теперь пробуем включить мозг и подумать - а где тут > нужна _запись_ в базу да еще с микросекундными таймстемпами. > Не "где макак побырому нагoвнякал", а где НУЖНА. везде, начиная от авторизации. где мы должны хотя бы зафиксировать факт логина, добавить плюсик к числу подключенных устройств и записать, с какого адреса и какого устройства залогинились. про микросекундные таймстампы вообще не понял, к чему это? у вас есть ультрабыстрый способ дернуть System.currentTimeMillis, при котором она возвращает только целые секунды?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	153. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от пох. (?), 30-Сен-21, 14:05
	Блин, типовой пользователь за этот час не сделал ровно НИХ-Я! Киношку он смотрит, и НИЧЕГО в это время больше не делает. И еще сорок минут будет ничего не делать. А потом пойдет спать. На паузу может поставить, но об этом факте незачем записывать в базу с наносекундной точностью чтоб потом героически бороться с ней. > везде, начиная от авторизации. где мы должны хотя бы зафиксировать факт логина, добавить плюсик к > числу подключенных устройств и записать, с какого адреса и какого устройства залогинились. то есть раз в неделю или реже. Потому что никто, разумеется, устройство не выключает. > про микросекундные таймстампы вообще не понял, к чему это? у вас есть ультрабыстрый способ > дернуть System.currentTimeMillis, при котором она возвращает только целые секунды? "вы не прошли собеседование на ассистента второго младшего помощника junior developer" Попробуйте устроиться менеджером проекта, там таких берут.
	Ответить \| Правка \| К родителю #152 \| Наверх \| Cообщить модератору


	154. "Анализ влияния на производительность выбранного в системе ис..."	+/–
	Сообщение от Михрютка (ok), 30-Сен-21, 15:17
	> Блин, типовой пользователь за этот час не сделал ровно НИХ-Я! Киношку он > смотрит, и НИЧЕГО в это время больше не делает. И еще > сорок минут будет ничего не делать. А потом пойдет спать. и что? все эти сорок минут время подключения и просмотра будут считать, с минутной точностью, но будут. вы бы почитали что-нить общедоступное про нетфликсовские метрики. > На паузу может поставить, но об этом факте незачем записывать в базу > с наносекундной точностью чтоб потом героически бороться с ней. дядя, вы уже подзадрали с вашими наносекундами. я там вопрос задал про способ получить время из джавы быстрее, жаль, что ваши растопыренные пальцы помешали вам попасть по клаве и ответить. >> везде, начиная от авторизации. где мы должны хотя бы зафиксировать факт логина, добавить плюсик к >> числу подключенных устройств и записать, с какого адреса и какого устройства залогинились. > то есть раз в неделю или реже. Потому что никто, разумеется, устройство > не выключает. дооо. кому там мозги включить надо? устройств обычно больше одного. и даже больше, чем допустимое по тарифному плану число одновременных сеансов.
	Ответить \| Правка \| К родителю #153 \| Наверх \| Cообщить модератору