Знаю многих здесь задолбали всякие ИИ, но кому интересно, то запустил новую модель на своем сайте Фотомагия для создания из фото анимешек с сохранением всех деталей исходной композиции. Думаю, будет интересно использовать на аватарках в соцсетях или как-то иначе. Под это выделил отдельный сервер (не очень мощный конечно, но думаю справится).
Ну и, как и ранее, все бесплатно для всех.
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
Seq Scan: Неожиданный чемпион высоких нагрузок.
Cчитается, что индексы — это панацея для производительности СУБД, своего рода «волшебная таблетка» для ускорения запросов. Но что, если под давлением конкуренции и стремительно растущей нагрузки классические подходы дают сбой?
В этой статье показаны результаты нагрузочного тестирования PostgreSQL в условиях нагрузочного тестирования, которые привели к парадоксальному на первый взгляд выводу. Когда количество одновременных операций растет, а данные активно читаются, дорогостоящие индексы могут не справиться, превратившись из помощников во вредителей. И как оказалось, старый добрый Seq Scan — метод полного сканирования таблицы — неожиданно стал в итоге самым эффективным решением в этом сценарии.
CREATE TABLE pgbench_test
(
aid integer PRIMARY KEY ,
bid integer,
abalance integer,
filler character(84)
);
ALTER TABLE pgbench_test ADD CONSTRAINT "pgbench_test_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid);
INSERT INTO pgbench_test ( aid , bid , abalance , filler )
SELECT
id ,
floor(random() * 685 ) + 1 ,
floor(random() * (68500000 - 1 + 1)) + 1 ,
md5(random()::text)
FROM generate_series(1,1000000) id;
select test.abalance
from pgbench_accounts acc
join pgbench_test test on (test.bid = acc.bid )
where acc.aid = current_aid ;
Стоимость плана = 21620.62
Gather (cost=1002.80..21620.62 rows=1460 width=4) (actual time=4.088..329.017 rows=1468 loops=1)
Workers Planned: 3
Workers Launched: 3
-> Hash Join (cost=2.80..20474.62 rows=471 width=4) (actual time=1.821..300.589 rows=367 loops=4)
-> Parallel Seq Scan on pgbench_test test (cost=0.00..19619.81 rows=322581 width=8) (actual time=0.692..263.390 rows=250000 loops=4)
-> Hash (cost=2.79..2.79 rows=1 width=4) (actual time=0.488..0.489 rows=1 loops=4)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.472..0.474 rows=1 loops=4)
Index Cond: (aid = 51440641)
Planning Time: 1.977 ms
Execution Time: 329.301 ms
CREATE INDEX pgbench_test_idx ON pgbench_test ( bid );
Стоимость плана = 1546.55
Nested Loop (cost=14.51..1546.55 rows=1460 width=4) (actual time=0.894..366.050 rows=1468 loops=1)
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.217..0.227 rows=1 loops=1)
Index Cond: (aid = 51440641)
-> Bitmap Heap Scan on pgbench_test test (cost=13.94..1529.17 rows=1460 width=8) (actual time=0.669..365.312 rows=1468 loops=1)
Recheck Cond: (bid = acc.bid)
Heap Blocks: exact=1407
-> Bitmap Index Scan on pgbench_test_idx (cost=0.00..13.57 rows=1460 width=0) (actual time=0.355..0.356 rows=1468 loops=1)
Index Cond: (bid = acc.bid)
Planning Time: 2.634 ms
Execution Time: 366.419 ms
CREATE INDEX idx_pgbench_test_bid_abalance ON pgbench_test(bid) INCLUDE (abalance);
Стоимость плана = 48.86
Nested Loop (cost=0.99..48.86 rows=1460 width=4) (actual time=0.771..1.186 rows=1432 loops=1)
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.736..0.737 rows=1 loops=1)
Index Cond: (aid = 51440641)
-> Index Only Scan using idx_pgbench_test_bid_abalance on pgbench_test test (cost=0.42..31.47 rows=1460 width=8) (actual time=0.029..0.289 rows=1432 loops=1)
Index Cond: (bid = acc.bid)
Heap Fetches: 0
Planning Time: 4.949 ms
Execution Time: 1.302 ms
Сравнительный график операционной скорости в ходе нагрузочного тестирования
До 8-ми соединений - наибольшая производительность получена с использованием метода доступа Bitmap Index Scan.
После 8-ми соединений и до 22-х - наибольшая производительность получена с использованием метода доступа Seq Scan.
Без индекса: Sequential Scan читает данные большими последовательными блоками
С индексом: Index Scans создают случайный доступ к диску
Индекс занимает место в shared_buffers
Вытесняет полезные данные из кэша
Каждое соединение читает разные части индекса → больше промахов кэш
При использовании индекса PostgreSQL обращается к системным каталогам
Увеличивается конкуренция за pg_index, pg_class
Особенно заметно при многих одновременных соединениях
Обработка индекса требует больше CPU операций
Bitmap Index Scan + Bitmap Heap Scan сложнее чем простой Seq Scan
При росте соединений CPU становится узким местом
Компания Rapoo наделала много шума в 2025 году, ворвавшись на российский рынок и представив множество моделей. Одной из них является механическая клавиатура V520, под кодовым названием которой даже я насчитал более 5 модификаций. Почему производитель не разделяет их дополнительным обозначением, мне непонятно. И, кажется, этого было мало, у меня на руках версия Rapoo V520 — очередная модель с серебристыми свитчами.
Упаковка фирменна в черно-бирюзовом цвете. Она достаточно большая, чтобы поместиться в рюкзак от ноутбука. На лицевой стороне коробки изображение модели и четыре крупных символа — V520.
На обратной стороне нас ожидает перечень главных особенностей. И местами плохой перевод, который стал часто достигаться с помощью чата GPT, но с ошибками. Поэтому внутри нас ждет «бесконфликтный дизайн клавиш», хотя, может, имеется в виду, что колпачки не цепляются друг за друга.
Rapoo V520 — это полноразмерная механическая клавиатура серого цвета с черными кейкапами с количеством клавиш 104 и базовой раскладкой ANSI. Лазерной гравировкой нанесены символы и русская раскладка. Выбран не самый удачный шрифт, поэтому надписи порой сливаются в одно целое.
Серия клавиатур Rapoo достаточно обширная, даже в рамках одной линейки: версий V520 в интернете можно найти несколько, отличающихся как по дизайну, так и типом переключателей.
Размеры данной модели 437 х 38 х 136 мм.
Механическая клавиатура Rapoo V520 построена на кликающих переключателях Rapoo Silver. Информации о них мало, даже на официальном сайте: 50 млн нажатий и сила нажатия ~50 г. Но по ощущениям, что всего 40 г. Печатать текст приятно, но характерный звук присутствует, и он нравится одной части аудитории, другие предпочитают менее громкие свичи.
Колпачки из ABS-пластика с двойным литьем, здесь придраться сложно.
Модель оснащена RGB-подсветкой ограниченного типа. Что это значит? Шесть рядов переключателей исключительно со своим цветом и оттенком. Можно регулировать режимы, скорость и яркость. А вот если самый верхний ряд — красный, то он останется им навсегда. Кому-то может понравиться.
Множество режимов описано в инструкции, выбираются они комбинацией Fn + PrtSc, а комбинацией Fn + Scroll Lock можно задавать подсветку определенных зон.
Нашел даже геймерский с WASD и стрелочками: привет шутерам и гонкам. Можно выбрать, где светится только левая часть или крайние кнопки. Иногда задумываюсь, как разработчики выбирают и утверждают подобные вариации.
Подсветка клавиатуры приятная и яркая, и настраивается, можно активировать готовые пресеты. Но, как по мне, не хватает именно разных цветов: шесть разных рядов с одинаковым свечением имеется у некоторых моделей на рынке, но выглядит простовато.
Корпус Rapoo V520 выполнен из ABS-пластика, но верхняя металлическая панель придает солидности продукту. Также она защищает от пыли и пролитой жидкости, если вы любите покушать за клавиатурой. Сбоку находятся полуматовые вставки для той же подсветки.
Механическая клавиатура тяжелая, примерно 850 г, но от скольжения это бы ее не уберегло. Поэтому на основании находятся четыре прорезиненные ножки.
По краям находятся складные ножки. Они увеличивают высоту корпуса на 12 мм. У них всего два положения.
Клавиатура Rapoo V520 получила проводное подключение по USB. Драйвера не требуются, системой Windows определяется мгновенно. Кабель в резиновой изоляции стандартной длины 1.7 метра.
В заключении хочется сказать, что перед нами хорошая механическая клавиатура со своим стилем и дизайном. Модель Rapoo V520 выделяется свичами Rapoo Silver и металлической пластиной. Она сочетает необычный внешний вид и тактильное удовольствие от работы за ней, конечно же, если вы сторонник подобных периферий. Однако у нее много конкурентов, что затрудняет выбор.
Однако основная ставка в Rapoo V520 делается именно на качественное исполнение и подобный тип конструкции. Я поискал что можно найти сейчас в магазинах: можно увидеть механические клавиатуры и за 850 рублей, но правда я боюсь представить что там внутри и как долго она прослужит. Подобные модели как Rapoo V520 по стоимости начинаются от 3500 рублей, например, Oklick 970G DARK KNIGHT, но там стоят другие переключатели, да и реализация корпуса попроще, поэтому модель из обзора имеет право на жизнь.
Наигравшись с кицунэ и лисами, решил попробовать нано банана про в генерации более сложных видов фуррей. Взял для начала протогенов и сергалов.
Протогены вышли прям отлично, даже без картинки-референса на строение протогена. Только через описание задумки моего персонажа, и через описание кодов цветов для цветовой палитры.
Почему-то сгенерил первый раз в трёх количествах. И да, его зовут Архивариус, ещё один мой персонаж, изучает Землю. Антеннки таки задуманы, если что - с их помощью он собирает инфу с аналоговых волн. Не знаю, зачем вам эта информация)
После, я решил чуть допилить - изначально я его задумывал с четырьмя ушами. Да и броню решил перекрасить, чтобы не возникало ощущения, что он голенький. Тут уже понадобился референс. Но получилось годно как по мне.
Вот это уже лучше, но зачем-то банана перекрасила ему и уши. И антеннок нет. И ещё - рот раскрыт, но этого не видно, создаётся ощущение что это просто подсветка, а язык высунут через визор. Непорядок,
Тогда я, подумав ещё, написал правки, чтобы это исправить. Но подумав позже, решил исправить ещё кое-что - фон.
Да, это его комната. Коллекционирование накопителей информации - его хобби.
И вот этот вариант мне понравился больше всего. А ещё, на этом этапе, я понял, что иногда стоит менять чаты в банане, иначе начинает слетать стиль (например, тут форма визора стала более округлой.
Ну и бонусом - самодиагностика. И снова пример того, почему стоит иногда менять чаты - визор стал ещё круглее.
Потом я решил - а если попробую сгенерировать Сергала, то может и с ним бананчик справится? И, закинув на всякий пожарный референсы из офицального гайдбука про то, как рисовать сергалов (на строение тела, на выражение мордочки и на... челюсти. Да. Чтобы правильно сгенерился рот). попробовал - и...
Лучше, чем ГПТ или Леонардо, но есть куча косяков - хвост без кисточки, зубов многовато, руки более человеческие. Может ещё что-то
Итог - протогенов Нано банана знает и генерит хорошо (если сравнивать с другими), даже все панельки на броне прорисовывает. Сергалов - нормально (опять же, сравнивая с другими нейронками), но с косяками. Хотя как мне кажется, если поиграться ещё с этим нейроартом в той же нанобанане, может и получится всё исправить.
Ну, вот так как то
Идея для персонажа протогена моя, как и его лор (могу кому-то скинуть, если интересно), так что считаю тег "Моё" уместным.
Китайский производитель бытовой техники Midea представил Miro U — первого в мире человекоподобного робота с шестью руками и колёсами вместо ног.
Miro U позиционируется как «супергуманоид», под которым понимается робот, похожий на человека, но способный выполнять задачи сверх человеческих возможностей.
Некоторые особенности Miro U:
Способность выполнять три задачи параллельно (по одной на каждую пару рук).
Вращение на 360 градусов. Это делает робота более эффективным в транспортировке и сортировке грузов на фабриках.
Нижнюю пару рук Miro U может использовать для подъёма тяжестей — верхние параллельно с этим будут выполнять более «тонкие» сборочные задачи.
До конца декабря 2025 года Midea запустит массовое производство шестируких роботов. Компания начнёт применять Miro U на нескольких предприятиях Midea Group, где собираются стиральные машины.
В Midea ожидают, что робот повысит эффективность производства примерно на треть.
Для этого они создали систему, которая может проникать через лобную кость и воздействовать на области мозга, отвечающие за запахи.
Метод называется сфокусированная ультразвуковая стимуляция.
Принцип:
Через специальную гарнитуру ультразвук направляют в определённые участки мозга, связанные с обонянием.
Особенности метода:
Ультразвук не наносит вреда тканям;
стимуляция точечная — аппарат активирует строго нужные участки;
Интенсивность легко регулируется.
Искусственно активируя нейроны, технология «обманывает» мозг, заставляя его воспринимать несуществующий аромат.
В результате испытуемые ощущали запахи свежего воздуха, костра, озона и даже мусора, несмотря на то, что ничего из этого физически рядом не было.
Если технологию доведут до массового применения, она может изменить игры, кино, VR и даже медицину. Например, можно будет включать ароматы в виртуальной реальности, фильмах, играх, просто нажатием кнопки.
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
Определи цель, заряди параметры, устрани проблему
Предисловие:
Когда производительность СУБД падает под нагрузкой, важно не стрелять наугад. Методика PG_EXPECTO предлагает сначала выявить ключевые цели — проблемные запросы и типы ожиданий — и только затем наносить точный удар, используя «большие пушки» оптимизации.
Проанализируй данные по типам ожидания в ходе инцидента производительности СУБД PostgreSQL
BgWorkerShutdown (40,62%) — наиболее проблемное событие:
Указывает на ожидание завершения фоновых процессов
Возможные причины:
Медленное завершение параллельных worker-процессов
Проблемы с освобождением ресурсов
Возможные deadlock-ситуации при завершении
ParallelFinish (25,4%) и ExecuteGather (21,14%):
Связаны с параллельным выполнением запросов
Высокие значения могут указывать на:
Слишком агрессивные настройки параллелизма
Конкуренцию за ресурсы между параллельными worker-ами
Неоптимальные планы выполнения параллельных запросов
BufferMapping (49,46%) — основная проблема в блокировках:
Указывает на конкуренцию за доступ к буферному кешу
Возможные причины:
Недостаточный размер shared_buffers
Высокая конкурентная нагрузка на горячие данные
Отсутствие или неэффективность индексов
SerializableXactHash (31,72%):
Связано с транзакциями уровня изоляции SERIALIZABLE
Может указывать на:
Высокую конкуренцию за структуры данных serializable транзакций
Необходимость оптимизации транзакций
Для IPC-ожиданий:
1.Проверить настройки параллелизма:
max_parallel_workers_per_gather
max_parallel_workers
max_worker_processes
2.Анализировать логи на предмет ошибок воркеров
3.Рассмотреть уменьшение параллелизма для сложных запросов
Для LWLock-ожиданий:
Оптимизировать работу с буферным кешем:
Увеличить shared_buffers (если позволяет RAM)
Проверить эффективность индексов
Рассмотреть использование pg_prewarm для критичных данных
Для Serializable транзакций:
Проверить необходимость использования SERIALIZABLE изоляции
Оптимизировать длительность транзакций
Рассмотреть альтернативные уровни изоляции
Сбор дополнительной информации:
Получить полный список ожиданий за период инцидента
Проверить мониторинг нагрузки на CPU, IO, память
Возможные immediate-действия:
Перераспределить нагрузку по времени
Временно снизить параллелизм
Добавить индексы на часто используемые поля в условиях WHERE/JOIN
Основные проблемы связаны с параллельным выполнением запросов и конкуренцией за буферный кеш. Рекомендуется поэтапная оптимизация настроек параллелизма и работы с памятью.
Проанализируй данные по событиям ожидания для SQL запросов по queryid в ходе инцидента производительности СУБД PostgreSQL
1. Запросы с наибольшим влиянием на IPC-ожидания:
Топ-1 проблемный запрос (17,6% IPC ожиданий):
queryid: -1701015661318396920 3018 вызовов, 85k строк
Ожидания: BgWorkerShutdown, ParallelFinish, BufferIO, ExecuteGather
Анализ: Часто выполняемый параллельный запрос с проблемами завершения воркеров
Топ-2 (14% IPC ожиданий):
queryid: -678327810318891437 5183 вызовов, 5183 строк
Особенность: Каждый вызов возвращает ровно 1 строку
Высокая частота выполнения усиливает проблемы параллелизма
2. Запросы с наибольшим влиянием на LWLock-ожидания:
Топ-1 проблемный запрос (24,73% LWLock ожиданий):
queryid: -8182552260313222074 42,7k вызовов, 8,5M строк
Ожидания: BufferMapping
Анализ: Крайне часто выполняемый запрос с высокой конкуренцией за буферный кеш
Критический запрос, присутствующий в обеих категориях:
queryid: 5459520954633506046:
IPC: 5,34% (параллельное выполнение)
LWLock: 11,83% (ParallelHashJoin)
Особенность: 287 вызовов, но 217k строк на вызов (~759 строк/вызов)
Вероятно: Сложный аналитический запрос с хеш-соединениями
Запросы с ParallelFinish и ExecuteGather:
Все топ-8 IPC запросов имеют эти ожидания
Рекомендация: Уменьшить max_parallel_workers_per_gather для этих queryid
Конкретные кандидаты на оптимизацию:
queryid: 1374759154717555017 2053 вызова, 0 строк
Возможно, DML-операция с неправильным планом
Имеет HashBuildHashInner - проблема с хеш-таблицами
Высокочастотные запросы:
queryid: -8182552260313222074 42k вызовов
Решение: Кэширование на уровне приложения, batch-обработка
Serializable транзакции в db5:
4 из топ-8 LWLock запросов используют SerializableXactHash
Все из базы db5
Рекомендация: Пересмотреть уровень изоляции
Для queryid: -8182552260313222074 (42k вызовов):
-- Добавить индексы на используемые предикаты
-- Внедрить кэширование на 5-10 минут
Для queryid: -1701015661318396920 (частый параллельный запрос):
-- Принудительно отключить параллельное выполнение
SET max_parallel_workers_per_gather = 0;
Группа 1: Частые параллельные запросы
queryid: -678327810318891437 (5k вызовов)
queryid: 3449463017331132112 (3k вызовов)
Действие: Оптимизация планов, уменьшение частоты выполнения
Группа 2: Запросы с хеш-соединениями
queryid: 5459520954633506046
queryid: 1374759154717555017
Действие: Увеличить work_mem, добавить индексы для соединений
Для базы db5 (Serializable транзакции):
Аудит необходимости SERIALIZABLE изоляции
Возможный переход на REPEATABLE READ
Настройка PostgreSQL:
# Увеличить для уменьшения BufferMapping
shared_buffers
# Оптимизация параллельных запросов
max_parallel_workers_per_gather = 2 (вместо 4-8)
parallel_setup_cost = 1000
parallel_tuple_cost = 0.1
# Увеличение для хеш-соединений
work_mem = 32MB (или больше)
Неделя 1: Оптимизация двух самых проблемных запросов
queryid: -8182552260313222074 (кэширование)
queryid: -1701015661318396920 (отключение параллелизма)
Неделя 2: Анализ и оптимизация запросов с хеш-соединениями
Добавление индексов
Пересмотр логики запросов
Неделя 3: Работа с часто выполняемыми запросами
Батчинг
Оптимизация бизнес-логики
Неделя 4: Пересмотр уровня изоляции в db5
Тестирование производительности при READ COMMITTED/REPEATABLE READ
Все изменения должны тестироваться на staging-окружении с нагрузочным тестированием.
Сформируй сводный отчет по типам ожиданий и событиям ожиданий для проблемных SQL запросов в ходе инцидента производительности СУБД PostgreSQL
В ходе инцидента производительности СУБД PostgreSQL выявлены проблемные SQL-запросы с высокой корреляцией (≥0.7) между типом ожидания и нагрузкой на СУБД. Отчет сформирован на основе анализа событий ожиданий и соответствующих запросов.
Наиболее частые события ожидания:
IPC: BgWorkerShutdown (40,62%)
LWLock: BufferMapping (49,46%)
Наиболее проблемные запросы:
IPC: -1701015661318396920 (17,6% ожиданий)
LWLock: -8182552260313222074 (24,73% ожиданий)
Распределение по БД:
db1 и db5 имеют наибольшее количество проблемных запросов
role1 является общей ролью для всех проблемных запросов
Паттерны ожиданий:
Запросы с высоким числом CALLS часто имеют ожидания типа LWLock
Запросы с большим количеством возвращаемых ROWS склонны к ожиданиям IPC
Сфокусироваться на оптимизации запросов с наибольшим процентом ожиданий
Исследовать причины частых событий BgWorkerShutdown и BufferMapping
Проанализировать работу параллельных операций (ParallelFinish, ExecuteGather)
Проверить настройки, связанные с управлением блокировками и параллельным выполнением
