【问题标题】:Postgresql doesn't use memory for cachingPostgresql 不使用内存进行缓存
【发布时间】:2014-05-27 16:46:53
【问题描述】:

我使用的服务器有 8GB 内存。我为 Postgresql 设置了适当的 Effective_cache_size 和 shared_buffers 配置参数。这是show all;的查询结果:

allow_system_table_mods off
application_name    
archive_command (disabled)
archive_mode    off
archive_timeout 0
array_nulls on
authentication_timeout  1min
autovacuum  on
autovacuum_analyze_scale_factor 0.1
autovacuum_analyze_threshold    50
autovacuum_freeze_max_age   200000000
autovacuum_max_workers  3
autovacuum_naptime  1min
autovacuum_vacuum_cost_delay    20ms
autovacuum_vacuum_cost_limit    -1
autovacuum_vacuum_scale_factor  0.2
autovacuum_vacuum_threshold 50
backslash_quote safe_encoding
bgwriter_delay  200ms
bgwriter_lru_maxpages   100
bgwriter_lru_multiplier 2
block_size  8192
bonjour off
bonjour_name    
bytea_output    hex
check_function_bodies   on
checkpoint_completion_target    0.5
checkpoint_segments 3
checkpoint_timeout  5min
checkpoint_warning  30s
client_encoding UTF8
client_min_messages notice
commit_delay    0
commit_siblings 5
config_file /etc/postgresql/9.1/main/postgresql.conf
constraint_exclusion    partition
cpu_index_tuple_cost    0.005
cpu_operator_cost   0.0025
cpu_tuple_cost  0.01
cursor_tuple_fraction   0.1
custom_variable_classes 
data_directory  /var/lib/postgresql/9.1/main
DateStyle   ISO, MDY
db_user_namespace   off
deadlock_timeout    1s
debug_assertions    off
debug_pretty_print  on
debug_print_parse   off
debug_print_plan    off
debug_print_rewritten   off
default_statistics_target   100
default_tablespace  
default_text_search_config  pg_catalog.english
default_transaction_deferrable  off
default_transaction_isolation   read committed
default_transaction_read_only   off
default_with_oids   off
dynamic_library_path    $libdir
effective_cache_size    6GB
effective_io_concurrency    1
enable_bitmapscan   on
enable_hashagg  on
enable_hashjoin on
enable_indexscan    on
enable_material on
enable_mergejoin    on
enable_nestloop on
enable_seqscan  on
enable_sort on
enable_tidscan  on
escape_string_warning   on
exit_on_error   off
external_pid_file   /var/run/postgresql/9.1-main.pid
extra_float_digits  0
from_collapse_limit 8
fsync   on
full_page_writes    on
geqo    on
geqo_effort 5
geqo_generations    0
geqo_pool_size  0
geqo_seed   0
geqo_selection_bias 2
geqo_threshold  12
gin_fuzzy_search_limit  0
hba_file    /etc/postgresql/9.1/main/pg_hba.conf
hot_standby off
hot_standby_feedback    off
ident_file  /etc/postgresql/9.1/main/pg_ident.conf
ignore_system_indexes   off
integer_datetimes   on
IntervalStyle   postgres
join_collapse_limit 8
krb_caseins_users   off
krb_server_keyfile  FILE:/etc/postgresql-common/krb5.keytab
krb_srvname postgres
lc_collate  en_US.UTF-8
lc_ctype    en_US.UTF-8
lc_messages en_US.UTF-8
lc_monetary en_US.UTF-8
lc_numeric  en_US.UTF-8
lc_time en_US.UTF-8
listen_addresses    *
lo_compat_privileges    off
local_preload_libraries 
log_autovacuum_min_duration -1
log_checkpoints off
log_connections off
log_destination csvlog
log_directory   pg_log
log_disconnections  off
log_duration    off
log_error_verbosity default
log_executor_stats  off
log_file_mode   0600
log_filename    postgresql-%Y-%m-%d_%H%M%S.log
log_hostname    off
log_line_prefix %t 
log_lock_waits  off
log_min_duration_statement  2s
log_min_error_statement error
log_min_messages    warning
log_parser_stats    off
log_planner_stats   off
log_rotation_age    1d
log_rotation_size   10MB
log_statement   none
log_statement_stats off
log_temp_files  -1
log_timezone    Turkey
log_truncate_on_rotation    off
logging_collector   on
maintenance_work_mem    16MB
max_connections 100
max_files_per_process   1000
max_function_args   100
max_identifier_length   63
max_index_keys  32
max_locks_per_transaction   64
max_pred_locks_per_transaction  64
max_prepared_transactions   0
max_stack_depth 2MB
max_standby_archive_delay   30s
max_standby_streaming_delay 30s
max_wal_senders 0
password_encryption on
port    5432
post_auth_delay 0
pre_auth_delay  0
quote_all_identifiers   off
random_page_cost    4
replication_timeout 1min
restart_after_crash on
search_path public, "$user", public
segment_size    1GB
seq_page_cost   1
server_encoding UTF8
server_version  9.1.13
server_version_num  90113
session_replication_role    origin
shared_buffers  2GB
shared_preload_libraries    
silent_mode off
sql_inheritance on
ssl on
ssl_ciphers ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH
ssl_renegotiation_limit 512MB
standard_conforming_strings on
statement_timeout   0
stats_temp_directory    pg_stat_tmp
superuser_reserved_connections  3
synchronize_seqscans    on
synchronous_commit  on
synchronous_standby_names   
syslog_facility local0
syslog_ident    postgres
tcp_keepalives_count    9
tcp_keepalives_idle 7200
tcp_keepalives_interval 75
temp_buffers    8MB
temp_tablespaces    
TimeZone    Turkey
timezone_abbreviations  Default
trace_notify    off
trace_recovery_messages log
trace_sort  off
track_activities    on
track_activity_query_size   1024
track_counts    on
track_functions none
transaction_deferrable  off
transaction_isolation   read committed
transaction_read_only   off
transform_null_equals   off
unix_socket_directory   /var/run/postgresql
unix_socket_group   
unix_socket_permissions 0777
update_process_title    on
vacuum_cost_delay   0
vacuum_cost_limit   200
vacuum_cost_page_dirty  20
vacuum_cost_page_hit    1
vacuum_cost_page_miss   10
vacuum_defer_cleanup_age    0
vacuum_freeze_min_age   50000000
vacuum_freeze_table_age 150000000
wal_block_size  8192
wal_buffers 16MB
wal_keep_segments   0
wal_level   minimal
wal_receiver_status_interval    10s
wal_segment_size    16MB
wal_sender_delay    1s
wal_sync_method fdatasync
wal_writer_delay    200ms
work_mem    16MB
xmlbinary   base64
xmloption   content
zero_damaged_pages  off

