Несколько комментариев относительно упомянутого движка MDBX:
Настоятельно советую мигрировать с LMDB на MDBX, пока не "бомбанули" ошибки LMDB. Кроме этого вы получите автокомпактификацию и изменяемый размер файла БД.
MDBX появилась внутри ReOpenLDAP в ходе доработок для использования в инфраструктуре ПАО Мегафон, и произошла эта история в компании Петер-Сервис (ныне Nexign).
Об MDBX скоро будет отдельная статья, как только я закончу основную работу над C++ биндингами.
При необходимости хранить "табличные данные" с колонками и вторичными индексами рекомендую посмотреть на libfpta, а не мучиться с голым key-value.
Базовые сервисы (Google Play, Google Pay) собирают гораздо больше информации.
Поэтому либо не стоит беспокоиться (и "получать удовольствие"), либо пользоваться "кнопочным телефоном".
Любителям своих "кастомных" прошивок советую добавить явную индикацию (зажигание какого-нибудь светодиода) при активации камеры, микрофона, wifi (при его "выключении"), "нательных датчиков" и гироскопа. Вы НЕ будете разочарованы.
Мой комментарий больше про то, что описанный в статье подход позволяет отлавливать "атаки" уровня script kiddie, но не замечает тривиальных вариаций. Тем более, не заметит чуть менее чем любую целевую атаку.
Соответственно, сбор логов в условный эластик — это конечно больше чем ничего, но для отлавливания более-менее серьезных атак нужен "настоящий" SIEM с "корреляцией" событий разнесенных по времени. Появление подобных продуктов в Open Source, к сожалению, по ряду причин не предвидится.
Можно ли получить образ виртуалки (для x86) или ssh-доступ (с целью оценить готовность платформы и трудоемкость портирования собственных проектов/библиотек)?
Очень важно уточнять, что основная часть потерь не боевые, а мирное население уничтоженное фашистами (и примкнувшими коллаборантами) на оккупированной территории. Плюс 4 миллиона пленных уничтоженных в концентрационных лагерях.
Хм, а разве у них "полимеры" не кончились год назад (собственно видно по github и т.д.)?
Хотя "Остапа" все равно стоит послушать, особенно "инвесторам".
Не хочу вступать в дискуссию, но если у вас чего-то остается много, то вы за это переплатили.
И на всякий уточню:
понятно, что далеко не всегда есть возможность не покупать лишнего, просто исходя из доступного спектра моделей и других обстоятельств.
в перспективе Mellanox (или еще кто-нибудь) смогут пустить offload в серию и снизить цены, соответственно блейды на ARM-ах станут дешевле и будут ближе к оптимуму (без лишних мощностей и холоднее).
чтобы это было возможно инфраструктуру offload в ядре нужно допиливать, что понемногу и происходит.
Ну вы учитывайте что Mellanox-у нужно продавать свое железо с offload.
Поэтому сейлы Mellanox будут "накручивать" цифры всеми приемлемыми способами.
Например, выбирать для тестов версии ядра, комбинации опций и софта показывающие что без offload "жить нельзя".
ну тут вы утрируете, конечно, если бы скорость отдачи была равна (memory bandwidth)/3, все были бы счастливы )
Есть разные сценарии.
К примеру, если у вас CDN большого масштаба, то ваша целевое состояние = минимальное кол-во работающих серверов с загрузкой ~95%.
Соответственно, в целевом (эффективном) состоянии, на таких серверах вы будите упираться либо в disk i/o (для "холодного" контента), либо в memory bandwidth (для "горячего" контента).
Конечно это не массовый сценарий, но в любом случае нормальный offload для AES действительно поднимает верхний предел отдачи в три раза. Это позволяет не только увидеть другие узкие места, но и делает осмысленным их устранение.
Во-первых это развитие, приведение в порядок и оптимизация механизмов off-load. AES относительно дешево реализуется в железе, а перенос шифрования с CPU на NIC позволяет увеличить производительность отдачи контента в разы. На всякий стоит пояснить:
Когда шифрованием занимается CPU, то ему нужно (как минимум) прочитать данные из памяти, затем зашифровать и записать в память, а потом снова прочитать через DMA сетевой картой.
Если же шифрованием занимает NIC, то можно обойтись однократным чтением из памяти.
Т.е. утилизация RAM bandwidth получается в три раза меньше, и это не считая затрат CPU на само шифрование и управление буферами для зашифрованных данных. Соответственно, условный Netflix сможет раздавать со своих блейдов в три раза больше, и/или использовать менее мощные, более холодные и дешевые процессоры (ARM).
Без AES-offload в NIC выигрыш скромнее, но всё же есть. В основном за счет уменьшения кол-ва переключений между ядром и userspace — примерно также как при использовании "обычного" системного вызова sendfile.
Возможно vadimfedorenko стоит добавить эту инфу в статью.
Теоретически M$ конечно могут это "починить" (сделали же clone/fork), но отказались (видимо) из-за трудоемкости и бесперспективности (всё выходило в разы медленнее чем в Linux).
У меня такое чувство, будто в WSL1 просто наговнокодили.
Не в WSL1, а несколько раньше.
И не "наговнокодили", а скорее не решились устранять недостатки дизайна.
Многие вещи в ядре NT начинались с отличного дизайна и были заимплеменчены достаточно хорошо, но некоторые были буквально "назло бабушке уши отморожу": процессы и треды, 1/3 инфраструктуры виртуальной памяти, файловая система — там адовы накладные расходы. Потом дополнительно добавили ведро дёгтя (win32sys), а ради мифа совместимости не стали упрощать IRP-стек.
В результате имеем то что имеем — WSL1 работает со скоростью нативных системных вызовов Windows 10 (затраты на трансляцию там погоды не делают), а WSL2 почти догоняет нативное ядро Linux.
Поэтому вместо сопоставления WSL1/WSL2 корректнее сформулировать "При некоторой усредненно-взвешенной оценке ядро Windows 10 выполняет системные вызовы в 13 раз медленнее Linux" — и это действительно так.
Отличная "мясистая" статья!
Несколько комментариев относительно упомянутого движка MDBX:
Уже лучше, но еще пары "нулей" не хватает.
Примерно так и будет, см. https://github.com/informationsea/xlsxwriter-rs
Хм, а если сжечь и заново — насколько было-бы хуже/лучше?
Не считаю рациональным, но поступок заслуживает.
Хотя павленский пригвоздился к явно более незыблемой основе.
Упс, а мы-то незнали!
;)
Базовые сервисы (Google Play, Google Pay) собирают гораздо больше информации.
Поэтому либо не стоит беспокоиться (и "получать удовольствие"), либо пользоваться "кнопочным телефоном".
Любителям своих "кастомных" прошивок советую добавить явную индикацию (зажигание какого-нибудь светодиода) при активации камеры, микрофона, wifi (при его "выключении"), "нательных датчиков" и гироскопа. Вы НЕ будете разочарованы.
Мой комментарий больше про то, что описанный в статье подход позволяет отлавливать "атаки" уровня script kiddie, но не замечает тривиальных вариаций. Тем более, не заметит чуть менее чем любую целевую атаку.
Соответственно, сбор логов в условный эластик — это конечно больше чем ничего, но для отлавливания более-менее серьезных атак нужен "настоящий" SIEM с "корреляцией" событий разнесенных по времени. Появление подобных продуктов в Open Source, к сожалению, по ряду причин не предвидится.
Надо будет допилить mimikatz, чтобы использовал два хендла, или вообще запускать рой процессов с обменом в SHM ;)
У меня пара вопросов:
Ну я не со зла и в кавычках
Очень важно уточнять, что основная часть потерь не боевые, а мирное население уничтоженное фашистами (и примкнувшими коллаборантами) на оккупированной территории. Плюс 4 миллиона пленных уничтоженных в концентрационных лагерях.
Хм, а разве у них "полимеры" не кончились год назад (собственно видно по github и т.д.)?
Хотя "Остапа" все равно стоит послушать, особенно "инвесторам".
Не хочу вступать в дискуссию, но если у вас чего-то остается много, то вы за это переплатили.
И на всякий уточню:
Ну вы учитывайте что Mellanox-у нужно продавать свое железо с offload.
Поэтому сейлы Mellanox будут "накручивать" цифры всеми приемлемыми способами.
Например, выбирать для тестов версии ядра, комбинации опций и софта показывающие что без offload "жить нельзя".
Есть разные сценарии.
К примеру, если у вас CDN большого масштаба, то ваша целевое состояние = минимальное кол-во работающих серверов с загрузкой ~95%.
Соответственно, в целевом (эффективном) состоянии, на таких серверах вы будите упираться либо в disk i/o (для "холодного" контента), либо в memory bandwidth (для "горячего" контента).
Конечно это не массовый сценарий, но в любом случае нормальный offload для AES действительно поднимает верхний предел отдачи в три раза. Это позволяет не только увидеть другие узкие места, но и делает осмысленным их устранение.
Бонусов несколько.
Во-первых это развитие, приведение в порядок и оптимизация механизмов off-load. AES относительно дешево реализуется в железе, а перенос шифрования с CPU на NIC позволяет увеличить производительность отдачи контента в разы. На всякий стоит пояснить:
Без AES-offload в NIC выигрыш скромнее, но всё же есть. В основном за счет уменьшения кол-ва переключений между ядром и userspace — примерно также как при использовании "обычного" системного вызова sendfile.
Возможно vadimfedorenko стоит добавить эту инфу в статью.
"Чисто технически" вся ядра NT принципиально не умеют две вещи:
Теоретически M$ конечно могут это "починить" (сделали же clone/fork), но отказались (видимо) из-за трудоемкости и бесперспективности (всё выходило в разы медленнее чем в Linux).
Не в WSL1, а несколько раньше.
И не "наговнокодили", а скорее не решились устранять недостатки дизайна.
Многие вещи в ядре NT начинались с отличного дизайна и были заимплеменчены достаточно хорошо, но некоторые были буквально "назло бабушке уши отморожу": процессы и треды, 1/3 инфраструктуры виртуальной памяти, файловая система — там адовы накладные расходы. Потом дополнительно добавили ведро дёгтя (win32sys), а ради мифа совместимости не стали упрощать IRP-стек.
В результате имеем то что имеем — WSL1 работает со скоростью нативных системных вызовов Windows 10 (затраты на трансляцию там погоды не делают), а WSL2 почти догоняет нативное ядро Linux.
Поэтому вместо сопоставления WSL1/WSL2 корректнее сформулировать "При некоторой усредненно-взвешенной оценке ядро Windows 10 выполняет системные вызовы в 13 раз медленнее Linux" — и это действительно так.
Реклама хацкеля удалась, зачет )
А также все реализации где важна скорость работы кода.