Re: [GENERAL] autovacuum worker running amok - and me too ;)

sorry, 64 GB swap -- View this message in context: http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-too-tp5840299p5841075.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To mak

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Hi paul just found my system (24 GB Mem, 72 GB Swap) running nearly at it's limits: The current vaccum is using 66.7 GB (sixty-six dot seven) GB of memory and my System is nearly down. I'm sorry, but that must be an bug. Remember: It's the Analyze of an GIN-Index that is making that problems. Va

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Hi, some final results: I monitored the vaccum process and logged some data using one big table and doing analyze/vaccum by hand. Table has two btree-indexes and one gin. maintenance_work_mem was 1GB. the analyze job used abot 1.2 GB virt mem during the whole task, no problems at all. The vacu

Re: [GENERAL] autovacuum worker running amok - and me too ;)

wambacher wrote > hi, > > waiting for the index (104/121GB), i read his document > http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT > and will do some changes before the next analyze: > > some comments: > > - the OOM did not

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Karsten Hilbert wrote > Of course, I am > not suggesting you provide 48GB of swap and your problem is > magically solved _but_ one thing we might take away from that > old adage is that one might "hope things to work better" > (say, while debugging) if there is at least as much swap as > there is p

Re: [GENERAL] autovacuum worker running amok - and me too ;)

hi, waiting for the index (104/121GB), i read his document http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT and will do some changes before the next analyze: some comments: - the OOM did not kill the Postmaster but the Analyze-Job. - started with 24GB real

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Jim Nasby-5 wrote > Which is it? Is the vacuum process is using 1.2GB (5% of memory) or is > it using 90% (~22GB)? i ran the job 2-3 times. - first with 18GB swap too. I heared it thrashing, performance went extremly down and after 2 hours i killed the job (reboot system, no other way to do it)

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Jim Nasby-5 wrote > On 3/5/15 2:06 PM, wambacher wrote: > Crashed? Or hit by the OOM killer? What's the log say? killed by OOM, but has only 1.2 GB mem, which is ok to me. > While this is going on you might as well disable autovac for that table. > It'll keep crashing a

Re: [GENERAL] autovacuum worker running amok - and me too ;)

crashed: no idea what to do now. walter -- View this message in context: http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-too-tp5840299p5840696.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-genera

Re: [GENERAL] autovacuum worker running amok - and me too ;)

> ... this will need some hours. Done after 30 Minutes :) nearly 50% dead rows - strange. Now i'll run a "vacuum verbose planet_osm_ways" because the system crashed during the autovacuum. cross my fingers. Walter -- View this message in context: http://postgresql.nabble.com/autovacuum-

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Hi, in my first post you can see all params: maintenance_work_mem = 64MB and two workers. i configured my system to the absolutely minimum ( got 24 GB real memory) and the problem was still there. Last night i rebuilt one index (122GB Size) and just in this minutes i started a manual "analyze

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Paul Ramsey wrote > Though maybe with a really big table? (with really big > objects?) Though still, doesn't analyze just pull a limited sample > (30K approx max) so why would table size make any difference after a > certain point? Hi paul, "my" table is quite big (about 293.049.000 records) but t

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Roxanne Reid-Bennett wrote > Most definitely ask on the Postgis list. Identify the full Postgis > version and Postgres versions as well. Hi Roxanne, seconds before sending it to the postgis-list i checked the table planet_osm_ways and there is no geometry: That can't be a postgis problem. I'll

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Tom Lane-2 wrote > See ALTER TABLE SET STATISTICS TARGET. thanks, will try it regards walter btw: the postgis analyze problem has been fixed more than one year ago, but i'll ask them too. -- View this message in context: http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-to

Re: [GENERAL] autovacuum worker running amok - and me too ;)

Tom Lane-2 wrote > Maybe you could reduce the statistics targets for that table. don't understand what you mean. do you mean how often that table is autovacuumed? at the moment about once a day or once in two days, i think. > I think we've heard that the analyze functions for PostGIS data types a

[GENERAL] autovacuum worker running amok - and me too ;)

Hi, running postgresql on ubuntu for many years, but now i'm in big trouble. My system has 24GB of real memory but after some hours one autovacuum worker is using 80-90% of memory, the OOM-Killer (out of memory killer) kills the process with kill -9 and the postgresql-server is restarting becaus