我使用 Postgresql 作为网站的后端数据库。我在网站上进行了压力测试,因此它在 Postgresql 上执行各种查询。我监视系统并看到 Postgresql 为使用一些内存的选择查询创建新进程,返回数据并杀死自己。 Postgresql 主进程使用 2GB 虚拟内存(shared_buffers),但据我所知,内存中没有用于缓存的持久数据。它一直使用大约 78mb。我知道 Postgresql 大量使用操作系统缓存,但top 表明内存使用量总体上非常低。

这是一个问题还是我错过了什么?

【问题讨论】:

  • 不,这是正常的。 effective_cache_size 尝试提示 PG 操作系统尝试维护的磁盘缓冲量。 (虽然您的 shared_buffers+effective_cache_size 相当高,但它应该 小于 总可用内存)请监控 IOstat/vmstat 以查看是否发生交换。如果是这样:将设置降低到 1GB+4GB 左右。将 random_page_cost 设置为较低的值将有助于大查询 + 网盘

标签: sql postgresql postgresql-9.1


【解决方案1】:

如果您在谈论RES 列,则任何后端进程都只会因其实际接触的内存而被归因,如果每个后端进程只存在于单个事务或查询的持续时间内,那么它可能只接触到很小的一部分在其生命周期内的内存量。 top 不会将 OS 缓存归因于单个进程,因此通过该工具无法看到 OS 缓存的高使用率。 vmtouch 这样做会更好。但一般来说,如果 %wa 时间很短,那么缓存必须按照它需要的那样运行。

至于是否有问题,只有你自己才知道——你跑了压力测试。效果如何?

【讨论】:

  • 当我运行相同的查询几次但所有查询的响应时间几乎相同时,我期待着改进。我试过vmtouch,数据目录的大小是1gb,但根据vmtouch,内存中只有50mb。我尝试了 -vt 参数,以便将 postgresql 中的所有数据加载到内存中,vmtouch 成功加载了数据,但同样查询的响应时间相同。
  • 顺便说一句,平均响应时间为 3 秒。选择查询使用 100% cpu 3 秒并返回响应。如果你想看的话,这里是解释分析:explain.depesz.com/s/3VBS
  • 如果数据已经被缓存,重复运行相同的查询预计不会带来改进。如果您运行 vmtouch -vt,然后稍后运行 vmtouch -v,它是否发现数据仍在内存中?什么是%wa?从 EXPLAIN 看来,您的查询似乎是 CPU 密集型的,而缓存与它无关;但是如果不查看查询本身,就很难明确地说出来。此外,使用 track_io_timing=on 解释(分析、缓冲)会有很大帮助。
  • 我再次测试了 vmtouch -v 并且 100% 的数据目录在内存中。是的,这就是我所考虑的瓶颈,但 Postgresql 不缓存连接和分组操作吗?我执行的查询中最昂贵的操作是按部分分组。这是一个方面查询示例:pastebin.com/tSBqPx49 数据集部分是动态的,但在这个特定的示例查询中,我没有对产品进行任何过滤。此查询中最昂贵的部分是最后一个联合,尤其是“vehicle_grup_id”表,因为该表有大约 1m 行...
  • ..track_io_timing 似乎适用于 9.2,所以我在我的计算机上执行了这个解释分析,因为服务器中的版本是 9.1:explain.depesz.com/s/p1kD@jjanes
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-03-12
  • 2014-10-21
  • 2019-03-11
  • 1970-01-01
  • 2012-12-19
  • 2017-02-25
  • 2015-04-04
相关资源
最近更新 更多