Comments 24
Иронично
Ой, удалите плиз, я перепутал email
В случае с SDS будет весьма полезно. Спасибо большое
регулятор частоты в режиме performance будет всегда выкручивать частоту процессора на максимум. На постоянной основе использовать не стоит. Только для получения максимальных баллов в бенчмарках. На дальних дистанциях в таком режиме от перегрева начнется троттлинг и вся производительность упадет. А при долгом использовании питальник на плате быстро деградирует. Пол года-год и пробьет. Вдруг кто из незнающих прочтет, будет предупреждением!
Это не так, если речь идёт о современных процессорах.
При использовании amd_pstate все простаивающие ядра опускаются до 400мгц, а TDP перераспределяется между загруженными ядрами, позволяя им буститься до более высоких частот. Без использования performance cpu governor ядра не так быстро выходят из спячих состояний, соответственно latency в системе становится хуже.
Никаких деградаций процессора, троттлинга и т.д. не будет.
Статья очень интересная, но при попытке воспроизвести это на десктопе (AMD Ryzen 9 5900X, Samsung SSD 980 PRO) результаты получились несколько иные: с spec_rstack_overflow=microcode IOPS случайного доступа действительно сильно (в полтора раза!) увеличиваются, линейная запись почти не меняется, но вот IOPS (как и BW) линейного чтения падает ещё сильнее (в 3 раза!). И для десктопа такой размен уже выгодным не выглядит, тем более что ещё и уязвимость дополнительная добавляется.
Команды я запускал вот такие:
fio -size=10G -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 \
-rw=read -runtime=60 -output="$1-read.txt"
fio -size=10G -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 \
-rw=write -runtime=60 -output="$1-write.txt"
fio -size=10G -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 \
-rw=randread -runtime=60 -output="$1-randread.txt"
fio -size=10G -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 \
-rw=randwrite -runtime=60 -output="$1-randwrite.txt"Без этой опции ядра cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow выдает "Mitigation: Safe RET", с ней "Vulnerable: Microcode, no safe RET".
Пробовали spec_rstack_overflow=off? А ещё интересно посмотреть на результаты с mitigations=off. Всё-таки процессор более старый у вас (zen 3).
Мистику с замедлением линейного чтения в 3 раза я прояснил. Такие высокие результаты теста на линейное чтение получаются только при условии, что тестируемый файл (`test.0.0` на 10 GB) ещё не существует и создаётся в момент запуска первого теста (а это как раз линейное чтение). Полагаю, с моими 32 GB RAM, тут где-то проявляются кеши линуха. И -direct=1 -invalidate=1 почему-то не спасает. Update: А ещё этот же эффект (ускорение линейного чтения в 3 раза) можно получить если просто поменять первые два теста (линейное чтение и запись) местами.
spec_rstack_overflow=off относительно spec_rstack_overflow=microcode добавляет 5-12% везде кроме линейного чтения.
mitigations=off относительно spec_rstack_overflow=off добавляет ещё 2-4% на случайном доступе а вот линейная запись почему-то заметно (30%) замедлилась.
В целом, относительно системы по умолчанию (все защиты активны), mitigations=off даёт выигрыш в 68% на случайном чтении/записи, и потерю 10% на линейной записи.
Ещё я провёл более реалистичный тест: сборку ядра линуха (make -j24 сразу после загрузки в single-user mode) . Относительно системы по умолчанию (все защиты активны), mitigations=off даёт выигрыш в 3.5%. Что как бы намекает, что этот выигрыш в 68% IOPS на случайном доступе - всё-таки синтетический тест, и в реальных приложениях разница скорее всего будет ближе к 3.5%.
Для сброса linux кешей можно воспользоваться документацией: https://www.kernel.org/doc/Documentation/sysctl/vm.txt# To free pagecache:
echo 1 > /proc/sys/vm/drop_caches
# To free reclaimable slab objects (includes dentries and inodes):
echo 2 > /proc/sys/vm/drop_caches
# To free slab objects and pagecache:
echo 3 > /proc/sys/vm/drop_caches
Вот 3 вариант сбросит все что можно, обычно между тестами выбирают его.
В продолжение темы:
https://devopsconf.io/moscow-rit/2019/abstracts/5219
Talos Linux, которая позволяет очень просто развернуть Kubernetes-кластер на любом окружении, легко обновлять его компоненты и поддерживать конфигурацию в одинаковом состоянии на всех узлах кластера благодаря декларативности и иммутабельности.
А можете упомянуть, какие еще ОС с подобными свойствами рассматривались? Если по этим критериям осуществлялся поиск и выборка.
Так как я всегда обновляю микрокод процессоров благодаря официальным Talos extensions amd-ucode и intel-ucode, собирая кастомные образы на factory.talos.dev, я могу себе позволить отключить софтверный патч этой уязвимости
Микрокод защищает лишь от атак в направлении пользователь->ядро и гость->хост. Но не защищает от пользователь->пользователь и виртуалка->виртуалка, для этого нужна программная заплатка.
Текущий статус защиты можно посмотреть в /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
При отсутствии программной заплатки будет статус "Vulnerable: Microcode, no safe RET".
ChatGPT проанализировала diff файл, и выдала точный ответ, какая именно настройка влияет на разницу в производительности?
Человечество обречено.
Как у члена группы, которую вы назвали обреченной, у меня вопрос. А что не так в процедуре экономии личного времени при делегировании решения задачи машинам?
Удивлен, что машина справилась с такой интеллектуальной задачей. Постепенно человек привыкнет сгружать сложные задачи, где надо подумать, машине, отупеет и вымрет.
задачи, где надо подумать
По моему, вы спутали задачу перебора с задачей на размышления.
Искать параметр в конфиге ядра, который так сильно убивает производительность, это как искать иголку в стоге сена, поскольку в kernel config'e более 6000 строк, а если файла два? Как понять какой именно параметр влияет?
Я создал два StorageClass — nvme-lvm-local и nvme-lvm-replicated-async.
А поделитесь итоговыми ямликами пожалуйста.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nvme-lvm-local
provisioner: linstor.csi.linbit.com
parameters:
linstor.csi.linbit.com/usePvcName: "true"
linstor.csi.linbit.com/storagePool: nvme-lvm
linstor.csi.linbit.com/layerList: "storage"
linstor.csi.linbit.com/allowRemoteVolumeAccess: "false"
linstor.csi.linbit.com/mountOpts: discard
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nvme-lvm-replicated-async
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: linstor.csi.linbit.com
parameters:
linstor.csi.linbit.com/usePvcName: "true"
linstor.csi.linbit.com/storagePool: nvme-lvm
linstor.csi.linbit.com/autoPlace: "2"
linstor.csi.linbit.com/layerList: "drbd storage"
linstor.csi.linbit.com/allowRemoteVolumeAccess: "false"
linstor.csi.linbit.com/mountOpts: discard
property.linstor.csi.linbit.com/DrbdOptions/Net/protocol: "A"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза