On Wed, April 1, 2015 9:35 am, Kevin Grittner-5 [via PostgreSQL] wrote: >
> > TonyS <t...@exquisiteimages.com> wrote: > > >> The postgresql log has these entries at the crash point: >> 2015-04-01 06:24:37 EDT LOG: server process (PID 1384) was terminated >> by signal 9: Killed 2015-04-01 06:24:38 EDT DETAIL: Failed process was >> running: analyze verbose; >> > > That was almost certainly the action of the OS's Out Of Memory > Killer process. > > >> Is there anything else that would be helpful? >> > > Unfortunately, leaving the OOM killer enabled causes the best > evidence to be destroyed. If you disable the OOM killer and run this > again, when memory is exhausted the database process attempting to > allocate memory will dump a map of where its memory was allocated. That > should give us something to work with regarding the cause. Try: > > vm.overcommit_memory = 2 vm.overcommit_ratio = 80 > > Also, it would be useful to see the output of this: > > > SELECT name, current_setting(name), source > FROM pg_settings > WHERE source NOT IN ('default', 'override'); > > > -- > Kevin Grittner > EDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > Thanks for the follow up Kevin. I made the changes to overcommit and started running the analyze operation again about 2 hours ago, so if it stays true to form, it should be crashing in about 5-1/2 hours. The output from the query you suggested is: name,current_setting,source autovacuum,off,configuration file checkpoint_completion_target,0.9,configuration file checkpoint_segments,16,configuration file checkpoint_timeout,1h,configuration file client_encoding,WIN1252,session default_statistics_target,10,configuration file default_text_search_config,pg_catalog.english,configuration file effective_cache_size,5132MB,configuration file external_pid_file,/var/run/postgresql/9.3-main.pid,configuration file fsync,off,configuration file lc_messages,en_US.UTF-8,configuration file lc_monetary,en_US.UTF-8,configuration file lc_numeric,en_US.UTF-8,configuration file lc_time,en_US.UTF-8,configuration file listen_addresses,*,configuration file log_line_prefix,%t ,configuration file log_timezone,localtime,configuration file maintenance_work_mem,480MB,configuration file max_connections,5,configuration file max_locks_per_transaction,512,configuration file max_stack_depth,2MB,environment variable port,5432,configuration file shared_buffers,1920MB,configuration file ssl,on,configuration file ssl_cert_file,/etc/ssl/certs/ssl-cert-snakeoil.pem,configuration file ssl_key_file,/etc/ssl/private/ssl-cert-snakeoil.key,configuration file synchronous_commit,off,configuration file TimeZone,localtime,configuration file unix_socket_directories,/var/run/postgresql,configuration file wal_buffers,8MB,configuration file work_mem,1536MB,configuration file -- View this message in context: http://postgresql.nabble.com/Would-like-to-know-how-analyze-works-technically-tp5844197p5844292.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.