LINUX.ORG.RU
Форум — Web-development  

Оптимизация Postresql для локальней разработки с Django

 , ,


0

1

В общем задумался о том, что у меня unit test тормозят. Особенно на стадии инициализации базы.

Задумался, можно ли это дело как-то оптимизировать. Возможно через подбор параметров базы, чтоб WAL писать по минимому например.

Проблема еще в том, что на машине 4Гб памяти и ее в притык.

★★★★
← Отображение специальных символов в Chrome
Господа, компоненты формы выглядят по разному в браузерах →

Остаётся только отключить логирование, wal, включить небезопасные настройки фс и в путь !

Deleted
()
Ответ на: комментарий от namezys

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

Vit ★★★★★
()
Ответ на: комментарий от namezys

IMHO ты путаешь юнит-тесты с какими-то другими, например интеграционными.

Ну и всегда можно отпилить всё тяжелое, чтобы пускалось только на CI. Это проще, чем заниматься кроиловым в 4 гигах.

Vit ★★★★★
()
Ответ на: комментарий от Vit

для этого придется очень глубоко залечит в код джанги.

или подменить драйвер BD.

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

namezys ★★★★
() автор топика
Ответ на: комментарий от Vit

Для того, чтоб отправить, надо бы еще написать, что отправить. В CI и так все запускается.

Мне обычно надо ~10 тестов. Но 90% времени уходит на инициализацию базы

namezys ★★★★
() автор топика

Особенно на стадии инициализации базы.

Если сама по себе инициализация базы тестом не является, то может просто заготовить заранее бинарнички с данными под конкретную версию postgresql? Или внешний кеш какой-нибудь завести для этих же целей.

Deleted
()
Ответ на: комментарий от namezys

Не сбивай с толку тогда терминологией, что у тебя юнит-тесты.

Можно еще попробовать целиком директорию с базой копировать, вместо того чтобы дамп заливать.

Vit ★★★★★
()

В джанговой тестилке вроде можно инициализировать базу не на каждый тест, а один раз. Тесты не такие чистые будут, но пошустрее.

legolegs ★★★★★
()
Ответ на: комментарий от namezys

nobarrier,writeback например. ну, плюс ещё попробовать выделить чуть больше памяти для postgresql и включить zswap.

Deleted
()
Ответ на: комментарий от Deleted

Слишком часто эти данные меняются.

нет цели ускорить есть где нить на CI.

namezys ★★★★
() автор топика
Ответ на: комментарий от Vit

Это как раз и unit тесты. Интеграционные тесты отдельно.

Фикчером для юнит тестов здесь является состояние базы.

Да, я понимаю, теоретически можно мок на драйвер сделать, но даже django не пошли на это. А у меня уйдет слишком много времени.

namezys ★★★★
() автор топика
Ответ на: комментарий от legolegs

Проблема в том, что мне надо 1-2 теста. Когда я запускаю пачку, мне время не так важно.

namezys ★★★★
() автор топика
Ответ на: комментарий от hippi90

Это довольно порочная практика. Даже с ORM, БД выолняет некоторую часть логической работы. И, как показывает практика, разница в SQL и SQLite в джанге есть и местами такая, что тесты могут валиться исключительно от смены решения.
Понятно что валятся они ещё и потому, что код не самыми прмыми руками писан, но всё-же.

Goury ★★★★★
()
Ответ на: комментарий от Goury

у меня используется куча специфичных для postgresql вещей, от массива и h-store до jsonb

namezys ★★★★
() автор топика
Ответ на: комментарий от Goury

Это нормальная практика. Потому что, надо сначала определиться, что вы тестируете: бизнес-логику или взаимодействие компонентов. Если твоя бизнес-логика зависит от того, откуда ты получил данные, то пора переквалифицироваться в дворники.

hippi90 ★★★★★
()
Ответ на: комментарий от Deleted 
#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------

# - Memory -

shared_buffers = 32MB  			# min 128kB
       					# (change requires restart)
#huge_pages = try      			# on, off, or try
       					# (change requires restart)
temp_buffers = 8MB     			# min 800kB
max_prepared_transactions = 8  		# zero disables the feature
       					# (change requires restart)
# Caution: it is not advisable to set max_prepared_transactions nonzero unless
# you actively intend to use prepared transactions.
work_mem = 3MB 				# min 64kB
maintenance_work_mem = 12MB    		# min 1MB
#autovacuum_work_mem = -1      		# min 1MB, or -1 to use maintenance_work_mem
#max_stack_depth = 2MB 			# min 100kB
dynamic_shared_memory_type = posix     	# the default is the first option
       					# supported by the operating system:
       					#   posix
       					#   sysv
       					#   windows
       					#   mmap
       					# use none to disable dynamic shared memory

# - Disk -

