Skip site navigation (1) Skip section navigation (2)

R: VACUUM FULL ANALYSE hanging

From: "Gabriele Bartolini" <g(dot)bartolini(at)comune(dot)prato(dot)it>
To: "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: R: VACUUM FULL ANALYSE hanging
Date: 2007-05-04 09:43:33
Message-ID: 910CF843580B3C40A25CD0D04B3908E21306BB@exchange4.comune.prato.local (view raw or flat)
Thread:
Lists: pgsql-admin
Hi guys,

   thanks for your answer. Unfortunately I have no superuser privileges on that server, but I have tried to look it up closely with our administrator today. I launched the VACUUM FULL ANALYSE command last night on a table, and it is still running.

   Now, I want to finish it and see how long it took. It is a test I want to do. The process is not idle, we have 'straced' it and here it's the output:

postgres  9178  9.2 10.9 527384 443476 ?     Ds   May03  75:37  \_ postgres: htminer htminer [local] VACUUM

> strace -i -p 9178
Process 9178 attached - interrupt to quit
[      339e0c6902] lseek(55, 1067171840, SEEK_SET) = 1067171840
[      339e0b9302] write(55, "\317\0\0\0h\37\353\331\1\0\0\0l\1\220\32\360\37\3 \340"..., 8192) = 8192
[      339e0c6902] lseek(31, 31145984, SEEK_SET) = 31145984
[      339e0b9272] read(31, "m\0\0\0\320\22V\36\1\0\0\0\240\5\310\t\360\37\3 \340\237"..., 8192) = 8192
[      339e0c6902] lseek(31, 31309824, SEEK_SET) = 31309824
[      339e0b9272] read(31, "\317\0\0\0\310\26\353\331\1\0\0\0\350\4\240\f\360\37\3"..., 8192) = 8192
[      339e0c6902] lseek(32, 667787264, SEEK_SET) = 667787264
[      339e0b9272] read(32, "\301\0\0\0PI\t\27\1\0\0\0\34\0\330\37\360\37\3 \350\237"..., 8192) = 8192
[      339e0c6902] lseek(34, 157900800, SEEK_SET) = 157900800
[      339e0b9272] read(34, "\317\0\0\0P\3725\327\1\0\0\0\260\5\210\t\360\37\3 \350"..., 8192) = 8192 

   If you are interested - and may be useful for comparisons - I will let you know the results.

   The tables are locked (I looked at pg_lock):

htminer=> select * from pg_locks where pid = 9178;
   locktype    | database | relation | page | tuple | transactionid | classid | objid | objsubid | transaction | pid  |        mode         | granted
---------------+----------+----------+------+-------+---------------+---------+-------+----------+-------------+------+---------------------+---------
 relation      |    16415 |   199381 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199381 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 relation      |    16415 |   199385 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199385 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 transactionid |          |          |      |       |      64899160 |         |       |          |    64899160 | 9178 | ExclusiveLock       | t
 relation      |    16415 |   199142 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199142 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 relation      |    16415 |   199382 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199382 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 relation      |    16415 |   199383 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199383 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 relation      |    16415 |   199386 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199386 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 relation      |    16415 |   198716 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t
 relation      |    16415 |   199384 |      |       |               |         |       |          |    64899160 | 9178 | RowExclusiveLock    | t
 relation      |    16415 |   199384 |      |       |               |         |       |          |    64899160 | 9178 | AccessExclusiveLock | t


   It should be alright. I am waiting for the results. Thank you for your nice answers.

Ciao,
Gabriele

--
Gabriele Bartolini - Istruttore Informatico - Comune di Prato
Sistema Informativo - Servizi di E-Government e Open-Source
g(dot)bartolini(at)comune(dot)prato(dot)it - www.comune.prato.it - www.htminer.it

-----Messaggio originale-----
Da: Scott Marlowe [mailto:smarlowe(at)g2switchworks(dot)com] 
Inviato: mercoledì 2 maggio 2007 17.41
A: Gabriele Bartolini
Cc: pgsql-admin(at)postgresql(dot)org
Oggetto: Re: [ADMIN] VACUUM FULL ANALYSE hanging

On Wed, 2007-05-02 at 05:05, Gabriele Bartolini wrote:
> Hi guys,
>  
>    I am having problems with freeing disk space after a massive delete 
> operation on a table that had approximately 80 million record. I ran 
> the following command, by setting the vacuum memory to approximately a 
> GigaByte:
>  
> SET vacuum_mem TO 1024000
> VACUUM FULL ANALYSE VERBOSE oltp.requests
>  
> Here is what I get:

SNIP

> DETAIL:  8211835 index row versions were removed.
> 73821 index pages have been deleted, 73821 are currently reusable.
> CPU 17.06s/28.14u sec elapsed 319.16 sec.
> 
>    But here, the command simply hangs.
>  
>    The table description is:

Maybe it's hanging, maybe it's just taking a really long time to finish and get back to you.

What's vmstat / top /iostat got to say about the machine during this "hang"?

IF the I/O or CPU are high, then it's not hung, it's just taking a while.

In response to

pgsql-admin by date

Next:From: Carol WalterDate: 2007-05-04 13:11:05
Subject: Adding a port to postgresql.conf
Previous:From: Tom LaneDate: 2007-05-04 04:15:20
Subject: Re: pl/pgsql function spikes CPU 100%

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group