Как устроена страничная организация памяти x86_64

В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.

Окружение

Это необязательно, но я рекомендую подготовить систему для отладки ядра Linux с QEMU + gdb. Если вы никогда этого не делали, то попробуйте такой репозиторий: easylkb (сам я им никогда не пользовался, но слышал о нём много хорошего), а если не хотите настраивать окружение самостоятельно, то подойдёт режим практики в любом из заданий по Kernel Security на pwn.college (вам нужно знать команды vm connect и vm debug).

Я рекомендую вам так поступить, потому что считаю, что самостоятельное выполнение команд вместе со мной и возможность просмотра страниц (page walk) на основании увиденного в gdb — хорошая проверка понимания.


Читать: https://habr.com/ru/articles/787502/

Building AI with MongoDB: How Patronus Automates LLM Evaluation to Boost Confidence in GenAI



Read: https://www.mongodb.com/blog/post/how-patronus-automates-llm-evaluation-boost-confidence-genai

Запуск и настройка Pentaho server с базой MSSQL

В этой статье описаны действия по установке MS SQL в качестве базы данных хоста для сервера Pentaho в архивной установке Pentaho.


Читать: https://habr.com/ru/articles/791198/

Тестирование менеджера транзакций

Привет, Хабр! Меня зовут Георгий Лебедев, я учусь на 4-м курсе ФРКТ МФТИ и работаю в команде разработки ядра Тарантула. В этой статье я хочу поделиться методикой тестирования менеджера транзакций, которая применяется в Тарантуле.


Читать: https://habr.com/ru/companies/vk/articles/790346/

Spotlight on Two Aussie Start-Ups Building AI Services on MongoDB Atlas



Read: https://www.mongodb.com/blog/post/spotlight-two-aussie-start-ups-building-ai-services-mongodb-atlas

Simplified Data Safe notifications improve data security visibility

We've simplified the process of creating notifications from Data Safe, making it easier for you to create and manage notifications about important events and status changes that impact your database's security posture

Read: https://blogs.oracle.com/database/post/data-safe-notifications

От перфокарт в облако. Где вы хранили файлы десятилетие назад?

В годы моей бурной юности в ходу были пятидюймовые дискеты. Их и вправду можно было назвать “floppy”, то есть, гибкими — футляр из плотного коленкора довольно легко сгибался, пробивался степлером и даже с некоторым усилием сворачивался в трубку. Перфокарты я тоже застал — родители иногда приносили их домой из вычислительного центра, в котором работали, и маленький я рисовал на этих забавных карточках с напечатанными типографским способом рядами цифр (и совой, сова с надписью «КАНГАС» почему-то накрепко засела в памяти) короткими фломастерами от плоттеров-графопостроителей, которые в ассортименте добывались там же, в ВЦ. Сейчас, используя многогигабайтовое облако, смешно вспоминать эту бумажную карточку емкостью 80 байт. Зато можно сказать, что эволюцию носителей информации от перфокарт к облаку я увидел собственными глазами.


Читать: https://habr.com/ru/companies/serverspace/articles/790800/

DocsGPT: Migrating One of the Industry’s Most Popular Open Source AI Assistants to Atlas Vector Search



Read: https://www.mongodb.com/blog/post/migrating-one-industrys-most-popular-open-source-ai-assistants-atlas-vector-search

MongoDB Enterprise Advanced in Google Distributed Cloud Hosted



Read: https://www.mongodb.com/blog/post/mongodb-enterprise-advanced-google-distributed-cloud-hosted

Подводные дата-центры и хранение информации в QR-кодах: новшества индустрии ЦОД

По данным TAdviser, в России зафиксирован небывалый «бум» строительства ЦОДов. Схожая картина наблюдается и в остальных странах: по итогам 2022 года общий объем данных в мире составил 97 зеттабайт, в 2023 году — 110-120 зеттабайт, а к 2025 году — прогноз вплоть до 180-ти. Всю эту информацию нужно где-то обрабатывать и хранить — потребность в дата-центрах растет ежемесячно. По данным «Коммерсанта», спрос на услуги дата-центров в значительной степени превышает предложение. Именно поэтому на сферу направлено сейчас пристальное внимание, а где внимание, там и высокие технологии.


Читать: https://habr.com/ru/companies/sberbank/articles/792072/

Building AI with MongoDB: How Flagler Health's AI-Powered Journey is Revolutionizing Patient Care



Read: https://www.mongodb.com/blog/post/building-ai-mongodb-how-flagler-healths-ai-powered-journey-revolutionizing-patient-care

