edo1h

Умножение требует три такта процессора, сдвиг один такт. Экономия двух тактов на вычислении адреса во фреймбуфере абсолютно некритична в реальной жизни, основное время уходит на совсем другие участки кода

Update: и да, в реальном коде все равно будет умножение, так как разрешение не константа

Как понимаю он с Bitlocker работает в связке

https://hexus.net/tech/news/software/135266-micros...

Как минимум, dns-запросы идут у вас через vpn, сто сто если выв рабочее время сидите на порносайтах, то теоретически работодатель может это увидеть.

Рядом написали про t.10 pi и end-to-end data protection. Нужно понимать, что это опциональная возможность протокола, которая поддерживается только некоторыми накопителями (насколько я знаю, среди ёмких hdd таких нет). И только поддержки со стороны накопителя недостаточно, нужна поддержка со стороны софта (файловых систем, например) и/или рейд-контроллера. В общем, на практике я такое видел только в «настоящих» схд.

По скорости интерфейса, глубине очереди, двунаправленности отличия от sata есть, но для hdd они роли не играют (а для ssd есть nvme).

Итого остаётся только удобство подключения десятков накопителей и внешних полок (экспандеры, multipath).
И да, к sas-контроллерам и экспандерам можно так же подключать и sata-накопители.

Про sas вас дезинформировали, волшебные пузырьки t10 pi поддерживаются разве во взрослых схд, но там обычно вендорлок, так что sas это или пропиетарный протокол — роли не играет.
Поясню: t10 pi должен поддерживаться накопителем (нестандартный размер сектора) и софтом и/или рейд-контроллером. Насколько я знаю, ёмких hdd с поддержкой t10 pi нет.

Примерно то же самое с nvme: nvme pi в стандарте есть, некоторые (немногие) серверные накопители поддерживают форматирование с нестандартным размером сектора. Однако что делать с этим дальше, непонятно, поддержка в софте в зачаточном состоянии.
Просто сказать mkfs.ext4 на отформатированном с нестандартным размером накопителе не получится.

Итого, подход zfs, не требующий для end-to-end data protection какой-то поддержки со стороны железа, мне кажется более жизнеспособным.

P.S. В качестве транспорта nvme использует pcie, насколько я знаю, в протоколе есть контрольные суммы, так что можно быть [почти] уверенным, что к накопителю/от накопителя данные будут доставлены без искажений. Возможно, вопрос был в этом. Но это совсем не end-to-end.
В sata, кстати, данные по кабелю тоже передаются с контрольными суммами.

Выдача сертификатов «для всех доменов» была бы явной дырой в безопасности, единственное применение, которое приходит в голову — MITM атака.

Подобные решения используются только в корпоративных файрволах, но там на компьютере пользователя устанавливается доверие к подписывающему сертификату.
Ещё вроде бы в Казахстане была подобная история на уровне государства, но там в итоге от неё отказались.

Если материнка имеет 4 порта SATAIII 6Gbps - это на каждый порт или на все диски делится?

На каждый

Спрашиваю потому как подключил 4 диска к ПК и при копировании с диска на диск получаю 100-120МБ\с

А что за диски? Может быть для них это нормальная скорость.

При копировании между двумя sata ssd скорости выше 400 мегабайт в секунду вполне достижимы.

Без каких-то серьёзных ахитектурных изменений вас спасёт только партицирование на несколько серверов, чтобы на каждом была только часть таблицы.

На LA вообще смотреть не стоит.
Если время генерации страничек устраивает, то всё нормально (но учитывайте, что у вас нет запаса мощности на случай наплыва пользовтелей, неудачных обновлений прграммистами и т. п.).
Если не устраивает — увеличивайте число ядер. Можно увеличить число ядер (не важно, intel или amd), но лучше смотреть в сторону горизонтального масштабирования (увеличения числа серверов). Так проще обеспечивать отказоустойчивость, дальнейший прирост производительности.

насколько я понимаю, окончательное решение о переключении за клиентом. точка может «намекнуть» клиенту, может даже сбросить его, но даже после этого клиент может упорно пытаться переподключиться к той же точке.

можете прочитать серию статей тут:
https://wi-cat.ru/category/wi-fi-roaming/

а зачем вам дамп? копируете каталог БД на новый сервер, запускаете там mariadb и всё должно заработать.

zpool показывает свободное место без вычета контрольных блоков (их же пока там нет).
zfs же показывает (примерно) то, что вам нужно.

если бы не было никаких накладных расходов, то вы бы увидели 3.6T:

