[Gelöst] PostgreSQL - Konfig oder Anwendungfehler?

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

[Gelöst] PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von ObiTobi » 07.01.2023 22:50:03

Hallo,

Ich muss zugeben wirklich Plan wie ich mein Problem in den Griff bekommen kann habe ich nicht.Vielleicht ist meine Konfiguration schlicht “totaler Blödsinn” oder die Anwendung die ich nutze macht Mist.

In Kurzfassung - meine Anwendung die ich nutzen will heißt “Photo Supreme”. Es ist eine Bildverwaltung. Wenn die Anwendung viele Dateien aktualisieren will - sagen wir mehr als 20000 ist es sicher, dass der Server es nicht überlebt und irgendwann wegen “out of memory” alles hinschmeißt.

Mein Server hat 48GB RAM, 8 CPU Kerne und läuft virtuell auf einem Linux Debian KVM Server.

Stelle ich in der Konfiguration Anzahl der max Verbindungen auf 50, so macht die Anwendung Ärger und kommt immer wieder mit "FATAL: tut mir leid schon zu viele Verbindungen"
Setze ich die Verbindungen auf 70, sieht man in top oder pg_top dass Speicher komplett alle ist und dann crasht das ganze.

Momentan sehen die wichtigste Konfigeinträge so aus

Code: Alles auswählen

max_connections = 100
shared_buffers = 64MB
temp_buffers = 1GB
work_mem = 64MB
maintenance_work_mem = 1GB
max_wal_size = 3GB
effective_cache_size = 24GB
dynamic_shared_memory_type = posix
Mir kommt es so vor, dass aus welchem Grund auch immer der Server mit der Zeit mehr Speicher benutzen will als überhaupt vorhanden und dann kommt es zu dem Crash.
Zuletzt geändert von ObiTobi am 23.01.2023 21:00:22, insgesamt 1-mal geändert.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von Blackbox » 11.01.2023 19:40:13

Ausführungsfehler, oder Auffälligkeiten im Logfile?
Mit derart wenig Informationen kann dir nicht geholfen werden!
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von ObiTobi » 13.01.2023 10:50:54

Blackbox hat geschrieben: ↑ zum Beitrag ↑
11.01.2023 19:40:13
Ausführungsfehler, oder Auffälligkeiten im Logfile?
Na wenn ich schreibe "Server hinschmeißt, weil kein Speicher mehr", dann wird es kaum mit Auffälligkeiten im Logfile zu tun haben
Blackbox hat geschrieben: ↑ zum Beitrag ↑
11.01.2023 19:40:13
Mit derart wenig Informationen kann dir nicht geholfen werden!
Und welche hättest Du gerne?
Wobei das hat sich vermutlich erst mal erledigt. Durch Hilfe in PostgreSQL Forum ist rausgekommen, zumindest Stand jetzt, dass mein Problem in der Anwendung und nicht in den Einstellungen zu suchen ist. In der Anwendung werden Trigger benutzt die sich einfach mehr und mehr Speicher nehmen. So lange die Anwendung läuft und eben die Bilddaten in die Datenbank schreibt.

Benutzeravatar
heisenberg
Beiträge: 3548
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von heisenberg » 13.01.2023 12:33:05

  1. Bitte mal die exakten Fehlermeldungen posten.
  2. Ich empfehle die Dokumentation mit den entsprechenden Konfigurationseinstellungen für den Speicherbedarf von PostgreSQL durchzuarbeiten.
  3. Als erstes fällt mir auf, dass Du shared_buffers auf 64MB stehen hast. In der Doku steht da u. a. folgendes dazu:
    If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system.
    D. h. bei Dir wäre der empfohlene Wert da nicht 64MB sondern 12 GB.
Nachtrag:

Hast Du ein Monitoring für das System am laufen? Wenn nicht, kannst Du mal zumindest ...

Code: Alles auswählen

dstat --mem --disk --swap --cpu 
mitlaufen lassen um zu schauen, ob da tatsächlich der Speicher vom System knapp wird, oder ob das nur der für PGSQL zugewiesene Speicher ist.
Jede Rohheit hat ihren Ursprung in einer Schwäche.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von Blackbox » 13.01.2023 14:59:35

ObiTobi hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 10:50:54
Und welche hättest Du gerne?dass mein Problem in der Anwendung und nicht in den Einstellungen zu suchen ist.
Sollte wirklich nichts im Logfile zu finden sein - was ich bezweifele - Loglevel erhöhen, und in

Code: Alles auswählen

/var/log/postgresql
nachschauen.
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 10:50:54
In der Anwendung werden Trigger benutzt die sich einfach mehr und mehr Speicher nehmen.
Und genau dafür gibt es Gründe. Siehe Logfile.
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 10:50:54
So lange die Anwendung läuft und eben die Bilddaten in die Datenbank schreibt.
Dass Bilddaten in einer Datenbank landen, ist kein exotisches Anwendungsszenario.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von ObiTobi » 14.01.2023 20:01:38

