Кстати, если использовать обычные уши вместо рельс, то проблема ровно такая же. На Arista уши отстегиваются легко и крепление к свитчу короткое по длине, поэтому это не проблема в данном конкретном случае. А вот если уши имеют длинное крепление и/или требуют откручивания винтов сбоку, то такие свитчи также невозможно установить/демонтировать в таких стойках.
Это не так, если речь идёт о современных процессорах.
При использовании amd_pstate все простаивающие ядра опускаются до 400мгц, а TDP перераспределяется между загруженными ядрами, позволяя им буститься до более высоких частот. Без использования performance cpu governor ядра не так быстро выходят из спячих состояний, соответственно latency в системе становится хуже.
Никаких деградаций процессора, троттлинга и т.д. не будет.
Согласен, причём можно было бы пошэрить bandwith 25-гигабитных портов как на диски, так и на интернет, а если бы не хватило — QSFP28 100-гигабитный решил бы проблему.
В целом если бы сервис был написан изначально на Go, а не на Node.js, то и не пришлось бы выносить в отдельную очередь, поскольку каждый http-запрос в Go обрабатывается в отдельной горутине
Там же чёрным по белому написано: ConnectX-7 Smart NIC.
Эта сетевая карта в свободной продаже
Это же вроде обычные QSFP порты?
Кстати, если использовать обычные уши вместо рельс, то проблема ровно такая же. На Arista уши отстегиваются легко и крепление к свитчу короткое по длине, поэтому это не проблема в данном конкретном случае. А вот если уши имеют длинное крепление и/или требуют откручивания винтов сбоку, то такие свитчи также невозможно установить/демонтировать в таких стойках.
У вас вертикальные PDU прикручиваются? У нас они просто в ZeroU лотки вставляются. Чтобы снять — достаточно просто приподнять PDU.
Я уже пробовал так сделать, но тогда свитч слишком глубоко в стойке
Написал пост про нашу проблему, если интересно)
https://habr.com/ru/posts/902370/
А ещё бывает вот так при установке rear-to-front свитчей
А ещё бывает вот так при установке rear-to-front свитчей
А ещё бывает вот так при установке rear-to-front свитчей
А ещё бывает вот так при установке rear-to-front свитчей
Хм, верно, у меня также.
Спасибо! Поправлю статью.
Из подобных никакие не использовал. Знаю что есть CoreOS и Flatcar, но по опыту моих коллег они ещё очень далеки от Talos Linux.
Пробовали
spec_rstack_overflow=off? А ещё интересно посмотреть на результаты сmitigations=off. Всё-таки процессор более старый у вас (zen 3).Это не так, если речь идёт о современных процессорах.
При использовании amd_pstate все простаивающие ядра опускаются до 400мгц, а TDP перераспределяется между загруженными ядрами, позволяя им буститься до более высоких частот. Без использования performance cpu governor ядра не так быстро выходят из спячих состояний, соответственно latency в системе становится хуже.
Никаких деградаций процессора, троттлинга и т.д. не будет.
Согласен, причём можно было бы пошэрить bandwith 25-гигабитных портов как на диски, так и на интернет, а если бы не хватило — QSFP28 100-гигабитный решил бы проблему.
Это читать невозможно
В целом если бы сервис был написан изначально на Go, а не на Node.js, то и не пришлось бы выносить в отдельную очередь, поскольку каждый http-запрос в Go обрабатывается в отдельной горутине
А затем чтобы не россияне брали сервера в Hetzner и OVH, а европейцы в ruVDS.
https://core.telegram.org/bots/api#sendchataction