Hi,
We are still trying to fix our issue and we found following logs :
2013-01-17 09:55:01 CET LOG: automatic vacuum of table
"flows.public.agg_t1213_incoming_a6_dst_port_and_proto_f5": index scans: 1
pages: 0 removed, 136547 remain
tuples: 0 removed, 4044679 remain
syst
ng 25 minutes then it just started to
take too much time on CREATE INDEX statements.
I just figure that when we perform the full process (with deletion of old
data), CREATE INDEX and TUNCATE take too much time.
At the same time the autovacuum process seems to perform more tasks on second
t
w a server (8 CPUs) which has a 0.56 load over the last 15 minutes could not
handle 3 autovacuum processes, for me it is very confusing.
Thanks anyway for your time and help.
Happy New Year's Eve.
Best regards,
Baptiste
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technop
> Was the blocking you described occurring at the time you captured
> this? It doesn't seem to be showing any problem.
Yes indeed. We have noticed that any process seems to be in waiting situation
but :
- before the autovacuum process starts to work on the both kind of tables,
truncate and ind
I have check but debian proposed only to upgrade to the 8.4.13.
Best regards, Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via pgsql-admin mailing list (pgsql-admin@postgre
nce of any bugs
> which have already been fixed?
Is there a way to upgrade without having to dump all data and restore them
after the upgrade ?
Best regards, Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51
| 756MB
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Thanks both of you for your help.
The autovacuum process did the work yesterday.
Best regards,
Baptiste
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via pgsql-admin mailing list
> Does "select * from pg_prepared_xacts" find anything?
Yes indeed, so I rollback our old prepared transactions.
I will check tomorrow, and I will let you know.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bida
I run a select on the pg_stat_all_tables and it returns that there is 0
n_dead_tup.
I am really confused.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via
>As I said, because they are still visible to other transactions. Try to
>see if you have long-lasting transactions.
How can I do that ? I check running query in pg_stat_activity, but there is no
query on that table.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
A
> It could be dead rows, still visible for other transactions.
Ok but in this case, why the automatic vacuum task of the autovacuum process
does not delete theses dead rows ?
Best regards,
Baptiste
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64
s).
To be sure I tried to run the following query to count availables tuples :
select count(*) from agg_t344_outgoing_a41_src_net_and_dst_net_f5;
count
-
2584398
(1 row)
Can someone give me a clue ?
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. -
>> Please show us the output from running this query:
>>
>> http://wiki.postgresql.org/wiki/Server_Configuration
> [very reasonable settings except for a very large work_mem]
> Make sure that work_mem setting isn't driving you into swapping or
> near-zero caching. A shortage of cache space could
Hi,
> That depends on configuration settings and on whether the computer
> (or VM) is so swamped that the autovacuum task is starved for cycles.
> Also on any overrides of statistics targets for those tables.
> Please show us the output from running this query:
> http://wiki.postgresql.org/wiki/
Hi,
Today I consulted the log of my PostgreSQL server and I saw that autovacuum
tasks took to much time to do their work. I thought that ANALYZE was a fast
operation ?
2012-11-09 10:52:33 CET LOG: automatic analyze of table
"flows.public.agg_t20_outgoing_a41_src_net_and_dst_net_f5" system usa
Hi,
> So that an auto-ANALYZE should run each 2.5-3 hours.
>
> If it does not proceed, check that you do not have some process still doing
> manual maintenance or DDL on those tables, they might
> lock the table and kill autovacuum
>
> (check the pg_stat_activity, and set log_autovacuum_min_du
55.447895+02 | 2.58851e+06 |63516 | 23375180
Regards, Baptiste Lhoste
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
ry in the pg_stat_activity,
althought we set the autovacuum_naptime to 15s to try to start new analyze task
more often.
We do not understand why we can't obtain some improvments with previous
changes. Did we do something wrong ?
Thank you all for your kind advices,
Regards, Baptiste.
---
Baptist
19 matches
Mail list logo