MariaDB Community Server Q1 2024 maintenance releases

Read: https://mariadb.com/?p=38725

Хранение паролей: работа над ошибками

В предыдущей статье, я описал свой сетап хранения авторотационных данных (паролей). Многие эксперты изучили её и дали свои комментарии, - о том, где могут быть проблемы, о том, что можно упростить, и о том, что можно делать по другому.

Но начнём мы с небольшого объяснения, почему система такая сложная. Вспомним суть:

1) Для логина на "не значимые" сайты (например в аккаунт очередного AI-продукта) мы используем уникальный пароль, который храним в программе хранения паролей (парольном менеджере)

2) Для логина на "более важные ресурсы" (например в аккаунт на github), мы используем уникальный пароль, который храним в парольном менеджере, плюс одноразовый пароль (TOTP - Time-based One-Time Password) который нам покажет специальное приложение на телефоне.

Вот и всё. Это вся суть повседневного использования всей системы. Но почему она тогда казалась такой сложной? Вероятно из-за дополнительных слоёв защиты от самого себя или любых непредвиденных факторов.


Читать: https://habr.com/ru/articles/791914/

Как мы поменяли методику исследования «BI-круг Громова», чтобы результаты стали еще точнее

«Круги Громова» занимается сравнительными исследованиями ИТ-решений. Начинали мы с исследований именно BI-систем (системы бизнес-аналитики, business intelligence) и разбираемся в них, как считаем, весьма хорошо. По задумке наши исследования (кстати, ежегодные) должны быть чем-то вроде карты для ИТ-отделов и руководителей, чтобы помочь им разобраться в дебрях множества современных BI-решений. Одним из основных параметров, влияющих на объективность исследования, является его методика. Поэтому мы постоянно думаем над тем, как сделать нашу методику еще более точной, учитывающей еще больше факторов и позволяющей раскрыть максимум информации о решениях, которые попали к нам под микроскоп.


Читать: https://habr.com/ru/articles/792292/

Announcing MongoDB as a Founding Member of the NIST AI Safety Institute Consortium



Read: https://www.mongodb.com/blog/post/announcing-mongodb-as-founding-member-of-nist-ai-safety-institute-consortium

Maximizing Database High Availability with MariaDB MaxScale

Read: https://mariadb.com/?p=38727

Поисковый движок в 80 строках Python

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

Давайте поговорим о целях. Слышали когда-нибудь о «кризисе сложности обнаружения маленьких веб-сайтов»? Проблема в том. что маленькие веб-сайты наподобие моего невозможно найти при помощи Google или любого другого поискового движка. Какова же моя миссия? Сделать эти крошечные веб-сайты снова великими. Я верю в возвращение славы этих малышей вдали от SEO-безумия Google.

В этом посте я подробно расскажу о процессе создания поискового движка с нуля на Python. Как обычно, весь написанный мной код можно найти в моём GitHub (репозиторий microsearch). Эта реализация не будет притворяться готовым к продакшену поисковым движком, это лишь полезный пример, демонстрирующий внутреннюю работу поискового движка.

Кроме того, мне стоит признаться, что в заголовке поста я слегка преувеличил. Да, поисковый движок действительно реализован примерно в 80 строках Python, но я ещё и писал вспомогательный код (краулер данных, API, HTML-шаблоны и так далее), из-за которого весь проект становится немного больше. Однако я считаю, что интересная часть проекта находится в поисковом движке, который состоит из менее чем 80 строк.

P.S. Написав этот пост и microsearch, я осознал, что пару лет назад нечто похожее написал Барт де Гёде. Моя реализация очень похожа на работу Барта, но я считаю что кое-что улучшил, в частности: (1) мой краулер асинхронный, что сильно ускоряет работу, (2) я реализовал пользовательский интерфейс, позволяющий взаимодействовать с поисковым движком.


Читать: https://habr.com/ru/articles/792452/

Заметка про сохранение структур во flash памяти на STM32

При разработке проекта для микроконтроллера часто возникает необходимость сохранения данных во Flash-память перед выключением устройства. Глобальные структуры содержат информацию о настройках различной периферии, данные с внешних датчиков и прочее. В этом посте я хочу показать простенький механизм записи структуры во FLASH память микроконтроллера STM32, которым я сам часто пользуюсь в своих проектах.


Читать: https://habr.com/ru/articles/791252/

Один из методов мониторинга и анализа ошибок СУБД с помощью Zabbix