((500 ⋅ (10^9)) ⋅ (10 − 2)) / (1024^4) ≈ 3.637978807091713

Рационально ли мое решение?

Для MVP подойдёт, конечно.

Только вместо raid0 я бы порекомендовал иметь по отдельной файловой системе на каждый диск, а потом при необходимости можно «слепить» их с помощью mergerfs. В этом случае смерть одного диска приведёт к потере только хранившихся на нём файлов.
А ещё raid0 с малым размером блока не особо хорош в многопоточной нагрузке.

драйвер вам не надо писать, поддержку MARK/SPACE я добавил в драйвер много лет назад (хотя и без неё можно было обойтись, переключая нужным образом ODD/EVEN, но …)

в новых малинках по умолчанию наружу смотрит mini UART, который не умеет 9 бит, а полноценный UART (ttyAMA0) занят блютусом, это настраивается, больше деталей тут:
https://www.raspberrypi.org/documentation/configur...

после этого ничего raspberry-специфичного в этой задаче нет, мы имеем обычный полноценный UART, который умеет 9 бит.

остаётся написать/взять готовую реализацию RS-485. уверен, что гугл по запросу «CMSPAR RS-485» выдаст кучу примеров/реализаций на разных языках.

Вопрос: из-за чего такая фантастически низкая скорость и как это изменить?

а вы уверены, что она фантастически низкая? 1000 пишущих транзакций в секунду — отличная производительность.

mysql (как и большинство БД) по умолчанию считает транзакцию завершённой после успешного fsync.
https://www.percona.com/blog/2018/02/08/fsync-perf...
https://docs.google.com/spreadsheets/d/1E9-eXjzsKb... (колонка journal iops)

так что да, писать в базу не по одной строчке, а пачками (уменьшать число транзакций). или отключать fsync, если данные не особо важны.

Или приспосабливать LISTEN/NOTIFY, или использовать внешний по отношению к базе механизм очередей.

BTW, в статье обсуждали LISTEN/NOTIFY, но в комментариях не особо тепло отнеслись к этому подходу.

Моё мнение: если речь именно о «подождать прихода данных в базе», то LISTEN/NOTIFY отлично подходит (и сам не раз использовал), если же нужны многие нагруженные очереди — лучше взять готовые реализации.

Здесь указывается

ну там же ответили: один воркер может проснуться и «схапать» все ожидающие входящие соединения, в результате будет дисбаланс ну и вообще не очень хорошо.

Как стоит поступить на многоядерной системе Debian 11 x64?

правила простые: если что-то не понимаете — не меняете, дефолт нжинкса достаточно хорош для большинства применений.

Говоря простым языком, на сайте может быть онлайн более одного человека при multi_accept off?

ИМХО проще взять и проверить, чем тут спрашивать.

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

в таймзоне смещение указывается с другим знаком
https://unix.stackexchange.com/questions/104088/wh...

«Потребление swap» нужно в первую очередь смотреть не в гигабайтах, а в операциях в секунду, если у вас нет никакого мониторинга, то можно с помощью iostat -mxzp 10
Если у вас много IOPS на разделе со свопом — тогда и нужно что-то предпринимать, если же нет — радуйтесь, у вас там осели неиспользуемые данные, можно сказать бесплатно память добавилась (хотя для заметного эффекта размер свопа должен быть одного порядка с размером памяти, конечно).

«Много IOPS» — это сколько? Можно считать в процентах от производительности диска, условно HDD умеет 100 IOPS, так что менее 10 обращений к свопу в секунду (менее 10% от потенциала диска) не окажут существенного влияния на производительность системы. Для SSD цифры будут куда выше, там и тысячи IOPS на своп могут быть нормальными (но для десктопных SSD надо помнить про ресурс дисков/забивание SLC кэша).

что будет при увеличении кол-ва машин (боюсь увидеть 100%)?

Само по себе это не не страшно. Но вот если приложениям (виртуальным машинам в вашем случае) не хватит общей памяти (физическая+своп), то у ядра не остаётся выбора кроме OOM killer.

Повторюсь, особого смысла в свопе, размером на порядок меньшим, чем объём физической памяти, я не вижу.
Обычно я настраиваю размером или с RAM (там, где он нужен, как в вашем случае), или вообще без swap (если на хосте, скажем, только postgresql или elsaticsearch).

Резюмируя:
- если у вас всё нормально с производительностью, IOPS, связанных со свопом мало — то ничего не делать, разве что рассмотреть возможность увеличения раздела со свопом «на вырост»;
- если дисковая система тормозит, то увеличивать объём оперативной памяти (или умерять аппетиты приложений).