Nun, zunächst - tut mir leid, dass ich die Konfiguration die ich hier angegeben hatte nicht mehr später mit der aktueller aktualisiert habe. Es ist für mich doch stochern im dunkeln
Heißt auf Grund von verschiedenen Seiten habe ich versuchet diverse Parameter zu verändern. Auch wenn ich weiß was ggf. gleich für Sprüche kommen werden - nicht immer habe ich die Änderungen durchgeführt und und verstanden warum.

Auf Grund der Änderungen kamen selbstverständlich auch Fehlermeldungen. Die wohl Sinnvollsten im syslog wie das hier

Code: Alles auswählen

Jan  9 14:22:21 xenpsql001 kernel: [ 8288.582783] postgres invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582785] CPU: 3 PID: 3306 Comm: postgres Not tainted 5.10.0-19-amd64 #1 Debian 5.10.149-2
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582786] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582787] Call Trace:
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582797]  dump_stack+0x6b/0x83
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582799]  dump_header+0x4a/0x1f4
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582800]  oom_kill_process.cold+0xb/0x10
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582802]  out_of_memory+0x1bd/0x4e0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582804]  __alloc_pages_slowpath.constprop.0+0xbcc/0xc90
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582805]  __alloc_pages_nodemask+0x2de/0x310
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582806]  pagecache_get_page+0x175/0x390
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582807]  filemap_fault+0x6a2/0x900
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582816]  ext4_filemap_fault+0x2d/0x50 [ext4]
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582819]  __do_fault+0x37/0x170
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582820]  handle_mm_fault+0x1208/0x1c10
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582822]  do_user_addr_fault+0x1b8/0x400
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582824]  ? switch_fpu_return+0x44/0xc0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582826]  exc_page_fault+0x78/0x160
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582827]  ? asm_exc_page_fault+0x8/0x30
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582828]  asm_exc_page_fault+0x1e/0x30
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582830] RIP: 0033:0x55b840b676e0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582833] Code: Unable to access opcode bytes at RIP 0x55b840b676b6.
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582833] RSP: 002b:00007fff6dc1a708 EFLAGS: 00010246
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582834] RAX: 0000000000000000 RBX: 000055b8414b43a8 RCX: 0000000020000000
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582835] RDX: 000055b840f78c50 RSI: 00007fff6dc1a76c RDI: 000055b84148fe08
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582835] RBP: 00007fff6dc1a7e0 R08: 000055b840f78c60 R09: 0000000000000000
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582836] R10: 0000000000000008 R11: 0000000000000038 R12: 0000000000000000
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582836] R13: 0000000043794f88 R14: 00007f3fb7923600 R15: 00007fff6dc1a770
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582837] Mem-Info:
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582839] active_anon:4985288 inactive_anon:6960647 isolated_anon:0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582839]  active_file:12 inactive_file:0 isolated_file:0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582839]  unevictable:0 dirty:3 writeback:0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582839]  slab_reclaimable:59458 slab_unreclaimable:10543
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582839]  mapped:3203056 shmem:3203728 pagetables:234879 bounce:0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582839]  free:70635 free_pcp:986 free_cma:0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582841] Node 0 active_anon:19941152kB inactive_anon:27842588kB active_file:48kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:12812224kB dirty:12kB writeback:0kB shmem:12814912kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 2217984kB writeback_tmp:0kB kernel_stack:3616kB all_unreclaimable? no
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582841] Node 0 DMA free:15908kB min:20kB low:32kB high:44kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582843] lowmem_reserve[]: 0 1940 48143 48143 48143
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582844] Node 0 DMA32 free:187484kB min:2720kB low:4704kB high:6688kB reserved_highatomic:0KB active_anon:746896kB inactive_anon:1045428kB active_file:16kB inactive_file:84kB unevictable:0kB writepending:0kB present:2080624kB managed:2015088kB mlocked:0kB pagetables:30652kB bounce:0kB free_pcp:32kB local_pcp:4kB free_cma:0kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582846] lowmem_reserve[]: 0 0 46203 46203 46203
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582847] Node 0 Normal free:79148kB min:79172kB low:126484kB high:173796kB reserved_highatomic:0KB active_anon:19194256kB inactive_anon:26797160kB active_file:20kB inactive_file:164kB unevictable:0kB writepending:12kB present:48234496kB managed:47317716kB mlocked:0kB pagetables:908864kB bounce:0kB free_pcp:3912kB local_pcp:1160kB free_cma:0kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582849] lowmem_reserve[]: 0 0 0 0 0
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582850] Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15908kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582855] Node 0 DMA32: 335*4kB (UME) 1603*8kB (UME) 2618*16kB (UME) 1335*32kB (UME) 755*64kB (UME) 142*128kB (UME) 54*256kB (UME) 13*512kB (UME) 2*1024kB (UM) 0*2048kB 0*4096kB = 187796kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582859] Node 0 Normal: 2146*4kB (UME) 1269*8kB (UME) 2255*16kB (UME) 610*32kB (UME) 71*64kB (UME) 4*128kB (M) 1*256kB (M) 1*512kB (M) 0*1024kB 0*2048kB 0*4096kB = 80160kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582864] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582864] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jan  9 14:22:22 xenpsql001 kernel: [ 8288.582865] 3223230 total pagecache pages
Im postgreSQL steht dann meistens (um nicht zu sagen immer "nur" so etwas wie:

Code: Alles auswählen

2023-01-08 01:59:19.845 CET [2548] idimager_main@moments of time FATAL:  Verbindung wird abgebrochen aufgrund von Anweisung des Administrators
Meine aktuelle Konfiguration sieht an vielen Stellen ganz anders als die oben angegebene. Leider an dem Verhalten hat sich nichts (so nach außen) verändert.
Die sieht dann wie folgt aus:

Code: Alles auswählen

# -----------------------------
# PostgreSQL configuration file
# -----------------------------
#
# This file consists of lines of the form:
#
#   name = value
#
# (The "=" is optional.)  Whitespace may be used.  Comments are introduced with
# "#" anywhere on a line.  The complete list of parameter names and allowed
# values can be found in the PostgreSQL documentation.
#
# The commented-out settings shown in this file represent the default values.
# Re-commenting a setting is NOT sufficient to revert it to the default value;
# you need to reload the server.
#
# This file is read on server startup and when the server receives a SIGHUP
# signal.  If you edit the file on a running system, you have to SIGHUP the
# server for the changes to take effect, run "pg_ctl reload", or execute
# "SELECT pg_reload_conf()".  Some parameters, which are marked below,
# require a server shutdown and restart to take effect.
#
# Any parameter can also be given as a command-line option to the server, e.g.,
# "postgres -c log_connections=on".  Some parameters can be changed at run time
# with the "SET" SQL command.
#
# Memory units:  kB = kilobytes        Time units:  ms  = milliseconds
#                MB = megabytes                     s   = seconds
#                GB = gigabytes                     min = minutes
#                TB = terabytes                     h   = hours
#                                                   d   = days


#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------

# The default values of these variables are driven from the -D command-line
# option or PGDATA environment variable, represented here as ConfigDir.

data_directory = '/var/lib/postgresql/14/main'		# use data in another directory
					# (change requires restart)
hba_file = '/etc/postgresql/14/main/pg_hba.conf'	# host-based authentication file
					# (change requires restart)
ident_file = '/etc/postgresql/14/main/pg_ident.conf'	# ident configuration file
					# (change requires restart)

# If external_pid_file is not explicitly set, no extra PID file is written.
external_pid_file = '/var/run/postgresql/14-main.pid'			# write an extra PID file
					# (change requires restart)


#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

# - Connection Settings -

listen_addresses = 'localhost,xenpsql001.rjap.de'		# 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 = 150			# (change requires restart)
#superuser_reserved_connections = 3	# (change requires restart)
unix_socket_directories = '/var/run/postgresql'	# comma-separated list of directories
					# (change requires restart)
#unix_socket_group = ''			# (change requires restart)
#unix_socket_permissions = 0777		# begin with 0 to use octal notation
					# (change requires restart)
#bonjour = off				# advertise server via Bonjour
					# (change requires restart)
#bonjour_name = ''			# defaults to the computer name
					# (change requires restart)

# - Security and Authentication -

#authentication_timeout = 1min		# 1s-600s
ssl = on
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
#ssl_prefer_server_ciphers = on
#ssl_ecdh_curve = 'prime256v1'
#ssl_dh_params_file = ''
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
#ssl_ca_file = ''
#ssl_crl_file = ''
#password_encryption = md5		# md5 or scram-sha-256
#db_user_namespace = off
#row_security = on

# GSSAPI using Kerberos
#krb_server_keyfile = ''
#krb_caseins_users = off

# - TCP Keepalives -
# see "man 7 tcp" for details

#tcp_keepalives_idle = 0		# TCP_KEEPIDLE, in seconds;
					# 0 selects the system default
#tcp_keepalives_interval = 0		# TCP_KEEPINTVL, in seconds;
					# 0 selects the system default
#tcp_keepalives_count = 0		# TCP_KEEPCNT;
					# 0 selects the system default


#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------

# - Memory -

shared_buffers = 8GB			# min 128kB
					# (change requires restart)
#huge_pages = try			# on, off, or try
					# (change requires restart)
temp_buffers = 8MB			# min 800kB
###temp_buffers = 1GB			# min 800kB
#max_prepared_transactions = 0		# 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 = 48MB				# min 64kB
maintenance_work_mem = 4GB		# min 1MB
#replacement_sort_tuples = 150000	# limits use of replacement selection sort
#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
					# (change requires restart)

# - Disk -

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

# - Kernel Resource Usage -

#max_files_per_process = 1000		# min 25
### max_files_per_process = 100		# 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 multiplier on buffers scanned/round
#bgwriter_flush_after = 512kB		# measured in pages, 0 disables

# - Asynchronous Behavior -

#effective_io_concurrency = 1		# 1-1000; 0 disables prefetching
#max_worker_processes = 8		# (change requires restart)
#max_parallel_workers_per_gather = 2	# taken from max_parallel_workers
#max_parallel_workers = 8		# maximum number of max_worker_processes that
					# can be used in parallel queries
#old_snapshot_threshold = -1		# 1min-60d; -1 disables; 0 is immediate
					# (change requires restart)
#backend_flush_after = 0		# measured in pages, 0 disables


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

# - Settings -

#wal_level = replica			# minimal, replica, or logical
					# (change requires restart)
#fsync = on				# flush data to disk for crash safety
					# (turning this off can cause
					# unrecoverable data corruption)
#synchronous_commit = on		# synchronization level;
					# off, local, remote_write, remote_apply, 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 = 360MB			# min 32kB, -1 sets based on shared_buffers
					# (change requires restart)
#wal_writer_delay = 200ms		# 1-10000 milliseconds
#wal_writer_flush_after = 1MB		# measured in pages, 0 disables

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

# - Checkpoints -

# checkpoint_timeout = 5min		# range 30s-1d
checkpoint_timeout = 45min		# range 30s-1d
max_wal_size = 3GB
min_wal_size = 1500MB
#checkpoint_completion_target = 0.5	# checkpoint target duration, 0.0 - 1.0
#checkpoint_flush_after = 256kB		# measured in pages, 0 disables
#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


#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------

# - Sending Server(s) -

# Set these on the master and on any standby that will send replication data.

#max_wal_senders = 10		# max number of walsender processes
				# (change requires restart)
#wal_keep_segments = 0		# in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s	# in milliseconds; 0 disables

#max_replication_slots = 10	# max number of replication slots
				# (change requires restart)
#track_commit_timestamp = off	# collect timestamp of transaction commit
				# (change requires restart)

# - Master Server -

# These settings are ignored on a standby server.

#synchronous_standby_names = ''	# standby servers that provide sync rep
				# method to choose sync standbys, number of sync standbys,
				# and comma-separated list of application_name
				# from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0	# number of xacts by which cleanup is delayed

# - Standby Servers -

# These settings are ignored on a master server.

#hot_standby = on			# "off" disallows queries during recovery
					# (change requires restart)
#max_standby_archive_delay = 30s	# max delay before canceling queries
					# when reading WAL from archive;
					# -1 allows indefinite delay
#max_standby_streaming_delay = 30s	# max delay before canceling queries
					# when reading streaming WAL;
					# -1 allows indefinite delay
#wal_receiver_status_interval = 10s	# send replies at least this often
					# 0 disables
#hot_standby_feedback = off		# send info from standby to prevent
					# query conflicts
#wal_receiver_timeout = 60s		# time that receiver waits for
					# communication from master
					# in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s	# time to wait before retrying to
					# retrieve WAL after a failed attempt

# - Subscribers -

# These settings are ignored on a publisher.

#max_logical_replication_workers = 4	# taken from max_worker_processes
					# (change requires restart)
#max_sync_workers_per_subscription = 2	# taken from max_logical_replication_workers


#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------

# - Planner Method Configuration -

#enable_bitmapscan = on
#enable_hashagg = on
#enable_hashjoin = on
#enable_indexscan = on
#enable_indexonlyscan = on
#enable_material = on
#enable_mergejoin = on
#enable_nestloop = on
#enable_seqscan = on
#enable_sort = on
#enable_tidscan = on

# - Planner Cost Constants -

#seq_page_cost = 1.0			# measured on an arbitrary scale
#random_page_cost = 4.0			# same scale as above
cpu_tuple_cost = 0.03			# same scale as above
#cpu_index_tuple_cost = 0.005		# same scale as above
#cpu_operator_cost = 0.0025		# same scale as above
#parallel_tuple_cost = 0.1		# same scale as above
#parallel_setup_cost = 1000.0	# same scale as above
#min_parallel_table_scan_size = 8MB
#min_parallel_index_scan_size = 512kB
effective_cache_size = 24GB

# - Genetic Query Optimizer -

#geqo = on
#geqo_threshold = 12
#geqo_effort = 5			# range 1-10
#geqo_pool_size = 0			# selects default based on effort
#geqo_generations = 0			# selects default based on effort
#geqo_selection_bias = 2.0		# range 1.5-2.0
#geqo_seed = 0.0			# range 0.0-1.0

# - Other Planner Options -

#default_statistics_target = 100	# range 1-10000
#constraint_exclusion = partition	# on, off, or partition
#cursor_tuple_fraction = 0.1		# range 0.0-1.0
#from_collapse_limit = 8
#join_collapse_limit = 8		# 1 disables collapsing of explicit
					# JOIN clauses
#force_parallel_mode = off


#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------

# - Where to Log -

#log_destination = 'stderr'		# Valid values are combinations of
					# stderr, csvlog, syslog, and eventlog,
					# depending on platform.  csvlog
					# requires logging_collector to be on.

# This is used when logging to stderr:
#logging_collector = off		# Enable capturing of stderr and csvlog
					# into log files. Required to be on for
					# csvlogs.
					# (change requires restart)

# These are only used if logging_collector is on:
#log_directory = 'log'			# directory where log files are written,
					# can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'	# log file name pattern,
					# can include strftime() escapes
#log_file_mode = 0600			# creation mode for log files,
					# begin with 0 to use octal notation
#log_truncate_on_rotation = off		# If on, an existing log file with the
					# same name as the new log file will be
					# truncated rather than appended to.
					# But such truncation only occurs on
					# time-driven rotation, not on restarts
					# or size-driven rotation.  Default is
					# off, meaning append to existing files
					# in all cases.
#log_rotation_age = 1d			# Automatic rotation of logfiles will
					# happen after that time.  0 disables.
#log_rotation_size = 10MB		# Automatic rotation of logfiles will
					# happen after that much log output.
					# 0 disables.

# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'
#syslog_sequence_numbers = on
#syslog_split_messages = on

# This is only relevant when logging to eventlog (win32):
# (change requires restart)
#event_source = 'PostgreSQL'

# - When to Log -

#client_min_messages = notice		# values in order of decreasing detail:
					#   debug5
					#   debug4
					#   debug3
					#   debug2
					#   debug1
					#   log
					#   notice
					#   warning
					#   error

#log_min_messages = warning		# values in order of decreasing detail:
					#   debug5
					#   debug4
					#   debug3
					#   debug2
					#   debug1
					#   info
					#   notice
					#   warning
					#   error
					#   log
					#   fatal
					#   panic

#log_min_error_statement = error	# values in order of decreasing detail:
					#   debug5
					#   debug4
					#   debug3
					#   debug2
					#   debug1
					#   info
					#   notice
					#   warning
					#   error
					#   log
					#   fatal
					#   panic (effectively off)

#log_min_duration_statement = -1	# -1 is disabled, 0 logs all statements
					# and their durations, > 0 logs only
					# statements running at least this number
					# of milliseconds


# - What to Log -

#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = on
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
#log_error_verbosity = default		# terse, default, or verbose messages
#log_hostname = off
log_line_prefix = '%m [%p] %q%u@%d '		# special values:
					#   %a = application name
					#   %u = user name
					#   %d = database name
					#   %r = remote host and port
					#   %h = remote host
					#   %p = process ID
					#   %t = timestamp without milliseconds
					#   %m = timestamp with milliseconds
					#   %n = timestamp with milliseconds (as a Unix epoch)
					#   %i = command tag
					#   %e = SQL state
					#   %c = session ID
					#   %l = session line number
					#   %s = session start timestamp
					#   %v = virtual transaction ID
					#   %x = transaction ID (0 if none)
					#   %q = stop here in non-session
					#        processes
					#   %% = '%'
					# e.g. '<%u%%%d> '
#log_lock_waits = off			# log lock waits >= deadlock_timeout
#log_statement = 'none'			# none, ddl, mod, all
#log_replication_commands = off
#log_temp_files = -1			# log temporary files equal or larger
					# than the specified size in kilobytes;
					# -1 disables, 0 logs all temp files
log_timezone = 'localtime'


# - Process Title -

cluster_name = '14/main'		# added to process titles if nonempty
					# (change requires restart)
#update_process_title = on


#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

#track_activities = on
#track_counts = on
#track_io_timing = off
#track_functions = none			# none, pl, all
#track_activity_query_size = 1024	# (change requires restart)
stats_temp_directory = '/var/run/postgresql/14-main.pg_stat_tmp'


# - Statistics Monitoring -

#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
#log_statement_stats = off


#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------

autovacuum = no 	 		# Enable autovacuum subprocess?  'on'
					# requires track_counts to also be on.
#log_autovacuum_min_duration = -1	# -1 disables, 0 logs all actions and
					# their durations, > 0 logs only
					# actions running at least this number
					# of milliseconds.
#autovacuum_max_workers = 3		# max number of autovacuum subprocesses
					# (change requires restart)
#autovacuum_naptime = 1min		# time between autovacuum runs
#autovacuum_vacuum_threshold = 50	# min number of row updates before
					# vacuum
#autovacuum_analyze_threshold = 50	# min number of row updates before
					# analyze
#autovacuum_vacuum_scale_factor = 0.2	# fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1	# fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000	# maximum XID age before forced vacuum
					# (change requires restart)
#autovacuum_multixact_freeze_max_age = 400000000	# maximum multixact age
					# before forced vacuum
					# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms	# default vacuum cost delay for
					# autovacuum, in milliseconds;
					# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1	# default vacuum cost limit for
					# autovacuum, -1 means use
					# vacuum_cost_limit


#------------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#------------------------------------------------------------------------------

# - Statement Behavior -

#search_path = '"$user", public'	# schema names
#default_tablespace = ''		# a tablespace name, '' uses the default
#temp_tablespaces = ''			# a list of tablespace names, '' uses
					# only default tablespace
#check_function_bodies = on
#default_transaction_isolation = 'read committed'
#default_transaction_read_only = off
#default_transaction_deferrable = off
#session_replication_role = 'origin'
#statement_timeout = 0			# in milliseconds, 0 is disabled
#lock_timeout = 0			# in milliseconds, 0 is disabled
#idle_in_transaction_session_timeout = 0	# in milliseconds, 0 is disabled
#vacuum_freeze_min_age = 50000000
#vacuum_freeze_table_age = 150000000
#vacuum_multixact_freeze_min_age = 5000000
#vacuum_multixact_freeze_table_age = 150000000
#bytea_output = 'hex'			# hex, escape
#xmlbinary = 'base64'
#xmloption = 'content'
#gin_fuzzy_search_limit = 0
#gin_pending_list_limit = 4MB

# - Locale and Formatting -

datestyle = 'iso, dmy'
#intervalstyle = 'postgres'
timezone = 'localtime'
#timezone_abbreviations = 'Default'     # Select the set of available time zone
					# abbreviations.  Currently, there are
					#   Default
					#   Australia (historical usage)
					#   India
					# You can create your own file in
					# share/timezonesets/.
#extra_float_digits = 0			# min -15, max 3
#client_encoding = sql_ascii		# actually, defaults to database
					# encoding

# These settings are initialized by initdb, but they can be changed.
lc_messages = 'de_DE.UTF-8'			# locale for system error message
					# strings
lc_monetary = 'de_DE.UTF-8'			# locale for monetary formatting
lc_numeric = 'de_DE.UTF-8'			# locale for number formatting
lc_time = 'de_DE.UTF-8'				# locale for time formatting

# default configuration for text search
default_text_search_config = 'pg_catalog.german'

# - Other Defaults -

#dynamic_library_path = '$libdir'
#local_preload_libraries = ''
#session_preload_libraries = ''


#------------------------------------------------------------------------------
# LOCK MANAGEMENT
#------------------------------------------------------------------------------

#deadlock_timeout = 1s
#max_locks_per_transaction = 64		# min 10
					# (change requires restart)
#max_pred_locks_per_transaction = 64	# min 10
					# (change requires restart)
#max_pred_locks_per_relation = -2	# negative values mean
					# (max_pred_locks_per_transaction
					#  / -max_pred_locks_per_relation) - 1
#max_pred_locks_per_page = 2            # min 0


#------------------------------------------------------------------------------
# VERSION/PLATFORM COMPATIBILITY
#------------------------------------------------------------------------------

# - Previous PostgreSQL Versions -

#array_nulls = on
#backslash_quote = safe_encoding	# on, off, or safe_encoding
#default_with_oids = off
#escape_string_warning = on
#lo_compat_privileges = off
#operator_precedence_warning = off
#quote_all_identifiers = off
#standard_conforming_strings = on
#synchronize_seqscans = on

# - Other Platforms and Clients -

#transform_null_equals = off


#------------------------------------------------------------------------------
# ERROR HANDLING
#------------------------------------------------------------------------------

#exit_on_error = off			# terminate session on any error?
#restart_after_crash = on		# reinitialize after backend crash?


#------------------------------------------------------------------------------
# CONFIG FILE INCLUDES
#------------------------------------------------------------------------------

# These options allow settings to be loaded from files other than the
# default postgresql.conf.

include_dir = 'conf.d'			# include files ending in '.conf' from
					# directory 'conf.d'
#include_if_exists = 'exists.conf'	# include file only if it exists
#include = 'special.conf'		# include file


#------------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#------------------------------------------------------------------------------

# Add settings for extensions here

Ich habe den Entwickler der Anwendung angeschrieben. Er ist der Meinung, dass es nicht an seinen Triggern liegt, sondern eher an dem darunter liegendem Linux System. Hätte ich es unter Windows laufen, hätte ich keine Probleme mit meiner Konfiguration. So seine Aussage. Leider kann ich es nicht wirklich verifizieren, denn der momentane Platz und Aufwand lässt es mir nicht zu. Aber egal wie - ich will mich da wo es nicht zwingend notwendig ist, nicht von Linux Debian trenen, daher hoffe ich doch noch eine Lösung zu finden - es sei meine Konfig oder Handfestes Beweis, dass die Anwendung es macht.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von Blackbox » 14.01.2023 22:29:26

ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Nun, zunächst - tut mir leid, dass ich die Konfiguration die ich hier angegeben hatte nicht mehr später mit der aktueller aktualisiert habe.
Diesen Satz verstehe ich nicht, könntest du bitte deine Gedanken noch einmal ordnen?
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Es ist für mich doch stochern im dunkeln
Dann wollen wir hoffen, das du diese Datenbank nicht mit wichtigen Daten betreibst?
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Heißt auf Grund von verschiedenen Seiten habe ich versuchet diverse Parameter zu verändern.
[...]
Auf Grund der Änderungen kamen selbstverständlich auch Fehlermeldungen.
Aber wie soll man dir helfen, wenn du nicht weißt, was du eigentlich gemacht hast und was deine Änderungen bewirk(t)en?

Beim Überfliegen des von dir zur Verfügung gestellten Logfiles sieht man im Wesentlichen den von dir beschriebene Fehler.

Die Kurzform: Die Datenbank reserviert sich immer mehr Arbeitsspeicher, dann greift irgendwann OOMd ein und beendet den Speicherhungrigen Prozess.
Und daraus resultiert, dass die Datenbank nicht zu erreichen ist.

Deswegen auch diese Meldung:

Code: Alles auswählen

Verbindung wird abgebrochen aufgrund von Anweisung des Administrators
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Meine aktuelle Konfiguration sieht an vielen Stellen ganz anders als die oben angegebene.
Damit entfällt auch jede weitere Diskussionsgrundlage, weil ich nicht erspüren kann, in welchem Zustand sich deine Datenbank gerade befindet.
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Er ist der Meinung, dass es nicht an seinen Triggern liegt, sondern eher an dem darunter liegendem Linux System.
Ich würde die Antwort des Anwendungsentwicklers eher so deuten: „Ich habe keine Ahnung von Linux und kann/will dir auch nicht helfen.“
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Hätte ich es unter Windows laufen, hätte ich keine Probleme mit meiner Konfiguration.
An dieser Stelle hättest du stutzig werden sollen, was genau hat die Datenbankkonfiguration mit dem Betriebssystem zu tun?
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
Leider kann ich es nicht wirklich verifizieren, denn der momentane Platz und Aufwand lässt es mir nicht zu.
Willst du das Problem lösen, oder nicht?
ObiTobi hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 20:01:38
ich will mich da wo es nicht zwingend notwendig ist, nicht von Linux Debian trenen, daher hoffe ich doch noch eine Lösung zu finden - es sei meine Konfig oder Handfestes Beweis, dass die Anwendung es macht.
Auch bei diesem Satz kann man nur erahnen, was du eigentlich ausdrücken möchtest?

Mein Fazit: Also entweder bist du ein unglaublich schlechter Troll, oder du solltest wegen mangelnder Kenntnisse keine Datenbank betreiben.
Besser wäre allerdings, sorge dafür, dass du das benötigte Knowhow zum Betreiben einer postgreSQL-Datenbank benötigst.

Dann legst du ein Backup der Daten aus der Datenbank an, leerst anschließend alle Tabellen und wirfst die veränderte Konfiguration deiner Datenbank weg.
Nun kannst du einen neuen Versuch starten.

Wichtig ist, dass du keine Veränderungen an deiner Datenbankkonfiguration vornimmst, die du nicht verstanden hast!!!
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von ObiTobi » 14.01.2023 22:56:32

Ich hatte an sich viele Punkte kommentiert aber nach diesem Satz
Blackbox hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 22:29:26
Mein Fazit: Also entweder bist du ein unglaublich schlechter Troll, oder du solltest wegen mangelnder Kenntnisse keine Datenbank betreiben.
hat sich das Thema zumindest für weiteren Dialog mit Dir erledigt.
Ich bin sicher, dass Du zu den Helden gehörst die immer alles perfekt beherrschen :THX:

Benutzeravatar
heisenberg
Beiträge: 3548
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von heisenberg » 16.01.2023 22:21:31

Hallo ObiTobi,

was die Aussage des Entwicklers angeht, so stimme ich Blackbox allerdings zu: Da ist schon viel Unwilligkeit dabei, Dich bei der Lösung des Problems irgendwie zu unterstützen. Dein Server ist ja jetzt wirklich sehr üppig mit RAM ausgestattet.
  1. Ich hatte ja bereits geschrieben: Schaue Dir die einzelnen Direktiven zu PostgreSQL an in Deiner Config. So viele sind das ja nicht, die da wirklich konfiguriert sind. Was steht da? Ist das bei Dir dementsprechend konfiguriert?
  2. Schaue Dir die PostgreSQL-Konfigurationsanleitung von Photo Supreme für PostgreSQL genau an, also nicht nur Copy+Paste sondern genau lesen, was da steht und dann für Deinen DB-Server umsetzen.
  3. Nutze $SUCHMASCHINE, um zu schauen, ob vielleicht andere Personen Speicherprobleme beim Setup Photo Supreme und PostgreSQL hatten. (Ich sehe es da z. B. dass bei einer Person half, einen timeout(Config Option idle_session_timeout) in PostgreSQL zu konfigurieren. Das könntest Du versuchen).
  4. Eine Frage an den Support wäre, ob man beim Photo Supreme auch noch etwas an der Config drehen kann, dass der nicht so viele Verbindungen gleichzeitig aufmacht?
Das ist Deine eingedampfte Config:

Code: Alles auswählen

data_directory = '/var/lib/postgresql/14/main'
hba_file = '/etc/postgresql/14/main/pg_hba.conf'
ident_file = '/etc/postgresql/14/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/14-main.pid'
listen_addresses = 'localhost,xenpsql001.rjap.de'
port = 5432
max_connections = 150
unix_socket_directories = '/var/run/postgresql'
ssl = on
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
shared_buffers = 8GB
work_mem = 48MB
maintenance_work_mem = 4GB
dynamic_shared_memory_type = posix
checkpoint_timeout = 45min
max_wal_size = 3GB
min_wal_size = 1500MB
cpu_tuple_cost = 0.03
effective_cache_size = 24GB
log_line_prefix = '%m [%p] %q%u@%d '
log_timezone = 'localtime'
cluster_name = '14/main'
stats_temp_directory = '/var/run/postgresql/14-main.pg_stat_tmp'
autovacuum = no          
datestyle = 'iso, dmy'
default_text_search_config = 'pg_catalog.german'
include_dir = 'conf.d'
Die Frage ist noch, ob in include_dir (=conf.d) weitere Konfigurationsdateien drin sind?

Ansonsten würde ich "autovacuum" immer auf yes stellen. Ich empfehle die Dokumentation dazu, damit Du die Grundlagen dazu verstehst.

https://www.postgresql.org/docs/14/rout ... uming.html

Da Du die ganze Zeit auch vermutlich kein Vacuum durchgeführt hast, was die DB sehr langsam machen könnte, empfehle ich außerdem die Datenbank einmal per zu exportieren(pg_dump) und dann wieder zu importieren. Anschließend dann entweder autovacuum auf "yes" oder regelmässig ein manuell angestossenes VACUUM für alle Datenbanken.

Wenn Du nicht sicher bist im Umgang mit PostgreSQL empfehle ich Dir eine TestVM, auf der Du die Kommandos erst ausprobieren kannst, speziell den DB-Export und -Import. Letzteres wäre für einen Admin ohnehin Grundlagenwissen.
Jede Rohheit hat ihren Ursprung in einer Schwäche.

ObiTobi
Beiträge: 67
Registriert: 03.08.2016 20:50:26

Re: PostgreSQL - Konfig oder Anwendungfehler?

Beitrag von ObiTobi » 19.01.2023 07:33:01

heisenberg hat geschrieben: ↑ zum Beitrag ↑
16.01.2023 22:21:31
was die Aussage des Entwicklers angeht,
Aus das Verhalten des Entwicklers habe ich nun gar kein Einfluss. Die Auswahl was solche Software angeht die mit externen Datenbanken arbeiten kann und Frontend sowohl unter Windows wie auch Mac läuft ist sehr bescheiden.

In seiner Dokumentation schreibt er Parameter die er verändert hat und sagt "damit läuft es". Das er kein DBA Profi ist gibt er ja auch zu und ist auch so weit kein Problem.
Er hat in seiner Konfig z.B die Werte für max_wal_size und min_wal_size unverändert. Damit bei größeren Aktionen bekommt man Fehlermeldungen, dass die Checkpoints zu oft passieren.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
16.01.2023 22:21:31
  1. Ich hatte ja bereits geschrieben: Schaue Dir die einzelnen Direktiven zu PostgreSQL an in Deiner Config. So viele sind das ja nicht, die da wirklich konfiguriert sind. Was steht da? Ist das bei Dir dementsprechend konfiguriert?
  2. Schaue Dir die PostgreSQL-Konfigurationsanleitung von Photo Supreme für PostgreSQL genau an, also nicht nur Copy+Paste sondern genau lesen, was da steht und dann für Deinen DB-Server umsetzen.
  3. Nutze $SUCHMASCHINE, um zu schauen, ob vielleicht andere Personen Speicherprobleme beim Setup Photo Supreme und PostgreSQL hatten. (Ich sehe es da z. B. dass bei einer Person half, einen timeout(Config Option idle_session_timeout) in PostgreSQL zu konfigurieren. Das könntest Du versuchen).
  4. Eine Frage an den Support wäre, ob man beim Photo Supreme auch noch etwas an der Config drehen kann, dass der nicht so viele Verbindungen gleichzeitig aufmacht?
An der Stelle auf jedem Fall Danke für die Sinnvollen Hinweise.
1. Ja es sind nicht viele Punkte die ich konfiguriert habe. Das ist richtig.
2. Ja die Konfiguration aus der Photo Supreme habe ich mir mehrfach angeschaut. Er setzt eben auch nur wenige Parameter und wie der Entweder in der Dokumentation oder per Mail mir mal geschrieben hat, er verwendet für seine Testdatenbanken eher eine "schwache" Maschine. Mit deutlich weniger RAM. OK er nutzt das nativ, bei mir läuft die Maschine als VM auf enem KVM Server
4. In der Anwendung selbst gibt es keine Parameter die man in Bezug auf die Datenbank konfigurieren kann.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
16.01.2023 22:21:31
Die Frage ist noch, ob in include_dir (=conf.d) weitere Konfigurationsdateien drin sind?
Nein da ist nichts drin.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
16.01.2023 22:21:31
Ansonsten würde ich "autovacuum" immer auf yes stellen. Ich empfehle die Dokumentation dazu, damit Du die Grundlagen dazu verstehst.
Das habe ich extra abgeschaltet, damit mir im Betrieb nichts dazwischen spuckt. Vacuum wird Nachts per cron erledigt.

So wie ich das sehe so einen Hexenwerk macht er nicht. Zunächst hat er die Liste der Dateien die verändert werden sollen. Dann sucht er nach den Einträgen in der Datenbank und löscht die Einträge. Anschließend schreibt er die neue Einträge in die Datenbank.
Meine wo ich geguckt habe, waren es immer 20 Datensätze ich er immer verarbeitet.

Vor 2 Tagen habe ich eine Windows VM aufgesetzt und da PostgreSQL installiert. Zum einem ist das Verarbeiten X Fach langsamer als mit der Linux VM (VM Parameter sind gleich was RAM, CPU und Disk angeht. Die Disk wo die Datenbanken liegen wird direkt an die VM weitergereicht. Zum anderen wenn kein Wunder passiert, wird auch unter Windows am Ende die Datenbank abstürzen. Mehr weiß ich heute Abend.

Antworten