Очень неприятная ситуация для DBA: "что-то происходит с СУБД , но что именно - нет информации". Первый и иногда достаточный способ избежать неопределенности - всегда иметь полную информацию о нештатных ситуациях в работе СУБД на текущий период и в истории. Для решения этой в общем то стандартной задачи и нужно мониторить и анализировать лог СУБД. PostgreSQL в данном случае не исключение.

К рассмотрению предлагается один из способов мониторинга ошибок СУБД PostgreSQL и получением итоговой информации , используя Zabbix. Данная статья не tutorial и не roadmap, скорее как эскиз для обмена мнениями с коллегами.

Мониторинг ошибок СУБД

Способ мониторинга СУБД очень простой - постоянный парсинг лога СУБД и оповещение о появлении ошибки .

В основе сервисного скрипта , который выполняется по cron положена очень простая конструкция:

cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА'

Данную конструкцию можно выполнять используя возможности агента Zabbix , но в этом случае есть несколько моментов:

Агент Zabbix должен иметь доступ на чтение к папке лога СУБД

Агент Zabbix имеет ограничения по timeout и в случае повышенной нагрузки на сервер и аварийной ситуации с инфраструктурой могут быть пробелы в мониторинга. А как раз в таких сценариях мониторинг ошибок особенно важен.

Поэтому используется несколько другой способ - агент Zabbix не выполняет парсинг лога СУБД , а всего лишь считывает значение метрики из файлов, которые формируются простым скриптом bash по расписанию cron:

# FATAL | ВАЖНО cat $log_file | grep -E 'FATAL|ВАЖНО' | wc -l > /tmp/fatal.count PANIC | ПАНИКА

cat $log_file | grep -E 'PANIC|ПАНИКА' | wc -l > /tmp/panic.count

PANIC | ПАНИКА

cat $log_file | grep -E 'PANIC|ПАНИКА' | wc -l > /tmp/panic.count

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

Для более углубленного анализа , для некоторых кодов ошибок можно и нужно сформировать отдельные файлы:

#Класс 53 — Нехватка ресурсов #53300| ВАЖНО: извините, уже слишком много клиентов - исключить дублирование метрики Zabbix cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' | grep -E ' 53000|| 53100|| 53200|| 53400|| 53500|' | wc -l > /tmp/error53.count Класс 58 — Ошибка системы (ошибка, внешняя по отношению к PostgreSQL)

cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' | grep -E ' 58000|| 58030|| 58P01|| 58P02|' | wc -l > /tmp/error58.count

Класс XX — Внутренняя ошибка

cat $log_file | grep -E 'FATAL|ВАЖНО|PANIC|ПАНИКА|ERROR|ОШИБКА' | grep -E ' XX000|| XX001|| XX002|' | wc -l > /tmp/errorXX.count

Для оперативного реагирования на ошибки - можно настроить стандартное оповещение Zabbix.

Метрики Zabbix

В результате добавления метрик Zabbix получается вполне доступная для оперативного и исторического анализа картина:

Анализ ошибок

Для получения более углублённого анализа и создания сводного отчета по оши
...

Читать: https://habr.com/ru/articles/792890/

Один из методов мониторинга и анализа ошибок СУБД

Очень неприятная ситуация для DBA: «что-то происходит с СУБД, но что именно — нет информации». Первый и иногда достаточный способ избежать неопределенности — всегда иметь полную информацию о нештатных ситуациях в работе СУБД на текущий период и в истории. Для решения этой в общем то стандартной задачи и нужно мониторить и анализировать лог СУБД. PostgreSQL в данном случае не исключение.

К рассмотрению предлагается один из способов мониторинга ошибок СУБД PostgreSQL и получением итоговой информации, используя Zabbix. Данная статья не tutorial и не roadmap, скорее как эскиз для обмена мнениями с коллегами.



Читать: https://habr.com/ru/articles/792912/

Кратко про NewSQL

NewSQL - это класс систем управления реляционными БД, представляет собой слияние преимуществ SQL-бд с инновациями, направленными на решение проблем масштабируемости и производительности.

В основе NewSQL лежит стремление сохранить полную совместимость с SQL, т.е разработчики, уже знакомые с SQL, могут легко адаптироваться к использованию NewSQL систем без необходимости изучения чего-либо другого.

Помимо базового SQL синтаксиса, многие NewSQL системы вводят дополнительные расширения, направленные на улучшение производительности Эти расширения могут включать в себя новые функции, процедуры и методы оптимизации запросов, которые традиционные SQL-системы не поддерживают.

В сегодяшней статье рассмотрим в общем виде то, что из себя представляет NewSQL


Читать: https://habr.com/ru/companies/otus/articles/792722/