timescaledb - 将 4GB 文件加载到超表时共享内存不足
timescaledb - out of shared memory when loading a 4GB file to a hypertable
:)
我有 Gentoo Linux,带有 postgresql 11.4 和 timescaledb-1.3.2。
我执行了 timescaledb-tune 来调整我的 postgresql 数据库配置。
我创建了一个包含大约 30 个字段的 table,我们称它为 foo。
我创建了另一个复制的 table,只是将其创建为 hypertable,我们称它为 h_foo.
我有一个 4gb 的 csv 文件,我尝试使用 COPY ... FROM ...
命令将其加载到数据库中
当我尝试将数据加载到常规 table 时,不到一分钟就完成了。
当我尝试将它加载到 hypertable 时,过了一会儿它抱怨共享内存不足并且需要很长时间才能到达错误点。
我认为开箱即用的 timescaledb(不知道高级配置)值得付出努力,但我不再确定了。
我将在下面粘贴我的 postgresql 配置文件,如果有任何我可以修改的地方,请告诉我谁能帮助我加载该 csv 文件。
谢谢
shared_buffers = 8009MB # min 128kB
work_mem = 6835kB # min 64kB
maintenance_work_mem = 2047MB # min 1MB
dynamic_shared_memory_type = posix # the default is the first option
effective_io_concurrency = 200 # 1-1000; 0 disables prefetching
max_worker_processes = 23 # (change requires restart)
max_parallel_workers_per_gather = 6 # taken from max_parallel_workers
max_parallel_workers = 12 # maximum number of max_worker_processes that
wal_buffers = 16MB # min 32kB, -1 sets based on shared_buffers
max_wal_size = 8GB
min_wal_size = 4GB
checkpoint_completion_target = 0.9 # checkpoint target duration, 0.0 - 1.0
random_page_cost = 1.1 # same scale as above
effective_cache_size = 24029MB
default_statistics_target = 500 # range 1-10000
log_timezone = 'Israel'
datestyle = 'iso, mdy'
timezone = 'Israel'
lc_messages = 'en_US.utf8' # locale for system error message
# strings
lc_monetary = 'en_US.utf8' # locale for monetary formatting
lc_numeric = 'en_US.utf8' # locale for number formatting
lc_time = 'en_US.utf8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'timescaledb'
max_locks_per_transaction = 256 # min 10
plperl.on_init = 'use utf8; use re; package utf8; require "utf8_heavy.pl";'
timescaledb.max_background_workers = 8
timescaledb.last_tuned = '2019-07-14T16:06:04+03:00'
timescaledb.last_tuned_version = '0.6.0'
这显然不应该发生...
您能否更深入地描述您的 CSV 数据?您的 table 模式和 create_hypertable
调用是什么样的,您的数据是什么时间范围?默认情况下,我们每周创建一个时间戳块。您是否使用 create_hypertable
更改了该设置,或者您的数据覆盖了巨大的 time-range?
(例如,我们看到一位用户曾经不小心将数据库设置为每秒创建一个块,然后尝试了一个试图创建一百万个块的 COPY。数据库不是很高兴...)
:) 我有 Gentoo Linux,带有 postgresql 11.4 和 timescaledb-1.3.2。 我执行了 timescaledb-tune 来调整我的 postgresql 数据库配置。
我创建了一个包含大约 30 个字段的 table,我们称它为 foo。 我创建了另一个复制的 table,只是将其创建为 hypertable,我们称它为 h_foo.
我有一个 4gb 的 csv 文件,我尝试使用 COPY ... FROM ...
命令将其加载到数据库中
当我尝试将数据加载到常规 table 时,不到一分钟就完成了。
当我尝试将它加载到 hypertable 时,过了一会儿它抱怨共享内存不足并且需要很长时间才能到达错误点。
我认为开箱即用的 timescaledb(不知道高级配置)值得付出努力,但我不再确定了。
我将在下面粘贴我的 postgresql 配置文件,如果有任何我可以修改的地方,请告诉我谁能帮助我加载该 csv 文件。
谢谢
shared_buffers = 8009MB # min 128kB
work_mem = 6835kB # min 64kB
maintenance_work_mem = 2047MB # min 1MB
dynamic_shared_memory_type = posix # the default is the first option
effective_io_concurrency = 200 # 1-1000; 0 disables prefetching
max_worker_processes = 23 # (change requires restart)
max_parallel_workers_per_gather = 6 # taken from max_parallel_workers
max_parallel_workers = 12 # maximum number of max_worker_processes that
wal_buffers = 16MB # min 32kB, -1 sets based on shared_buffers
max_wal_size = 8GB
min_wal_size = 4GB
checkpoint_completion_target = 0.9 # checkpoint target duration, 0.0 - 1.0
random_page_cost = 1.1 # same scale as above
effective_cache_size = 24029MB
default_statistics_target = 500 # range 1-10000
log_timezone = 'Israel'
datestyle = 'iso, mdy'
timezone = 'Israel'
lc_messages = 'en_US.utf8' # locale for system error message
# strings
lc_monetary = 'en_US.utf8' # locale for monetary formatting
lc_numeric = 'en_US.utf8' # locale for number formatting
lc_time = 'en_US.utf8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'timescaledb'
max_locks_per_transaction = 256 # min 10
plperl.on_init = 'use utf8; use re; package utf8; require "utf8_heavy.pl";'
timescaledb.max_background_workers = 8
timescaledb.last_tuned = '2019-07-14T16:06:04+03:00'
timescaledb.last_tuned_version = '0.6.0'
这显然不应该发生...
您能否更深入地描述您的 CSV 数据?您的 table 模式和 create_hypertable
调用是什么样的,您的数据是什么时间范围?默认情况下,我们每周创建一个时间戳块。您是否使用 create_hypertable
更改了该设置,或者您的数据覆盖了巨大的 time-range?
(例如,我们看到一位用户曾经不小心将数据库设置为每秒创建一个块,然后尝试了一个试图创建一百万个块的 COPY。数据库不是很高兴...)