зеркало из
				https://github.com/iharh/notes.git
				synced 2025-10-31 13:46:08 +02:00 
			
		
		
		
	m
Этот коммит содержится в:
		
							родитель
							
								
									8dedd9a160
								
							
						
					
					
						Коммит
						34be9dd7e3
					
				| @ -1,3 +1,5 @@ | |||||||
|  | 2024 | ||||||
|  | https://habr.com/ru/companies/oleg-bunin/articles/824826/ | ||||||
| 2023 | 2023 | ||||||
| https://blog.ydb.tech/ydb-meets-tpc-c-distributed-transactions-performance-now-revealed-42f1ed44bd73 | https://blog.ydb.tech/ydb-meets-tpc-c-distributed-transactions-performance-now-revealed-42f1ed44bd73 | ||||||
|     https://habr.com/ru/companies/ydb/articles/763938/ |     https://habr.com/ru/companies/ydb/articles/763938/ | ||||||
|  | |||||||
							
								
								
									
										45
									
								
								db/sql/postgres/feature/query/parallel-mode.txt
									
									
									
									
									
										Обычный файл
									
								
							
							
						
						
									
										45
									
								
								db/sql/postgres/feature/query/parallel-mode.txt
									
									
									
									
									
										Обычный файл
									
								
							| @ -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/GoogleContainerTools/distroless | ||||||
| https://github.com/GoogleCloudPlatform/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
									
									
									
									
									
										Обычный файл
									
								
							
							
						
						
									
										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 | testing | ||||||
| 2024 | 2024 | ||||||
|  | https://habr.com/ru/articles/824594/ | ||||||
| https://habr.com/ru/companies/alfastrah/articles/816057/ | https://habr.com/ru/companies/alfastrah/articles/816057/ | ||||||
| 
 | 
 | ||||||
| batching | 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 | 2022 | ||||||
| https://habr.com/ru/company/otus/blog/671122/ | https://habr.com/ru/company/otus/blog/671122/ | ||||||
|  | |||||||
| @ -1,4 +1,5 @@ | |||||||
| 2024 | 2024 | ||||||
|  | https://habr.com/ru/articles/824594/ | ||||||
| https://habr.com/ru/articles/819589/ | https://habr.com/ru/articles/819589/ | ||||||
| 2023 | 2023 | ||||||
| https://www.atomicjar.com/2023/12/building-spring-boots-serviceconnection-for-testcontainers-wiremock/ | 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/error_management.html | ||||||
| http://rust.unhandledexpression.com/nom/how_nom_macros_work.html | http://rust.unhandledexpression.com/nom/how_nom_macros_work.html | ||||||
| 
 | 
 | ||||||
|  | 2024 | ||||||
|  | https://habr.com/ru/companies/otus/articles/816687/ | ||||||
| 2022 | 2022 | ||||||
| https://naiveai.hashnode.dev/practical-parsing-nom | https://naiveai.hashnode.dev/practical-parsing-nom | ||||||
| 2021 | 2021 | ||||||
|  | |||||||
		Загрузка…
	
	
			
			x
			
			
		
	
		Ссылка в новой задаче
	
	Block a user
	 Ihar Hancharenka
						Ihar Hancharenka