#temp_file_limit = -1  			# limits per-session temp file space
       					# in kB, or -1 for no limit

# - Kernel Resource Usage -

#max_files_per_process = 1000  		# min 25
       					# (change requires restart)
#shared_preload_libraries = '' 		# (change requires restart)

# - Cost-Based Vacuum Delay -

#vacuum_cost_delay = 0 			# 0-100 milliseconds
#vacuum_cost_page_hit = 1      		# 0-10000 credits
#vacuum_cost_page_miss = 10    		# 0-10000 credits
#vacuum_cost_page_dirty = 20   		# 0-10000 credits
#vacuum_cost_limit = 200       		# 1-10000 credits

# - Background Writer -

#bgwriter_delay = 200ms			# 10-10000ms between rounds
#bgwriter_lru_maxpages = 100   		# 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0 		# 0-10.0 multipler on buffers scanned/round

# - Asynchronous Behavior -

#effective_io_concurrency = 0  		# 1-1000; 0 disables prefetching
#max_worker_processes = 8


#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------

# - Settings -

#wal_level = minimal   			# minimal, archive, hot_standby, or logical
       					# (change requires restart)
fsync = off    				# turns forced synchronization on or off
#synchronous_commit = on       		# synchronization level;
       					# off, local, remote_write, or on
#wal_sync_method = fsync       		# the default is the first option
       					# supported by the operating system:
       					#   open_datasync
       					#   fdatasync (default on Linux)
       					#   fsync
       					#   fsync_writethrough
       					#   open_sync
#full_page_writes = on 			# recover from partial page writes
#wal_compression = off 			# enable compression of full-page writes
#wal_log_hints = off   			# also do full page writes of non-critical updates
       					# (change requires restart)
#wal_buffers = -1      			# min 32kB, -1 sets based on shared_buffers
       					# (change requires restart)
#wal_writer_delay = 200ms      		# 1-10000 milliseconds

commit_delay = 10000   			# range 0-100000, in microseconds
commit_siblings = 100  			# range 1-1000

# - Checkpoints -

#checkpoint_timeout = 5min     		# range 30s-1h
#max_wal_size = 1GB
#min_wal_size = 80MB
#checkpoint_completion_target = 0.5    	# checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s      		# 0 disables

# - Archiving -

#archive_mode = off    		# enables archiving; off, on, or always
       				# (change requires restart)
#archive_command = ''  		# command to use to archive a logfile segment
       				# placeholders: %p = path of file to archive
       				#               %f = file name only
       				# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0   		# force a logfile segment switch after this
       				# number of seconds; 0 disables
namezys ★★★★
() автор топика
Ответ на: комментарий от hippi90

Можно. Можно сделать. Вопрос цены ресурсов. Подменить драйвер БД можно. Но дорого. И тестировать станет сложнее.

namezys ★★★★
() автор топика
Ответ на: комментарий от namezys

Я бы вот эти параметры точно поднял бы значения - 

shared_buffers = 256MB  # лучше еще больше
temp_buffers = 64MB     			# min 800kB
max_prepared_transactions = 0  		
work_mem = 300MB 				# min 64kB
maintenance_work_mem = 500MB
pi11 ★★★★★
()
Последнее исправление: pi11 (всего исправлений: 1)
Ответ на: комментарий от pi11

я бы тоже поднял. но тогда придется отказаться от pycharm

такой объем сразу откушает гиг где-то

namezys ★★★★
() автор топика
Ответ на: комментарий от namezys

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

checkpoint_segments = 10
checkpoint_timeout = 20min

pi11 ★★★★★
()

Такое бывает когда у тебя много миграций, например. squash'ить их не поможет?

Ну и есть keepdb, обычно решающий все проблемы с тестами.

x3al ★★★★★
()
Последнее исправление: x3al (всего исправлений: 1)

Использование PG для тестов всегда будет давать заметную задержку. Это связано с инициализацией базы и наполнением ее тестовыми данными.

1. Используй быстрое файловое хранилище - ssd или tmpfs (но у тебя мало рамы).

Размещай либо PG польностью на быстром диске, либо частично: https://www.postgresql.org/docs/9.5/static/manage-ag-tablespaces.html

И воообще, хватит нищебродствовать - купи себе нормальное железо ,)

2. Если помнишь, то мы на пыхе использовали луковичный подход с begin-rollback-ами.

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

В таком случае все тесты группируются по луковицам и слоям. Сначала запускаешь все тесты для ядра луковицы, setup/teardown делают begin/rollback

Потом подгружаешь следующий слой и запускаешь нужные тесты на нем и т.д.

anonymous
()
Ответ на: комментарий от namezys

Тадысь ой )

Вкладывайся в железо ,)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Отображение специальных символов в Chrome
Web-development
Господа, компоненты формы выглядят по разному в браузерах →