Этот коммит содержится в:
Ihar Hancharenka 2024-06-28 16:35:21 +03:00
родитель 8dedd9a160
Коммит 34be9dd7e3
8 изменённых файлов: 66 добавлений и 0 удалений

Просмотреть файл

@ -1,3 +1,5 @@
2024
https://habr.com/ru/companies/oleg-bunin/articles/824826/
2023
https://blog.ydb.tech/ydb-meets-tpc-c-distributed-transactions-performance-now-revealed-42f1ed44bd73
https://habr.com/ru/companies/ydb/articles/763938/

Просмотреть файл

@ -0,0 +1,45 @@
*****************************************************************************
Если у вас в PostgreSQL включено параллельное выполнение запросов, то планировщик, в целях повышения производительности выполнения запроса может решить использовать его. Что такое параллельное выполнение запросов, как работает и как его настроить будем разбираться в этой заметке.
Технически параллельное выполнение запросов происходит так: запрос разбивается на несколько частей и выполняется несколькими фоновыми процессами. Фоновые процессы общаются между собой через общий буфуер. Как только каждая часть запроса будет выполнена, его результат будет аккомулирован и передан ведущему процессу.
Результат команды EXPLAIN при параллельном выполнении запроса будет выглядеть примерно вот так:
Gather (cost=0.00..46010.00 rows=1000000 width=43)
Workers Planned: 4
Workers Launched: 4
-> Parallel Seq Scan on my_table (cost=0.00..44010.00 rows=230000 width=43)
Вместо Gather еще может быть Gather Merge. В чем разница, разберемся дальше.
Здесь Gather показывает нам, что результат запроса был собран из нескольких параллельных процессов, Workers Planned - сколько параллельных процессов было запланировано к использованию планировщиком запросов, Workers Launched - сколько фактически параллельных процессов было использовано.
Разница между Gather и Gather Merge заключается в том, что Gather Merge участвует в операциях сортировки (ORDER BY), т.е. когда каждый из фоновых процессов производит сортировку своей части запроса и передает результат для финального слияния ведущему процессу. Gather используется в запросах без сортировки.
Есть несколько параметров в файле postgresql.conf, с помощью которых мы можем управлять параллельным выполнением запросов:
max_worker_processes - контролирует общее кол-во фоновых процессов, доступных всему кластеру PostgreSQL;
max_parallel_workers - контролирует общее кол-во активных процессов, доступных всему кластеру PostgreSQL для параллельного выполнения запросов. Значение этого параметра должно быть меньшим или равным значению параметра max_worker_processes;
max_parallel_workers_per_gather - значение этого параметра контролирует кол-во фоновых процессов, доступных для параллельного выполнения одного запроса.
Есть еще несколько параметров, с помощью которых мы можем контролировать стоимость выполнения параллельных запросов:
parallel_setup_cost - устанавливает стоимость запуска одного фонового процесса и выделения ему памяти. Значение по умолчанию 1000;
parallel_tuple_cost - устанавливает стоимость передачи данных между фоновыми процессами. Значение по умолчанию 0.1.
А еще мы можем управлять параллельным сканированием таблиц и индексов:
min_parallel_table_scan_size - устанавливает минимальный размер таблицы, при котором PostgreSQL примет решение о ее параллельном сканировании. Значение устанавливается в байтах, значение по умолчанию - 8MB. Т.е. параллельное сканирование не будет включаться на таблицах, объем которых меньше 8MB;
min_parallel_index_scan_size - тоже самое, что и предыдущий параметр, только для индексов. Значение по умолчанию 8MB.
А еще можно включить параметр force_parallel_mode (по умолчанию OFF) и тогда PostgreSQL будет пытаться параллелить все что возможно. Но на рабочем кластере лучше так не делать, так как могут быть неприятные нюансы.
Параллельное выполнение запросов наиболее эффективно при OLAP нагрузке, т.е. когда у вас в базе происходят долгие запросы для формирования какого-нибудь аналитического отчета. Когда у вас много коротких запросов, которые создают, обновляют или удаляют данные в базе, т.е. OLTP нагрузка, то толку от параллельного выполнения запросов будет мало, или не будет вообще.
Для программ семейства 1с вообще рекомендуют отключать параллелизм, т.е. ставить параметр max_parallel_workers_per_gather в ноль, но тут все не так просто и настройки параллелизма могут зависеть от конкретной ситуации и типа нагрузки на базу данных.
О нюансах параллелизма запросов ещё расскажем в будущих постах 😉.

Просмотреть файл

@ -1,2 +1,6 @@
https://github.com/GoogleContainerTools/distroless
https://github.com/GoogleCloudPlatform/distroless
2022
https://iximiuz.com/en/posts/containers-distroless-images/
https://habr.com/ru/companies/flant/articles/822427/

5
pl/java/libfws/security/crypto-pro.txt Обычный файл
Просмотреть файл

@ -0,0 +1,5 @@
https://www.cryptopro.ru/products/csp
2024
https://habr.com/ru/companies/alfastrah/articles/823974/
https://github.com/engine-it-in/service-with-custom-TLS-context

Просмотреть файл

@ -30,6 +30,7 @@ public class MyBean {
testing
2024
https://habr.com/ru/articles/824594/
https://habr.com/ru/companies/alfastrah/articles/816057/
batching

Просмотреть файл

@ -1,2 +1,8 @@
2024
https://habr.com/ru/articles/824594/
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.config.strategy=dynamic
junit.jupiter.execution.parallel.mode.classes.default=concurrent
junit.jupiter.execution.parallel.mode.default=same_thread
2022
https://habr.com/ru/company/otus/blog/671122/

Просмотреть файл

@ -1,4 +1,5 @@
2024
https://habr.com/ru/articles/824594/
https://habr.com/ru/articles/819589/
2023
https://www.atomicjar.com/2023/12/building-spring-boots-serviceconnection-for-testcontainers-wiremock/

Просмотреть файл

@ -18,6 +18,8 @@ http://rust.unhandledexpression.com/nom/making_a_new_parser_from_scratch.html
http://rust.unhandledexpression.com/nom/error_management.html
http://rust.unhandledexpression.com/nom/how_nom_macros_work.html
2024
https://habr.com/ru/companies/otus/articles/816687/
2022
https://naiveai.hashnode.dev/practical-parsing-nom
2021