Как нам улучшить PostgreSQL?
Исходя из предудущих моих постов ответ напрашивается такой - установкой расширений (extension).
Вот так это примерно делается:
CREATE EXTENSION IF NOT EXISTS extension_name
WITH SCHEMA schema_name
VERSION version
CASCADE
Вот так обновление:
ALTER EXTENSION extension_name
UPDATE TO version
И удаление:
DROP EXTENSION IF EXISTS extension_name
CASCADE | RESTRICT
Из важного - расширения тоже имеют транзитивные зависимости, их установка/удаление решается опцией CASCADE.
Проблема несовместимых версий видимо решается установкой совместимых версий)
Расширение ставится в конкретную схему.
Всегда можно сделать условное обновление\удаление - с проверкой на существование.
Что меняют расширения:
1) механизм хранения данных в таблицах (Table Access Method Interface)
2) аналогично для индексов, т.е. новые типы индексов (Index Access Method Interface)
3) новые типы данных
4) новые функции
5) внешние источники данных (Foreign Data Wrapper)
6) SQL синтаксис
И к делу.
Вот что интересного я нашел (orioledb, timescaledb, citus и прочие Foreign Data Wrapper уже описал ранее, исключаем):
1) pg_stat_statements - статистика по времени и ресурсам, затраченным на выполнение запросов (где-то год назад уже писал о нем)
Выборка 10 "тяжелых" запросов по общему времени выполнения:
SELECT query, total_time, calls, rows FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;
2) PostGIS - новые типы данных в столбцах, индексы и функции для работы с геоданными (point, line, polygon)
Создание таблицы со геоданными:
CREATE TABLE spatial_data ( id SERIAL PRIMARY KEY, name VARCHAR, location GEOMETRY(Point, 4326);
Поиск объектов в радиусе 1000 метров от точки с определенными координатами:
SELECT * FROM spatial_data WHERE ST_DWithin(location, ST_GeomFromText('POINT(-73.975972 40.782865)', 4326), 1000);
3) HypoPG - создание гипотетических индексов. Т.е. индекса физически нет, но планировщик запросов думает, что он есть.
Создание гипотетического индекса:
SELECT * FROM hypopg_create_index('CREATE INDEX ON mytable (cardId)');
Проверка, подействовал ли он:
EXPLAIN SELECT * FROM mytable WHERE cardId = 1;
4) jsquery - более лучший поиск в стиле XPath по JSONB столбцам (столбцам, с бинарным оптимизированным хранением json) Детали: https://habr.com/ru/companies/selectel/articles/928922/
Поиск пользователей с именем «Иван» старше 30 лет или тех, у кого есть тег «vip»:
SELECT * FROM users WHERE data @@ '((name = "Иван" AND age > 30) OR tags.# = "vip")';
5) pgvector - работа с векторными типами данных, PostgreSQL как RAG, AI и все такое. Детали: https://habr.com/ru/companies/selectel/articles/920824/
Создание таблицы для хранения векторов:
CREATE TABLE items (
id SERIAL PRIMARY KEY,
title TEXT,
embedding VECTOR(1536)
);
Вставка данных :
INSERT INTO items (title, embedding) VALUES
('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'),
('Neural image processing', '[0.42, 0.18, -0.35]'),
('Sound pattern matching', '[-0.20, 0.70, 0.60]'),
('Document clustering', '[0.09, -0.79, 0.48]');
Нахождение похожих векторов:
SELECT
a.title AS title_a,
b.title AS title_b,
a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;
6) pgcrypto - криптографические функции в PostgreSQL. Детали: https://habr.com/ru/companies/selectel/articles/925848/
Сохранение хэшированного пароля:
INSERT INTO users (username, password_hash) VALUES ('new_user', crypt('highly-secure-password123', gen_salt('bf', 10)));
7) hstore - key-value тип данных. На оф.сайте https://www.postgresql.org/docs/current/hstore.html
Создание таблицы с key-value столбцом для хранения атрибутов книги:
CREATE TABLE books (
id serial PRIMARY KEY,
name varchar,
attributes hstore
);
Вставка:
INSERT INTO books (name, attributes) VALUES (
'Harry Potter and the Philosophers Stone',
'author => "J. K. Rowling", pages => 223, series => "Harry Potter"'
);
и выборка по ключу атрибута:
SELECT name, attributes->'author' as author
FROM books
WHERE attributes->'series' = 'Harry Potter'
To be continued...
#PostgreSQL #db
Исходя из предудущих моих постов ответ напрашивается такой - установкой расширений (extension).
Вот так это примерно делается:
CREATE EXTENSION IF NOT EXISTS extension_name
WITH SCHEMA schema_name
VERSION version
CASCADE
Вот так обновление:
ALTER EXTENSION extension_name
UPDATE TO version
И удаление:
DROP EXTENSION IF EXISTS extension_name
CASCADE | RESTRICT
Из важного - расширения тоже имеют транзитивные зависимости, их установка/удаление решается опцией CASCADE.
Проблема несовместимых версий видимо решается установкой совместимых версий)
Расширение ставится в конкретную схему.
Всегда можно сделать условное обновление\удаление - с проверкой на существование.
Что меняют расширения:
1) механизм хранения данных в таблицах (Table Access Method Interface)
2) аналогично для индексов, т.е. новые типы индексов (Index Access Method Interface)
3) новые типы данных
4) новые функции
5) внешние источники данных (Foreign Data Wrapper)
6) SQL синтаксис
И к делу.
Вот что интересного я нашел (orioledb, timescaledb, citus и прочие Foreign Data Wrapper уже описал ранее, исключаем):
1) pg_stat_statements - статистика по времени и ресурсам, затраченным на выполнение запросов (где-то год назад уже писал о нем)
Выборка 10 "тяжелых" запросов по общему времени выполнения:
SELECT query, total_time, calls, rows FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;
2) PostGIS - новые типы данных в столбцах, индексы и функции для работы с геоданными (point, line, polygon)
Создание таблицы со геоданными:
CREATE TABLE spatial_data ( id SERIAL PRIMARY KEY, name VARCHAR, location GEOMETRY(Point, 4326);
Поиск объектов в радиусе 1000 метров от точки с определенными координатами:
SELECT * FROM spatial_data WHERE ST_DWithin(location, ST_GeomFromText('POINT(-73.975972 40.782865)', 4326), 1000);
3) HypoPG - создание гипотетических индексов. Т.е. индекса физически нет, но планировщик запросов думает, что он есть.
Создание гипотетического индекса:
SELECT * FROM hypopg_create_index('CREATE INDEX ON mytable (cardId)');
Проверка, подействовал ли он:
EXPLAIN SELECT * FROM mytable WHERE cardId = 1;
4) jsquery - более лучший поиск в стиле XPath по JSONB столбцам (столбцам, с бинарным оптимизированным хранением json) Детали: https://habr.com/ru/companies/selectel/articles/928922/
Поиск пользователей с именем «Иван» старше 30 лет или тех, у кого есть тег «vip»:
SELECT * FROM users WHERE data @@ '((name = "Иван" AND age > 30) OR tags.# = "vip")';
5) pgvector - работа с векторными типами данных, PostgreSQL как RAG, AI и все такое. Детали: https://habr.com/ru/companies/selectel/articles/920824/
Создание таблицы для хранения векторов:
CREATE TABLE items (
id SERIAL PRIMARY KEY,
title TEXT,
embedding VECTOR(1536)
);
Вставка данных :
INSERT INTO items (title, embedding) VALUES
('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'),
('Neural image processing', '[0.42, 0.18, -0.35]'),
('Sound pattern matching', '[-0.20, 0.70, 0.60]'),
('Document clustering', '[0.09, -0.79, 0.48]');
Нахождение похожих векторов:
SELECT
a.title AS title_a,
b.title AS title_b,
a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;
6) pgcrypto - криптографические функции в PostgreSQL. Детали: https://habr.com/ru/companies/selectel/articles/925848/
Сохранение хэшированного пароля:
INSERT INTO users (username, password_hash) VALUES ('new_user', crypt('highly-secure-password123', gen_salt('bf', 10)));
7) hstore - key-value тип данных. На оф.сайте https://www.postgresql.org/docs/current/hstore.html
Создание таблицы с key-value столбцом для хранения атрибутов книги:
CREATE TABLE books (
id serial PRIMARY KEY,
name varchar,
attributes hstore
);
Вставка:
INSERT INTO books (name, attributes) VALUES (
'Harry Potter and the Philosophers Stone',
'author => "J. K. Rowling", pages => 223, series => "Harry Potter"'
);
и выборка по ключу атрибута:
SELECT name, attributes->'author' as author
FROM books
WHERE attributes->'series' = 'Harry Potter'
To be continued...
#PostgreSQL #db
Хабр
Расширение jsquery для PostgreSQL — точные и быстрые выборки из JSONB
Привет, Хабр! Это Антон Дятлов, инженер по защите информации в Selectel . В современных базах данных JSON — де-факто стандарт для хранения полуструктурированных сведений. PostgreSQL предлагает два...
👍1
Продолжение поста про расширения PostgreSQL.
Все что не влезло в предыдущий)
8) citext - case-insensitive хранение, а скорее сравнение строк в БД.
Создание таблицы с case-insensitive столбцом и вставка данных:
Поиск без учета регистра:
9) pg_stat_kcache - еще больше статистики по выполнению запросов, в особенности про работу с файловой системой - например, чтение из кэша ОС vs чтение с диска.
Что за данные собираются - можно узнать тут https://github.com/powa-team/pg_stat_kcache
Пример запроса: 5 самых затратных по времени запросов, их частоту выполнения, объемы обращений к диску и оперативной памяти, а также количество переключений контекста ядра ОС.
10) isn - добавляет новые типы данных для проверки разного рода штрих кодов EAN13, UPC, ISBN (books), ISMN (music), and ISSN (serials) на допустимые префиксы. У модуля есть минус - набор допустимых префиксов постоянном меняется, следовательно, надо поддерживать актуальность расширения и может быть гэп по времени по поступлению обновлений.
Создание и вставка данных в таблицу с ISBN столбцом (уникальный номер книги):
11) pg_hint_plan - позволяет "прибить гвоздями" кусок плана выполнения запроса
Тут мы указываем, что надо использовать HashJoin и сразу смотрим реальный план выполнения запроса:
12) pg_cron - что делает - понятно. Можно подумать, что расширение нарушает принцип - никакой логики в БД. Но оно полезно для другого - для служебных задач, например, периодически делать VACUUM:
На цифре 12 пожалуй и остановлюсь.
Что еще важно.
Часть расширений уже входит в поставку.
Какие именно - можно узнать выполнив команду:
Набор может различаться, в официальном дистрибутиве их на данный момент 60, в PostgrePro - 48, Сбер Pangolin - 119.
#postgresql #db #plugins
Все что не влезло в предыдущий)
8) citext - case-insensitive хранение, а скорее сравнение строк в БД.
Создание таблицы с case-insensitive столбцом и вставка данных:
CREATE TABLE users (user_id SERIAL PRIMARY KEY, username CITEXT, email CITEXT);
INSERT INTO users (username, email) VALUES ('Иван Смирнов', 'ivan.smironoff@mail.ru');
Поиск без учета регистра:
SELECT * FROM users WHERE username = 'иван смирнов';
9) pg_stat_kcache - еще больше статистики по выполнению запросов, в особенности про работу с файловой системой - например, чтение из кэша ОС vs чтение с диска.
Что за данные собираются - можно узнать тут https://github.com/powa-team/pg_stat_kcache
Пример запроса: 5 самых затратных по времени запросов, их частоту выполнения, объемы обращений к диску и оперативной памяти, а также количество переключений контекста ядра ОС.
SELECT
round(total_exec_time::numeric, 0) AS time,
calls,
pg_size_pretty(exec_minflts * 4096) AS reclaim, pg_size_pretty(exec_majflts * 4096) AS faults,
pg_size_pretty(exec_reads) AS reads, pg_size_pretty(exec_writes) AS writes,
round(exec_user_time::numeric, 2) AS user_time, round(exec_system_time::numeric, 2) AS sys_time,
exec_nvcsws AS virtual_switches, exec_nivcsws AS involuntary_switches,
LEFT(query, 27) AS query_text
FROM pg_stat_statements s
JOIN pg_stat_kcache() k
USING(userid, dbid, queryid)
ORDER BY total_exec_time DESC
LIMIT 5;
10) isn - добавляет новые типы данных для проверки разного рода штрих кодов EAN13, UPC, ISBN (books), ISMN (music), and ISSN (serials) на допустимые префиксы. У модуля есть минус - набор допустимых префиксов постоянном меняется, следовательно, надо поддерживать актуальность расширения и может быть гэп по времени по поступлению обновлений.
Создание и вставка данных в таблицу с ISBN столбцом (уникальный номер книги):
CREATE TABLE test (id isbn);
INSERT INTO test VALUES('9780393040029');
11) pg_hint_plan - позволяет "прибить гвоздями" кусок плана выполнения запроса
Тут мы указываем, что надо использовать HashJoin и сразу смотрим реальный план выполнения запроса:
/*+ HashJoin(pt st) */
EXPLAIN SELECT * FROM s1.t1 st
JOIN public.t1 pt ON (st.id=pt.id);
12) pg_cron - что делает - понятно. Можно подумать, что расширение нарушает принцип - никакой логики в БД. Но оно полезно для другого - для служебных задач, например, периодически делать VACUUM:
SELECT cron.schedule('59 23 * * *', 'VACUUM');
На цифре 12 пожалуй и остановлюсь.
Что еще важно.
Часть расширений уже входит в поставку.
Какие именно - можно узнать выполнив команду:
SELECT * FROM pg_available_extensions;
Набор может различаться, в официальном дистрибутиве их на данный момент 60, в PostgrePro - 48, Сбер Pangolin - 119.
#postgresql #db #plugins
GitHub
GitHub - powa-team/pg_stat_kcache: Gather statistics about physical disk access and CPU consumption done by backends.
Gather statistics about physical disk access and CPU consumption done by backends. - powa-team/pg_stat_kcache
Астрологи объявили 2025 годом уязвимостей в Tomcat)
По крайней мере у меня складывается такое впечатление.
И похоже не только впечатление.
https://www.cve.org/CVERecord/SearchResults?query=apache+tomcat
24 уязвимости в 2025 году, по сравнению 15 с 2024. И год еще не закончился)
Предположу, что проблема скорее не в том, что Tomcat кривой по архитектуре или дырявый, а это обратная сторона популярности. Все-таки Tomcat - вариант по умолчанию встроенного сервера для Spring Boot приложений. И большинство его не меняют. Больше инсталляций, больше людей, которые их хотят сломать.
Но не Tomcat единым, как говорится.
Есть еще как минимум 4 сервера для JVM приложений:
1) Jetty
2) Undertow
3) Netty
4) Open Liberty
Все они production ready.
Кто может заменить Tomcat для Spring Boot приложений?
И нужно ли менять?
Начнем с того, кто не сможет.
Netty - это не контейнер сервлетов, синхронное взаимодействие Spring Web MVC он просто не поддерживает. Зато это выбор номер один для реактивщины. Как в Spring, так и в конкурирующих фреймворках Quarkus/Micronaut/Vert.x/Helidon.
И очевидно он выдает намного большую производительность и меньшее потребление памяти, по сравнению с Tomcat. Но требует полного переписывания логики на принципах реактивного программирования. А это сложно и требует я бы сказал повышенной квалификации.
Open Liberty - бывший IBM Websphere Liberty Profile, ушедший в open source. Хотя он и совместим со Spring Boot https://openliberty.io/docs/latest/deploy-spring-boot.html, два факта говорят о том, что смысла так делать нет:
1) одна из главных фишек Open Liberty - полная поддержка Java EE/Microprofile. Это точно не про Spring.
2) среди встроенных серверов Spring Boot нет Open Liberty в отличие от остальных четырех кандидатов.
Тоже побыстрее Tomcat, поддерживает модульность (а это необходимое условие при полной поддержке Java EE).
Остаются два кандидата - Jetty и Undertow.
Undertow - полностью JBoss Undertow - тоже бывшая коммерческая разработка, ушедшая в open source. Архитектурно сделана в неблокирующем стиле а-ля Netty, но с поддержкой сервлетов (Spring Web MVC). Что должно положительно сказаться на производительности. Плюс можно плавно мигрировать с кода в классическом стиле к реактивному. Минус по сути один - мало распространена, меньше сообщество. Да, и уязвимостей мало https://www.cve.org/CVERecord/SearchResults?query=undertow
И наконец Jetty. Архитектура классическая, как и у Tomcat. Разработчики делают фокус на модульной структуре: даже поддержка http (обычного, HTTP v1) обеспечивается модулем и может быть отключена. Кому интересно - вот список модулей из стандартной поставки: https://jetty.org/docs/jetty/12.1/operations-guide/modules/standard.html
Сообщество поменьше, чем у Tomcat, но достаточно большое, учитывая 20 лет на рынке. Уязвимостей сильно меньше в этом году https://www.cve.org/CVERecord/SearchResults?query=Jetty, при сравнимом количестве в 2024.
Вывод: а надо ли куда-то переходить? Для Spring Web MVC приложения большой разницы в производительности, потреблении памяти и надежности на ПРОМ я не ожидаю. Как я говорил - все сервера production ready. Но в плане уязвимостей - возможно, с Jetty жизнь станет немного спокойнее. Не ложное ли это успокоение - может "хакеры" еще не добрались до Jetty? Время покажет, но учитывая 20 лет на рынке ... очень может быть, что и нет, не ложное.
P.S. Интересно, что и IBM, и Redhat (JBoss)) пошли одним путем - выделить ядро своего сервера в отдельный lite компонент и сделать его open source.
#java #web #servlet
По крайней мере у меня складывается такое впечатление.
И похоже не только впечатление.
https://www.cve.org/CVERecord/SearchResults?query=apache+tomcat
24 уязвимости в 2025 году, по сравнению 15 с 2024. И год еще не закончился)
Предположу, что проблема скорее не в том, что Tomcat кривой по архитектуре или дырявый, а это обратная сторона популярности. Все-таки Tomcat - вариант по умолчанию встроенного сервера для Spring Boot приложений. И большинство его не меняют. Больше инсталляций, больше людей, которые их хотят сломать.
Но не Tomcat единым, как говорится.
Есть еще как минимум 4 сервера для JVM приложений:
1) Jetty
2) Undertow
3) Netty
4) Open Liberty
Все они production ready.
Кто может заменить Tomcat для Spring Boot приложений?
И нужно ли менять?
Начнем с того, кто не сможет.
Netty - это не контейнер сервлетов, синхронное взаимодействие Spring Web MVC он просто не поддерживает. Зато это выбор номер один для реактивщины. Как в Spring, так и в конкурирующих фреймворках Quarkus/Micronaut/Vert.x/Helidon.
И очевидно он выдает намного большую производительность и меньшее потребление памяти, по сравнению с Tomcat. Но требует полного переписывания логики на принципах реактивного программирования. А это сложно и требует я бы сказал повышенной квалификации.
Open Liberty - бывший IBM Websphere Liberty Profile, ушедший в open source. Хотя он и совместим со Spring Boot https://openliberty.io/docs/latest/deploy-spring-boot.html, два факта говорят о том, что смысла так делать нет:
1) одна из главных фишек Open Liberty - полная поддержка Java EE/Microprofile. Это точно не про Spring.
2) среди встроенных серверов Spring Boot нет Open Liberty в отличие от остальных четырех кандидатов.
Тоже побыстрее Tomcat, поддерживает модульность (а это необходимое условие при полной поддержке Java EE).
Остаются два кандидата - Jetty и Undertow.
Undertow - полностью JBoss Undertow - тоже бывшая коммерческая разработка, ушедшая в open source. Архитектурно сделана в неблокирующем стиле а-ля Netty, но с поддержкой сервлетов (Spring Web MVC). Что должно положительно сказаться на производительности. Плюс можно плавно мигрировать с кода в классическом стиле к реактивному. Минус по сути один - мало распространена, меньше сообщество. Да, и уязвимостей мало https://www.cve.org/CVERecord/SearchResults?query=undertow
И наконец Jetty. Архитектура классическая, как и у Tomcat. Разработчики делают фокус на модульной структуре: даже поддержка http (обычного, HTTP v1) обеспечивается модулем и может быть отключена. Кому интересно - вот список модулей из стандартной поставки: https://jetty.org/docs/jetty/12.1/operations-guide/modules/standard.html
Сообщество поменьше, чем у Tomcat, но достаточно большое, учитывая 20 лет на рынке. Уязвимостей сильно меньше в этом году https://www.cve.org/CVERecord/SearchResults?query=Jetty, при сравнимом количестве в 2024.
Вывод: а надо ли куда-то переходить? Для Spring Web MVC приложения большой разницы в производительности, потреблении памяти и надежности на ПРОМ я не ожидаю. Как я говорил - все сервера production ready. Но в плане уязвимостей - возможно, с Jetty жизнь станет немного спокойнее. Не ложное ли это успокоение - может "хакеры" еще не добрались до Jetty? Время покажет, но учитывая 20 лет на рынке ... очень может быть, что и нет, не ложное.
P.S. Интересно, что и IBM, и Redhat (JBoss)) пошли одним путем - выделить ядро своего сервера в отдельный lite компонент и сделать его open source.
#java #web #servlet
openliberty.io
Open Liberty Docs
You can enable Open Liberty to support a Spring Boot application. Open Liberty can also configure Spring Boot application arguments and properties and can also thin Spring Boot applications to use resources efficiently.
Если LLM не понимает твой код (процесс)...
В продолжение поста про мысль о том, что код, который не понимает LLM - плохой код.
Пишу сейчас агента, постоянно сталкиваются с скажем так ... не очень хорошей и совсем не стабильной работой LLM.
Начиная с какого-то уровня сложности промта LLM глючит - игнорирует прямые указания, выполняет лишние действия.
Первая мысль - ну тупая...)
Вторая - а может использовать LLM как своеобразный критерий качества аналитики и\или бизнес-процесса?
Если LLM глючит - аналитика не логичная, а процесс - кривой?
Причем и объяснение такому поведению модели есть. Если у нас сложный процесс, то у него большое значение цикломатической сложности - возможных путей выполнения программы. Это аналогия с кодом, т.к. в системном промте мы, пусть и более декларативно, тоже по сути пишем код. А работа LLM - это вероятностный процесс, т.е. на каждой развилке есть вероятность, что процесс пойдет не туда. Плюс код анализируется и выполняется последовательно, а промт - единовременно, и любой кусок пользовательского или системного промта может повлиять на план выполнения агента. И что в итоге мы получим ...?)
P.S. Вопрос конечно провокационный, но справедливости ради в попытках заставить LLM отвечать корректно я нашел ряд логических противоречий в промте. И перешел от 3 агентов к одному, т.к. в рамках одного проще поддерживать непротиворечивость промта.
P.P.S. Все же русский язык совсем не идеален для описания бизнес-логики.
..P.S. Как со всем этим делать мультиагентную систему, где логика пишется разными людьми и выполняется разными агентами - вопрос.
#llm #ai
В продолжение поста про мысль о том, что код, который не понимает LLM - плохой код.
Пишу сейчас агента, постоянно сталкиваются с скажем так ... не очень хорошей и совсем не стабильной работой LLM.
Начиная с какого-то уровня сложности промта LLM глючит - игнорирует прямые указания, выполняет лишние действия.
Первая мысль - ну тупая...)
Вторая - а может использовать LLM как своеобразный критерий качества аналитики и\или бизнес-процесса?
Если LLM глючит - аналитика не логичная, а процесс - кривой?
Причем и объяснение такому поведению модели есть. Если у нас сложный процесс, то у него большое значение цикломатической сложности - возможных путей выполнения программы. Это аналогия с кодом, т.к. в системном промте мы, пусть и более декларативно, тоже по сути пишем код. А работа LLM - это вероятностный процесс, т.е. на каждой развилке есть вероятность, что процесс пойдет не туда. Плюс код анализируется и выполняется последовательно, а промт - единовременно, и любой кусок пользовательского или системного промта может повлиять на план выполнения агента. И что в итоге мы получим ...?)
P.S. Вопрос конечно провокационный, но справедливости ради в попытках заставить LLM отвечать корректно я нашел ряд логических противоречий в промте. И перешел от 3 агентов к одному, т.к. в рамках одного проще поддерживать непротиворечивость промта.
P.P.S. Все же русский язык совсем не идеален для описания бизнес-логики.
..P.S. Как со всем этим делать мультиагентную систему, где логика пишется разными людьми и выполняется разными агентами - вопрос.
#llm #ai
Новости AI
1) появился инструмент сравнения разных LLM моделей - один забра запрос передаётся в 2 разные модели, скорость и качество ответа можно сравнить глазами. https://lmarena.ai/ Что интересно - доступны коммерческие LLM без регистрации и СМС, в смысле без VPN и оплаты
2) сейчас у большинства AI чатов появляется режим Research. Это ризонинг + поиск в интернете + какой-то набор tool для обработки полученных данных. Ещё из важного: составляется план исследования и дозапрашиваются непроходимые данные у пользователя. По сути это AI агент, заточенный под исследования.
Недавно тестировал такой режим у Mistral.
На мою просьбу сравнить скорость сборки Docker образов, модель не просто поискала в интернете тесты, а вначале уточнила сложность образа и возможность включить кэширование(!), после чего сделала вот такой план выполнения запроса:
1) создать docker файлы с нужным настройками
2) сформировать команду для измерения времени сборки для всех видов сборки
3) запустить команду n раз, посчитать среднее
В ответе кроме плана и таблицы с результатами (среднее, max, min), была конфигурация тестового сервера (!!!), описание плюсов и минусов всех инструментов сборки и рекомендации по их использованию.
Думаю - вот до чего техника дошла. И LLM модель, и поиск в вебе, и ещё виртуалку для выполнения задачи подняли. Реально - AI джун. И все бесплатно.
Но червячок сомнения точит... Спросил у модели - а ты реально виртуалку подняла для теста? Нет, говорит, не умею я такого. А откуда цифры тогда, дай источник? Нет источника, синтезировала цифры. Вот тебе ссылки, ищи там, результаты неточные (((
Вывод:
а) LLM модели врут
б) очень хотелось бы иметь такого джуна.
Из хорошего - инструмент доступен без VPN и есть бесплатные попытки. Полезен, если для выполнения задачи достаточно поиска. Ещё может с планом исследования помочь. Что интересно: неделю назад было 10 попыток в месяц, сейчас стало 5, кроме того появилось разделение по скорости - одна попытка быстрая, 4 - медленные. Экономика должна быть экономной)
3) OpenRouter - веб-сервис, являющийсф прокси-адаптером к куче LLM моделей с ChatGPT API. Область применения:
а) запуск кода, написанного для OpenAPI, на других моделях
б) динамический выбор модели в зависимости от задачи/цены без необходимости хранить кучу разных credentials у себя
в) отказоустойчивость.
Из хорошего - много моделей и небольшая наценка.
Из плохого - недавно закрыли доступ из России.
Из интересного - вот тут можно глянуть рейтинг моделей, используемых для разработки https://openrouter.ai/rankings?category=programming#categories
Ясно, что он искажён в части доли ChatGPT. Т.к. если тебя полностью устраивает ChatGPT, то ты не будешь использовать прокси. Но все же интересно)
#ai #llm #ai_agents
1) появился инструмент сравнения разных LLM моделей - один забра запрос передаётся в 2 разные модели, скорость и качество ответа можно сравнить глазами. https://lmarena.ai/ Что интересно - доступны коммерческие LLM без регистрации и СМС, в смысле без VPN и оплаты
2) сейчас у большинства AI чатов появляется режим Research. Это ризонинг + поиск в интернете + какой-то набор tool для обработки полученных данных. Ещё из важного: составляется план исследования и дозапрашиваются непроходимые данные у пользователя. По сути это AI агент, заточенный под исследования.
Недавно тестировал такой режим у Mistral.
На мою просьбу сравнить скорость сборки Docker образов, модель не просто поискала в интернете тесты, а вначале уточнила сложность образа и возможность включить кэширование(!), после чего сделала вот такой план выполнения запроса:
1) создать docker файлы с нужным настройками
2) сформировать команду для измерения времени сборки для всех видов сборки
3) запустить команду n раз, посчитать среднее
В ответе кроме плана и таблицы с результатами (среднее, max, min), была конфигурация тестового сервера (!!!), описание плюсов и минусов всех инструментов сборки и рекомендации по их использованию.
Думаю - вот до чего техника дошла. И LLM модель, и поиск в вебе, и ещё виртуалку для выполнения задачи подняли. Реально - AI джун. И все бесплатно.
Но червячок сомнения точит... Спросил у модели - а ты реально виртуалку подняла для теста? Нет, говорит, не умею я такого. А откуда цифры тогда, дай источник? Нет источника, синтезировала цифры. Вот тебе ссылки, ищи там, результаты неточные (((
Вывод:
а) LLM модели врут
б) очень хотелось бы иметь такого джуна.
Из хорошего - инструмент доступен без VPN и есть бесплатные попытки. Полезен, если для выполнения задачи достаточно поиска. Ещё может с планом исследования помочь. Что интересно: неделю назад было 10 попыток в месяц, сейчас стало 5, кроме того появилось разделение по скорости - одна попытка быстрая, 4 - медленные. Экономика должна быть экономной)
3) OpenRouter - веб-сервис, являющийсф прокси-адаптером к куче LLM моделей с ChatGPT API. Область применения:
а) запуск кода, написанного для OpenAPI, на других моделях
б) динамический выбор модели в зависимости от задачи/цены без необходимости хранить кучу разных credentials у себя
в) отказоустойчивость.
Из хорошего - много моделей и небольшая наценка.
Из плохого - недавно закрыли доступ из России.
Из интересного - вот тут можно глянуть рейтинг моделей, используемых для разработки https://openrouter.ai/rankings?category=programming#categories
Ясно, что он искажён в части доли ChatGPT. Т.к. если тебя полностью устраивает ChatGPT, то ты не будешь использовать прокси. Но все же интересно)
#ai #llm #ai_agents
LMArena
An open platform for evaluating AI through human preference
😁1
Всем привет!
Для IntelliJ IDEA появился новый плагин - Spring Debugger.
Цель создания понятна - мир бинов типичного Spring приложения огромен и запутан. Периодически что-то ломается, возникают вопросы типа такого: "Почему (не)поднялся тот или иной бин"?
Как всегда - статья: https://habr.com/ru/companies/spring_aio/articles/924550/
И кратко то, что меня зацепило:
1) в окне Spring показывает какие из бинов не инстанцированы или заменены моком
2) во время выполнения показывает фактически значения настроек в application.properties(yml) - там где они переопределены или рассчитаны
3) при заходе в метод подсказывает, если он выполняется внутри транзакции и детали транзакции: уровень изоляции, propagation, место начала
4) там же отображает состояние JPA кэша первого уровня в реальном времени
5) REPL для Spring-контекста: в окне Threads&Variables можно искать не только локальные объекты, но и любые Spring бины из контекста, с автодополнением и вызовом методов.
6) там же можно вбить имя настройки и увидеть откуда оно считалось (главное не забыть переключить область поиска с Java на Spring Properties).
Увы, доступен только в Ultimate. Если это не препятствие - рекомендую.
P.S. Вначале создаем Spring приложения с кучей бинов, потом героически преодолеваем сложность)
#idea #ide #debug #dropapp
Для IntelliJ IDEA появился новый плагин - Spring Debugger.
Цель создания понятна - мир бинов типичного Spring приложения огромен и запутан. Периодически что-то ломается, возникают вопросы типа такого: "Почему (не)поднялся тот или иной бин"?
Как всегда - статья: https://habr.com/ru/companies/spring_aio/articles/924550/
И кратко то, что меня зацепило:
1) в окне Spring показывает какие из бинов не инстанцированы или заменены моком
2) во время выполнения показывает фактически значения настроек в application.properties(yml) - там где они переопределены или рассчитаны
3) при заходе в метод подсказывает, если он выполняется внутри транзакции и детали транзакции: уровень изоляции, propagation, место начала
4) там же отображает состояние JPA кэша первого уровня в реальном времени
5) REPL для Spring-контекста: в окне Threads&Variables можно искать не только локальные объекты, но и любые Spring бины из контекста, с автодополнением и вызовом методов.
6) там же можно вбить имя настройки и увидеть откуда оно считалось (главное не забыть переключить область поиска с Java на Spring Properties).
Увы, доступен только в Ultimate. Если это не препятствие - рекомендую.
P.S. Вначале создаем Spring приложения с кучей бинов, потом героически преодолеваем сложность)
#idea #ide #debug #dropapp
Хабр
Разбираемся со Spring Boot с помощью Spring Debugger
Команда Spring АйО перевела статью о работе со Spring Debugger и о том, как его применение существенно облегчает отладку приложений, написанных с использованием Spring Boot. На момент написания статьи...
UUID ключи в PostgreSQL
Я уже писал про версии UUID https://t.me/javaKotlinDevOps/264
Особенно интересной выглядит 7-я версия для использования в БД для построения индексов по двум причинам:
1) позволяет сортировать записи по времени создания
2) значение содержит метку времени, ее можно извлечь
Ну и эффект, наблюдаемый только в БД - записи ложатся последовательно в индексах и, соответственно, partition благодаря тому, что генерируются монотонно возрастающие значения.
Стандарт был принят в мае 2024 года https://datatracker.ietf.org/doc/rfc9562/
И не прошло и полгода (прошел год, но в мире БД это кажется даже быстро) и появляется PostgreSQL 18 c нативной поддержкой UUID v7 (функции uuidv7() и uuid_extract_timestamp) https://habr.com/ru/companies/spring_aio/articles/946168/
P.S. Если вчитаться в стандарт - попадаешь в кроличью нору:
1) для целей безопасности метка времени обрезается до миллисекунд
2) но чтобы получить возрастающие значения используется счетчик
3) счетчик инициализируется случайным числом, во избежание коллизий
4) есть защита от переполнения счетчика - допустимо использовать как счетчик ту часть метки времени, которую мы обнулили ранее, главное не перейти за границы миллисекунды. Если и этого не хватит - вопрос...
5) генератор должен хранить время t0, чтобы при переводе времени продолжать использовать исходное время и значения были уникальными и монотонно возрастающими
...
#postgresql #uuid
Я уже писал про версии UUID https://t.me/javaKotlinDevOps/264
Особенно интересной выглядит 7-я версия для использования в БД для построения индексов по двум причинам:
1) позволяет сортировать записи по времени создания
2) значение содержит метку времени, ее можно извлечь
Ну и эффект, наблюдаемый только в БД - записи ложатся последовательно в индексах и, соответственно, partition благодаря тому, что генерируются монотонно возрастающие значения.
Стандарт был принят в мае 2024 года https://datatracker.ietf.org/doc/rfc9562/
И не прошло и полгода (прошел год, но в мире БД это кажется даже быстро) и появляется PostgreSQL 18 c нативной поддержкой UUID v7 (функции uuidv7() и uuid_extract_timestamp) https://habr.com/ru/companies/spring_aio/articles/946168/
P.S. Если вчитаться в стандарт - попадаешь в кроличью нору:
1) для целей безопасности метка времени обрезается до миллисекунд
2) но чтобы получить возрастающие значения используется счетчик
3) счетчик инициализируется случайным числом, во избежание коллизий
4) есть защита от переполнения счетчика - допустимо использовать как счетчик ту часть метки времени, которую мы обнулили ранее, главное не перейти за границы миллисекунды. Если и этого не хватит - вопрос...
5) генератор должен хранить время t0, чтобы при переводе времени продолжать использовать исходное время и значения были уникальными и монотонно возрастающими
...
#postgresql #uuid
Telegram
(java || kotlin) && devOps
Всем привет!
Наверное все здесь знают, что такое UUID. Universally Unique IDentifier. Можно использовать как искусственный ключ. С высокой точностью обеспечивает уникальность, хотя и не 100%. Казалось бы, о чем здесь можно рассказывать. Ну и UUID и UUID.…
Наверное все здесь знают, что такое UUID. Universally Unique IDentifier. Можно использовать как искусственный ключ. С высокой точностью обеспечивает уникальность, хотя и не 100%. Казалось бы, о чем здесь можно рассказывать. Ну и UUID и UUID.…
👀2
Небольшая заметка.
Мы обсуждаем, как хорошо AI пишет код. Но люди его используют совсем не для этого: https://t-j.ru/news/how-people-use-chatgpt
Это я, к тому, для каких задач его будут оптимизировать.
С другой стороны: да, 4% казалось бы немного. Но если сравнить с обычным поиском, то рост раза в 2. Точных цифр по доле запросов по разработке в поисковом трафике нет, но тот же ChatGPT дает неплохую оценку исходя из числа разработчиков и среднего числа их запросов в день.
#ai
Мы обсуждаем, как хорошо AI пишет код. Но люди его используют совсем не для этого: https://t-j.ru/news/how-people-use-chatgpt
Это я, к тому, для каких задач его будут оптимизировать.
С другой стороны: да, 4% казалось бы немного. Но если сравнить с обычным поиском, то рост раза в 2. Точных цифр по доле запросов по разработке в поисковом трафике нет, но тот же ChatGPT дает неплохую оценку исходя из числа разработчиков и среднего числа их запросов в день.
#ai
Т—Ж
Как люди используют ChatGPT: главное из исследования OpenAI
Просят совета, гуглят и редактируют тексты
Как быстрее погрузиться в код?
Речь про существующий микросервис и нового разработчика.
Я уже писал, что JavaDoc (KDoc) не является обязательным для каждого метода\поля или класса (как минимум для бизнес-приложения, общие библиотеки - особый кейс), т.к. документацию никто не читает.
А что же тогда будет документацией? Например, тесты. Их конечно тоже новичок не будет читать на 100%, но во-первых их и так нужно писать, а во-вторых - при рефакторинге падающий тест покажет, что забыли поправить, а в целом любой существующий тест изменяемого класса покажет, как он работает.
А недавно я нашел еще один полезный способ задокументировать микросервис так, чтобы этой "документацией" пользовались.
Начну немного издалека. Есть такая ИТ консалтинговая компания как Thoughtworks. Ну есть и есть, где мы и где консалтинг. Но там работает такой небезызвестный человек, как Мартин Фаулер. Главный научным руководителем https://www.thoughtworks.com/profiles/leaders/martin-fowler
А это внушает некий уровень доверия.
Так вот, компания ведет реестр технологий а-ля техрадар.
И в текущей его версии есть такая штука https://www.thoughtworks.com/en-de/radar/techniques/api-request-collection-as-api-product-artifact
как коллекция API запросов как артефакт продукта.
На самом деле мысль лежит на поверхности, я уже достаточно давно практикую прихранивание запросов в формате IDEA api collection вместе с исходниками в тех проектах, над которыми приходилось работать. Да, над форматом стоит подумать отдельно, возможно Insomnia будет по-универсальнее, зависит от команды и организации. Но сама идея мне очень нравится. Такой документацией точно будут пользоваться.
P.S. Кто ее должен делать - разработчики или тестировщики и нужно ли шарить коллекцию между ними - тоже вопрос для обсуждения. В идеале - думаю, что да.
P.P.S. Да, когда я говорю про артефакт продукта - это значит мало ее сделать, ее нужно поддерживать в актуальном состоянии.
#api #onbording #documentation
Речь про существующий микросервис и нового разработчика.
Я уже писал, что JavaDoc (KDoc) не является обязательным для каждого метода\поля или класса (как минимум для бизнес-приложения, общие библиотеки - особый кейс), т.к. документацию никто не читает.
А что же тогда будет документацией? Например, тесты. Их конечно тоже новичок не будет читать на 100%, но во-первых их и так нужно писать, а во-вторых - при рефакторинге падающий тест покажет, что забыли поправить, а в целом любой существующий тест изменяемого класса покажет, как он работает.
А недавно я нашел еще один полезный способ задокументировать микросервис так, чтобы этой "документацией" пользовались.
Начну немного издалека. Есть такая ИТ консалтинговая компания как Thoughtworks. Ну есть и есть, где мы и где консалтинг. Но там работает такой небезызвестный человек, как Мартин Фаулер. Главный научным руководителем https://www.thoughtworks.com/profiles/leaders/martin-fowler
А это внушает некий уровень доверия.
Так вот, компания ведет реестр технологий а-ля техрадар.
И в текущей его версии есть такая штука https://www.thoughtworks.com/en-de/radar/techniques/api-request-collection-as-api-product-artifact
как коллекция API запросов как артефакт продукта.
На самом деле мысль лежит на поверхности, я уже достаточно давно практикую прихранивание запросов в формате IDEA api collection вместе с исходниками в тех проектах, над которыми приходилось работать. Да, над форматом стоит подумать отдельно, возможно Insomnia будет по-универсальнее, зависит от команды и организации. Но сама идея мне очень нравится. Такой документацией точно будут пользоваться.
P.S. Кто ее должен делать - разработчики или тестировщики и нужно ли шарить коллекцию между ними - тоже вопрос для обсуждения. В идеале - думаю, что да.
P.P.S. Да, когда я говорю про артефакт продукта - это значит мало ее сделать, ее нужно поддерживать в актуальном состоянии.
#api #onbording #documentation
Thoughtworks
Martin Fowler
Martin Fowler, Chief Scientist and Agile pioneer at Thoughtworks—author of key software architecture works. Learn more.
🔥1
Основные проблемы AI в разработке.
Я вижу две основные проблемы.
Первая - принципиально недетерминированный ответ как отражение вероятностной природы LLM. Если в креативных задачах это плюс, но в разработке скорее минус.
Вторая - естественный язык не самое лучшее API из-за своей неоднозначности.
И для второй, а частично и для первой проблемы есть решение - паттерн structured output. Суть проста - мы говорим модели, в каком виде хотели бы получить ответ. Это может быть JSON схема или класс Response. Базовый формат - JSON, но он на уровне библиотеки легко трансформируется в класс для большинства языков программирования. Ключевой момент - вызов модели должен вернуть правильный по структуре JSON с вероятностью 100%. И далее его можно или без лишних проверок парсить и передавать на вход следующему методу.
Реализован паттерн должен быть в самой модели, так как на уровне библиотеки или промта гарантии 100% соответствия получить нельзя.
Вот статья с примером использования:
https://habr.com/ru/articles/923096
P.S. Паттерны есть везде, коллекция AI паттернов постепенно растёт)
#ai #llm
Я вижу две основные проблемы.
Первая - принципиально недетерминированный ответ как отражение вероятностной природы LLM. Если в креативных задачах это плюс, но в разработке скорее минус.
Вторая - естественный язык не самое лучшее API из-за своей неоднозначности.
И для второй, а частично и для первой проблемы есть решение - паттерн structured output. Суть проста - мы говорим модели, в каком виде хотели бы получить ответ. Это может быть JSON схема или класс Response. Базовый формат - JSON, но он на уровне библиотеки легко трансформируется в класс для большинства языков программирования. Ключевой момент - вызов модели должен вернуть правильный по структуре JSON с вероятностью 100%. И далее его можно или без лишних проверок парсить и передавать на вход следующему методу.
Реализован паттерн должен быть в самой модели, так как на уровне библиотеки или промта гарантии 100% соответствия получить нельзя.
Вот статья с примером использования:
https://habr.com/ru/articles/923096
P.S. Паттерны есть везде, коллекция AI паттернов постепенно растёт)
#ai #llm
Хабр
Structured Output как полноценная замена Function Calling
В этой статье мы рассмотрим альтернативный подход вызова инструментов LLM, который использует Structured Output вместо традиционного Function Calling для обеспечения надежности...
RestTemplate is dead, baby)))
Spring наконец-то решили задепрекейтить RestTemplate.
Пруф: https://spring.io/blog/2025/09/30/the-state-of-http-clients-in-spring
Его замены в fluent стиле: RestClient для синхронного и WebCLient для асинхронного взаимодействия.
Видимо, команда Spring таки выпилила его из компонентов фреймворка и теперь предлагает это сделать всем остальным)
На самом деле я немного добавил сенсационности в пост.
А реальная хронология событий планируется такая:
- в ноябре этого года (Spring 7.0) будет объявлено о том, что компонент deprecated
- формально deprecated он станет в ноябре 2026 года (Spring 7.1)
- выпилят в Spring 8.0 где-то в 27 году.
Это мир Java == мир обратной совместимости)
#spring #web
Spring наконец-то решили задепрекейтить RestTemplate.
Пруф: https://spring.io/blog/2025/09/30/the-state-of-http-clients-in-spring
Его замены в fluent стиле: RestClient для синхронного и WebCLient для асинхронного взаимодействия.
Видимо, команда Spring таки выпилила его из компонентов фреймворка и теперь предлагает это сделать всем остальным)
На самом деле я немного добавил сенсационности в пост.
А реальная хронология событий планируется такая:
- в ноябре этого года (Spring 7.0) будет объявлено о том, что компонент deprecated
- формально deprecated он станет в ноябре 2026 года (Spring 7.1)
- выпилят в Spring 8.0 где-то в 27 году.
Это мир Java == мир обратной совместимости)
#spring #web
The state of HTTP clients in Spring
Level up your Java code and explore what Spring can do for you.
👍2
Языки программирования общего назначения?
Java, Python, C, Go. Формально, технически - да, все это универсальные языки, которые можно применять в любой, задача. А фактически?
Говорим Python - подразумеваем Data Science, ML и AI.
Go захватил разработку крипты. Плюс операторы в k8s.
Kotlin - от 70 до 90% приложений в Google Play (топовых приложений если быть точным, т.к. есть "хвост" легаси)
Похожая картина у Swift - примерно 60% в iOS (доля бинпрников в iOS 17).
C# - нативные Windows приложения (Delphi и VB.NET эту битву проиграли).
Groovy нашел свою нишу в Jenkins как DSL (Gradle еще, но там его теснит Kotlin, да и не должны Gradle скрипты быть большими).
Lua - язык плагинов (Nginx, Tarantool) и скриптовый язык для игр. То бишь - король DSL.
Драйвера пишут на C (до сих пор ли? Раньше так было).
Да, экосистема (библиотеки, фреймворки, документация, сообщество) рулит)
И вопрос - что я забыл?
#lang
Java, Python, C, Go. Формально, технически - да, все это универсальные языки, которые можно применять в любой, задача. А фактически?
Говорим Python - подразумеваем Data Science, ML и AI.
Go захватил разработку крипты. Плюс операторы в k8s.
Kotlin - от 70 до 90% приложений в Google Play (топовых приложений если быть точным, т.к. есть "хвост" легаси)
Похожая картина у Swift - примерно 60% в iOS (доля бинпрников в iOS 17).
C# - нативные Windows приложения (Delphi и VB.NET эту битву проиграли).
Groovy нашел свою нишу в Jenkins как DSL (Gradle еще, но там его теснит Kotlin, да и не должны Gradle скрипты быть большими).
Lua - язык плагинов (Nginx, Tarantool) и скриптовый язык для игр. То бишь - король DSL.
Драйвера пишут на C (до сих пор ли? Раньше так было).
Да, экосистема (библиотеки, фреймворки, документация, сообщество) рулит)
И вопрос - что я забыл?
#lang
Небольшой забавный (и при этом грустный) факт о JVM.
Для запуска Hello world приложения на Java JVM загружает 450 классов.
Пруф: https://inside.java/2025/01/28/jvm-start-up/
#jvm #fun_facts
Для запуска Hello world приложения на Java JVM загружает 450 классов.
Пруф: https://inside.java/2025/01/28/jvm-start-up/
#jvm #fun_facts
inside.java
A Deep Dive into JVM Start-up
A deep-dive into all the processes and work the JVM performs on start-up.
😱4
Если IDEA легла при старте. Или mini IDEA troobleshooting guide.
Что можно сделать?
Вариант номер ноль - обругать нехорошими словами разработчиков IDE и откатиться на предыдущую версию. Хотя, разработчики IDE могут быть не виноваты, о чем ниже)
Если вас этот вариант не устраивает - вот на что стоит обратить внимание.
Предусловие - надо вспомнить где у вас хранятся настройки IDEA. По умолчанию на примере Windows это %USERDATA%\AppData\Local\xxx\yyy, xxx - это JetBrains\GIGAIDE\..., а yyy - имя IDE.
Но через idea.properties это место можно переопределить.
И так.
1) Логи. По умолчанию лежат в %USERDATA%\AppData\Local\xxx\yyy\log\idea.log
В логах стоит обратить внимание на исключения. Как ни странно, искать их надо по SEVERE, а не ERROR
Возможно из исключения будет сразу понятна причина.
2) Плагины. Часто в исключении есть какие-то классы, но за что они отвечают - не ясно. Но если перед исключением есть строчка
Plugin to blame: xxx,
то предполагаемый виновник найден.
Очень часто это новый плагин или его новая версия.
Его надо отключить. Но IDE не стартует, и настройки в UI недоступны.
Не беда - внешние плагины можно отключить удалив соответствующую папку из %USERDATA%\AppData\Roaming\xxx\yyy\plugins.
Бывают сбои и во встроенных (bundled) плагинах, поэтому есть второй способ: добавить id плагина в файл %USERDATA%\AppData\Roaming\xxx\yyy\disabled_plugins.txt
Важно - id, а не имя. id это по сути grouId артифакта, найти его можно в логе.
3) Текущий проект. У меня были кейсы, когда даже с плагином с утечкой памяти, сжирающим 6, 8, 16 Гб - т.е. все что дадут - удавалось запустить IDE открыв пустой проект. Но IDEA по умолчанию открывает последние проекты. Вариант решения - переименовать папку, чтобы она их не нашла.
4) Опции запуска. https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html#arguments
Могут помочь решить проблему следующие:
а) disableNonBundledPlugins - запуск IDE без внешних плагинов
б) dontReopenProjects - более элегантный вариант открыть IDEA без последних проектов
5) Память. Если в логах есть OutOfMemoryError - можно попробовать увеличить Heap для IDEA. Почему можно попробовать - потому что это не панацея, при утечке памяти не поможет.
Второй вопрос - как увеличить? Через idea64.exe.vmoptions.
А если не хватает прав его поправить?
Есть его "профильный" (лежащий в профиле пользователя) двойник %USERDATA%\AppData\Roaming\xxx\yyy\idea64.exe.vmoptions.
Рекомендую использовать его, особенно если у вас настройки IDEA в кастомной папке, не меняющейся от версии к версии.
6) thread dump и heap dump. Больше помогут разрабам IDE, но глянуть можно.
Создаются в двух случаях.
а) При каждом зависании (freeze) создаются в %USERDATA%\AppData\Local\xxx\yyy\log\threadDumps-freeze-zzz
б) при OutOfMemory с включенной опцией -XX:+HeapDumpOnOutOfMemoryError (а в idea64.exe.vmoptions она по умолчанию есть) в %USERDATA% создается heapdump и лог, включающий threaddumps
На сегодня все, если найду еще интересные лайфхаки - сделаю новый пост.
#idea #ide #troubleshooting
Что можно сделать?
Вариант номер ноль - обругать нехорошими словами разработчиков IDE и откатиться на предыдущую версию. Хотя, разработчики IDE могут быть не виноваты, о чем ниже)
Если вас этот вариант не устраивает - вот на что стоит обратить внимание.
Предусловие - надо вспомнить где у вас хранятся настройки IDEA. По умолчанию на примере Windows это %USERDATA%\AppData\Local\xxx\yyy, xxx - это JetBrains\GIGAIDE\..., а yyy - имя IDE.
Но через idea.properties это место можно переопределить.
И так.
1) Логи. По умолчанию лежат в %USERDATA%\AppData\Local\xxx\yyy\log\idea.log
В логах стоит обратить внимание на исключения. Как ни странно, искать их надо по SEVERE, а не ERROR
Возможно из исключения будет сразу понятна причина.
2) Плагины. Часто в исключении есть какие-то классы, но за что они отвечают - не ясно. Но если перед исключением есть строчка
Plugin to blame: xxx,
то предполагаемый виновник найден.
Очень часто это новый плагин или его новая версия.
Его надо отключить. Но IDE не стартует, и настройки в UI недоступны.
Не беда - внешние плагины можно отключить удалив соответствующую папку из %USERDATA%\AppData\Roaming\xxx\yyy\plugins.
Бывают сбои и во встроенных (bundled) плагинах, поэтому есть второй способ: добавить id плагина в файл %USERDATA%\AppData\Roaming\xxx\yyy\disabled_plugins.txt
Важно - id, а не имя. id это по сути grouId артифакта, найти его можно в логе.
3) Текущий проект. У меня были кейсы, когда даже с плагином с утечкой памяти, сжирающим 6, 8, 16 Гб - т.е. все что дадут - удавалось запустить IDE открыв пустой проект. Но IDEA по умолчанию открывает последние проекты. Вариант решения - переименовать папку, чтобы она их не нашла.
4) Опции запуска. https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html#arguments
Могут помочь решить проблему следующие:
а) disableNonBundledPlugins - запуск IDE без внешних плагинов
б) dontReopenProjects - более элегантный вариант открыть IDEA без последних проектов
5) Память. Если в логах есть OutOfMemoryError - можно попробовать увеличить Heap для IDEA. Почему можно попробовать - потому что это не панацея, при утечке памяти не поможет.
Второй вопрос - как увеличить? Через idea64.exe.vmoptions.
А если не хватает прав его поправить?
Есть его "профильный" (лежащий в профиле пользователя) двойник %USERDATA%\AppData\Roaming\xxx\yyy\idea64.exe.vmoptions.
Рекомендую использовать его, особенно если у вас настройки IDEA в кастомной папке, не меняющейся от версии к версии.
6) thread dump и heap dump. Больше помогут разрабам IDE, но глянуть можно.
Создаются в двух случаях.
а) При каждом зависании (freeze) создаются в %USERDATA%\AppData\Local\xxx\yyy\log\threadDumps-freeze-zzz
б) при OutOfMemory с включенной опцией -XX:+HeapDumpOnOutOfMemoryError (а в idea64.exe.vmoptions она по умолчанию есть) в %USERDATA% создается heapdump и лог, включающий threaddumps
На сегодня все, если найду еще интересные лайфхаки - сделаю новый пост.
#idea #ide #troubleshooting
IntelliJ IDEA Help
Command-line interface | IntelliJ IDEA
👍1