СУБД Postgres Pro – сложный механизм, который можно гибко настраивать под конкретный тип нагрузки. Для этого в нём имеется множество параметров и инструментов. Например, одним из главных потребителей ресурсов CPU является оптимизатор/планировщик запросов, который отвечает за построение оптимального плана выполнения. Существует большое количество параметров, которые прямо или косвенно влияют на работу планировщика, но к их изменению надо подходить очень осторожно, т. к. возможен обратный эффект. Например, параметры _collapse_limit могут и помочь оптимизатору рассмотреть большее количество вариантов планов, и негативно повлиять на время планирования.

Сегодня я расскажу, как мы решали реальную проблему производительности и высокой (> 90%) утилизации ресурсов CPU на промышленном «боевом» сервере с СУБД Postgres Pro Enterprise 15, обслуживающем запросы бизнес-приложения, какие для этого использовали инструменты и что мы изменили в настройках СУБД.

X11 это тот механизм на чем работает весь графический интерфейс Unix подобных ОС.

Но мало кто знает как он работает на самом деле. Потому что с годами он оброс слоями и слоями библиотек, которые стремятся скрыть саму сущность протокола.

А протокол в своей сути прекрасен. Он лаконичен и почти совершенен.

В Интернете есть полная документация по протоколу. Но дело в том, что эта документация большая, написана не совсем ясным языком и, по сути, является просто спецификацией. Важные моменты никак не обозначены, а как использовать – тоже оставлено на фантазию читателя.

А все книги и статьи по использованию X11 описывают это через библиотеки прокладки типа XLib и XCB, и даже, что хуже, GTK или Qt.

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

Как бы то ни было, если кому-то интересно как все работает на самом деле, пожалуйста под кат.

Что такое балансировка нагрузки?

• Балансировщик нагрузки приложений.
• Сетевой балансировщик нагрузки.
• Балансировщик нагрузки шлюза.
• Классический балансировщик нагрузки.

В России не любят Линукс. Студенты и корпорации всячески отлынивают его использовать, даже если Линукс насаждают преподаватели или госзаказчики. Но есть область, в которой Линукс придется полюбить. Это разработка микросхем. Даже внутри Apple и Microsoft инженеры используют Synopsys Design Compiler / IC Compiler и Cadence Genus / Innovus, у которых вообще нет версий для Windows и MacOS, только для Linux. Да, я знаю, что Synopsys и Cadence ушли из России. Но даже открытые тулы для синтеза ASIC - Open Lane - есть только под Linux.

Я уже несколько лет использую для семинаров по FPGA загружаемые через USB SSD диски, на который ставится весь необходимый софтвер. Такое решение позволяет избежать агонии первого дня семинара, когда приходит куча народу со своими ноутбуками, три часа ставят Quartus, а потом мучаются с драйверами USB Blaster для китайского контрафактного клона, который без танцев с бубном не хотят поддерживать не Win10, ни Linux, ни особенно Win11, который хочет подписанные драйверы.

А как же виртуальные машины? - спросите вы. С моей точки зрения они вносят дополнительный уровень танцев с бубном. И это не мое дремучее мнение - так же считает мой приятель, который работал над виртуализацией в Микрософте. То оно USB порт не пробивает, то еще какие-нибудь глюки. Плюс учить дополнительные опции, качать и копировать файлы в десятки гигабайт. А тут вставил в USB порт, и если загрузится, то заработает.

Конечно, загружаемые SSD тоже не без проблем: тут и Legacy BIOS boot против UEFI boot, и Secure Boot с Bit Locker, и зловещий "хвост GPT", и отрубание всего из-за скачка напряжения в USB хабе - но с этими проблемами мы методично разобрались. Решение я и описываю в этой заметке, предназначенной в первую очередь для учеников и руководителей кластеров в Школе Синтеза Цифровых Схем, которая начинается с сентября в 14 российских городах (объявления и точных дат еще нет, но уже записалось 200 учеников).

Прежде всего: как выглядит загружаемый SSD? А вот так:

История началась в 2019 году, когда я работал сервисным инженером по ремонту промышленного оборудования. Как-то раз, во время очередного компонентного ремонта, мне начальник предложил собрать хороший инструмент "из прошлого" для быстрого поиска неисправностей и ремонта печатных плат. По его утверждению, с помощью этого таинственного устройства ремонт происходил в разы быстрее (во времена своей молодости начальник занимался ремонтом персональных компьютеров и периферии). И даже название того оригинального прибора мне было озвучено - Huntron Tracker®.
Изучив подробно новую для себя тему, я принялся к сборке простейшей аналогичной схемы из нескольких деталей (не без скепсиса конечно). Это была приставка к осциллографу.

