Die Situation Ich habe eine Postgresql 9.2-Datenbank, die die ganze Zeit ziemlich stark aktualisiert wird. Das System ist daher I / O-gebunden, und ich überlege derzeit, ein weiteres Upgrade durchzuführen. Ich benötige nur einige Anweisungen, um mit der Verbesserung zu beginnen.
Hier ist ein Bild davon, wie die Situation in den letzten 3 Monaten ausgesehen hat:
Wie Sie sehen können, entfällt der größte Teil der Festplattenauslastung auf Aktualisierungsvorgänge. Hier ist ein weiteres Bild davon, wie die Situation in einem detaillierten 3-Stunden-Fenster aussieht:
Wie Sie sehen können, liegt die maximale Schreibgeschwindigkeit bei 20 MB / s
Software
Auf dem Server wird Ubuntu 12.04 und Postgresql 9.2 ausgeführt. Die Art der Aktualisierungen wird normalerweise in einzelnen Zeilen, die durch die ID gekennzeichnet sind, geringfügig aktualisiert. Eg UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. Ich habe so viele Indizes entfernt und optimiert, wie ich für möglich halte, und die Serverkonfiguration (sowohl Linux-Kernel als auch postgres conf) ist auch ziemlich optimiert.
Hardware Bei der Hardware handelt es sich um einen dedizierten Server mit 32 GB ECC-RAM, 4x 600 GB SAS-Festplatten mit 15.000 U / min in einem RAID 10-Array, der von einem LSI-RAID-Controller mit BBU und einem Intel Xeon E3-1245 Quadcore-Prozessor gesteuert wird.
Fragen
- Ist die Leistung der Grafiken für ein System dieses Kalibers (Lesen / Schreiben) angemessen?
- Sollte ich mich daher auf ein Hardware-Upgrade konzentrieren oder die Software genauer untersuchen (Kernel-Optimierungen, Confs, Abfragen usw.)?
- Wenn Sie ein Hardware-Upgrade durchführen, ist die Anzahl der Festplatten der Schlüssel zur Leistung?
------------------------------AKTUALISIEREN------------------- ----------------
Ich habe jetzt meinen Datenbankserver mit vier Intel 520 SSDs anstelle der alten 15k SAS-Festplatten aktualisiert. Ich benutze den gleichen RAID-Controller. Die Dinge haben sich sehr verbessert, wie Sie aus den folgenden Abschnitten ersehen können: Die maximale E / A-Leistung hat sich um das 6- bis 10-fache verbessert - und das ist großartig !.
Ich erwartete jedoch eher eine 20- bis 50-fache Verbesserung in Bezug auf die Antworten und die E / A-Fähigkeiten der neuen SSDs. Also hier kommt eine andere Frage.
Neue Frage Befindet sich in meiner aktuellen Konfiguration etwas, das die E / A-Leistung meines Systems einschränkt (wo liegt der Engpass?).
Meine Konfigurationen:
/etc/postgresql/9.2/main/postgresql.conf
data_directory = '/var/lib/postgresql/9.2/main'
hba_file = '/etc/postgresql/9.2/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.2/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.2-main.pid'
listen_addresses = '192.168.0.4, localhost'
port = 5432
unix_socket_directory = '/var/run/postgresql'
wal_level = hot_standby
synchronous_commit = on
checkpoint_timeout = 10min
archive_mode = on
archive_command = 'rsync -a %p postgres@192.168.0.2:/var/lib/postgresql/9.2/wals/%f </dev/null'
max_wal_senders = 1
wal_keep_segments = 32
hot_standby = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 100
maintenance_work_mem = 1920MB
checkpoint_completion_target = 0.7
effective_cache_size = 22GB
work_mem = 160MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 7680MB
max_connections = 400 /etc/sysctl.conf
# sysctl config
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0
# Updated according to postgresql tuning
vm.dirty_ratio = 10
vm.dirty_background_ratio = 1
vm.swappiness = 0
vm.overcommit_memory = 2
kernel.sched_autogroup_enabled = 0
kernel.sched_migration_cost = 50000000/etc/sysctl.d/30-postgresql-shm.conf
# Shared memory settings for PostgreSQL
# Note that if another program uses shared memory as well, you will have to
# coordinate the size settings between the two.
# Maximum size of shared memory segment in bytes
#kernel.shmmax = 33554432
# Maximum total size of shared memory in pages (normally 4096 bytes)
#kernel.shmall = 2097152
kernel.shmmax = 8589934592
kernel.shmall = 17179869184
# Updated according to postgresql tuningAusgabe von MegaCli64 -LDInfo -LAll -aAll
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 446.125 GB
Sector Size : 512
Is VD emulated : No
Mirror Data : 446.125 GB
State : Optimal
Strip Size : 64 KB
Number Of Drives per span:2
Span Depth : 2
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
Is VD Cached: Nosynchronous_commit: "Asynchrones
synchronous_commit = off, nachdem Sie die Dokumente unter postgresql.org/docs/9.2/static/wal-async-commit.html gelesen haben . (3). Wie sieht Ihre Konfiguration aus? Z.B. ergebnisse dieserSELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');