Добрый день!
До недавнего времени на сервере бд postgresql-9.3 была такая конфигурация: CPU-Intel(R) Xeon(R) E5504 @ 2.00GHz, DDR 64Gb, ОС debian 7.
Заменили на CPU- Intel(R) Xeon(R) X5650 @ 2.67GHz, DDR 98Gb, ос debian7. Дисковая подсистема осталась примерно на том же уровне.
В основном тест проходил на проекте, где большое количество селектов к таблицам по (10-15гб в среднем). После замены не почувствовали прирост производительности. Увеличил размер shared_buffers с 10Gb до 30Gb. Но опять ничего не почувствовали.
htop показывает, что занято всего 2-3Гб из 98...
Проверил след параметры системы:
cat /proc/sys/kernel/shmall
18446744073692774399
cat /proc/sys/kernel/shmmax
18446744073692774399
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
postgresql.conf
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 400 # (change requires restart)
#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------
# - Memory -
shared_buffers = 30GB # min 128kB
# (change requires restart)
temp_buffers = 128MB # min 800kB
#max_prepared_transactions = 0 # zero disables the feature
# (change requires restart)
# Note: Increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
# It is not advisable to set max_prepared_transactions nonzero unless you
# actively intend to use prepared transactions.
work_mem = 64MB # min 64kB
maintenance_work_mem = 8GB # min 1MB
max_stack_depth = 6MB # min 100kB
#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
wal_level = hot_standby # minimal, archive, or hot_standby
# (change requires restart)
fsync = on # 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_buffers = -1 # min 32kB, -1 sets based on shared_buffers
# (change requires restart)
#wal_writer_delay = 200ms # 1-10000 milliseconds
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000
# - Checkpoints -
checkpoint_segments = 128 # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 5min # range 30s-1h
checkpoint_completion_target = 0.8 # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s # 0 disables
Подскажите пожалуйста, почему такое происходит, почему такое потребление памяти?