Данный самодельный прибор может оказаться весьма полезным в радиолюбительской мастерской в некоторых случаях. Прибор позволяет оценить добротность (наличие потерь) конденсаторов и индуктивностей – дросселей и трансформаторов, и, в частности, выявлять наличие короткозамкнутых витков в них.

Откройте любую статью с обзором HTTP/1.1. Скорее всего, там найдётся хотя бы один пример запроса и ответа, допустим, такие:

GET / HTTP/1.1
Host: localhost

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 38
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<h1>Привет!</h1>

Теперь откройте статью с обзором HTTP/2 или HTTP/3. Вы узнаете о мультиплексировании запросов, о сжатии заголовков, о поддержке push-технологий, но вряд ли увидите хоть одно конкретное сообщение. Ясно, почему так: HTTP/1.1 — текстовый протокол, тогда как сиквелы к нему бинарные. Это очевидное изменение открывает дорогу ко множеству оптимизаций, но упраздняет возможность просто и доступно записать сообщения.

Поэтому в этой статье предлагаю покопаться в кишках у HTTP/2: разобрать алгоритмы установки соединения, формат кадров, примеры взаимодействия клиента с сервером.

1. Введенние.
2. Zval.
3. Циклические ссылки.
4. Сборщик мусора.
5. Алгоритм работы сборщика мусора.
6. Смотрим глазами.
7. Слабые ссылки.
8. Бонус-трэк: WeakMap.
9. Заключение.

Point in Time Recovery (PiTR) — это восстановление базы данных на какой‑то конкретный момент времени (с точностью до секунд или до конкретной транзакции).

PiTR невероятно полезен для восстановления базы данных после того, как «случилось непоправимое». Если достаточно точно выбрать точку на которую восстанавливать базу, то можно восстановить базу данных практически без потери данных.

В этой статье мы рассмотрим классический PiTR и еще два способа путешествовать во времени быстрее, и уменьшить количество операций, которые надо выполнять руками.

На Хабре можно найти немало статей, посвящённых оптимизациям поиска кратчайшего пути на графе. Я расскажу ещё про еще один подход. Речь пойдёт о распараллеливании алгоритма A* и исполнении его на двух потоках, а также о сложностях, с которыми я столкнулся при реализации, и их преодолении.

Сегодня я хочу поделиться подборкой open source ханипотов, которые можно использовать для защиты своих серверов и локальных сетей от кибератак. Но для начала давайте разберемся, что такое ханипот и зачем он нужен.

Honeypot — это приманка для хакеров, которая имитирует реальную цель атаки. Он может имитировать любой цифровой актив, например, сервер, приложение, устройство или даже отдельный документ. Такие приманки создаются специально, чтобы привлечь внимание злоумышленников и отвлечь их от настоящих целей.

Это был конец декабря 2021-го года, мы едем через Техас, только что благополучно переночевали в El Paso — низкий тебе поклон Голливуд за прекрасные фильмы, такие как Sicario, после которых у нас тряслись коленки когда мы въезжали в этот прекрасный город. Продолжаем движение по направлению к Boca Chica, посмотреть на StarBase (оно того стоит поверьте). На улице жара +30 и солнечно, приятная летняя погода. В фоне отгоняю от себя мысли о том, что тут творится летом с температурой и людьми.

О чем можно думать в этот момент кроме как о космосе, о будущем и о распределенных системах? Конечно много о чем, а не этой гиковской фигне:) ...

Привет, хабр! Уже более 5 лет занимаюсь разработкой и моделированием радиолокационных систем, в частности «больших» локаторов дециметровой длины. В своей практике сталкивался с тем, что при разработке такой сложной системы, как локационная, в основном делают упор на моделировании функциональной части, например, блоков фильтрации, типа зондирующего сигнала, алгоритмов компенсации задержек, а иногда и учет нелинейных эффектов, в частности в аналоговом усилительном тракте.

Как‑то раз, разрабатывая модель функциональных блоков и ячеек локатора в матлабе и симулинке (для моих нужд и целей этого аппарата хватало вполне), задумался о том, что живой локатор так не работает, он состоит из множества дополнительных систем, которые в совокупности и формируют его истинный облик. Проведя небольшие исследования, а также на личном опыте столкнулся с тем, что мало кто из разрабов моделит САУ, а уж совместно с функциональной частью и подавно. Еще меньше моделят учет и потери пакетов при сетевом трафике, а это частая проблема у «больших» локаторов со множеством приемо‑передающих ячеек и блоков.

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

Итак, поехали..