R: VACUUM FULL ANALYSE hanging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.bartolini@xxxxxxxxxxxxxxx - www.comune.prato.it - www.htminer.it

-----Messaggio originale-----
Da: Scott Marlowe [mailto:smarlowe@xxxxxxxxxxxxxxxxx] 
Inviato: mercoledì 2 maggio 2007 17.41
A: Gabriele Bartolini
Cc: pgsql-admin@xxxxxxxxxxxxxx
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.


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux