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) - next without swap: i monitored the system with hmon and the vacuum task was getting bigger and bigger until oom killed it. VIRT at about 20.x GB, MEM% at 80-90% At this time i called for help. - next: rebuilt the gin-index without fastupdate=off to use the default. - vacuum planet_osm_ways on console - VIRT about 1.2 GB, MEM% about 3.4% on HTOP - crashed again, system logs are attached saying "OOM killed him, but using about 1.2 GB, which is fine to me (and you) - dropped index, clustered, vacuum --> no problems - recreating of gin index is still running. 96/121 GB, some hours to go. waiting for next test. > reporting > a size of 1.2GB doesn't surprise me at all (assuming it's including > shared memory in there). > > This is starting to sound like a regular OOM problem. Have you tried the > steps in > http://postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT not yet, but i'll check it right now. Regards walter -- View this message in context: http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-too-tp5840299p5840765.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
