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.