7.3.4真空/分析错误 [英] 7.3.4 vacuum/analyze error
问题描述
我在运行ANALYZE
和/或VACUUM ANALYZE（来自autovacuum过程）时遇到一大堆这些可重复的错误
7.3.4集群在HP-UX上B.11.00：
2004-09-29 18：14：53.621 [520]错误：AllocSetAlloc（1189）内存耗尽
此错误在FAQ中，但该答案似乎不适用。
错误发生在2个不同的数据库上，在多个表上，
并且所有涉及的表都经常更新。
任何线索？
这里有一个更多上下文的例子：
2004-09-29 18：20：55.426 [3728]日志：查询：分析审计
TopMemoryContext：总共32792个4块; 11664免费（23块）; 21128使用
TopTransactionContext：8192总共1块; 8176免费（0块）; 16使用
DeferredTriggerXact：总共0个0块; 0免费（0块）; 0使用
TransactionCommandContext：总共8192个1块; 8176免费（9块）; 16使用
QueryContext：总共8192个块; 7440免费（1块）; 752使用
分析：132263832共27块; 2984免费（35块）;使用132260848
真空：1块8192个; 8152免费（0块）; 40使用
DeferredTriggerSession：总共0个0块; 0免费（0块）; 0使用
PortalMemory：总共8192个积木; 8176免费（0块）; 16使用
CacheMemoryContext：总计516096 6块; 170872免费（1块）; 345224使用
pg_index_indrelid_index：1块总共1024块; 640免费（0块）; 384使用
pg_toast_16410_index：1块总共1024块; 320免费（0块）; 704使用
pg_stat_all_tables：19456总共19个街区; 216免费（0块）; 19240使用
pg_settings：5个街区共计5120个; 336免费（0块）; 4784使用了
pg_conversion_oid_index：总共1024个块; 640免费（0块）; 384使用
pg_index_indexrelid_index：总共1024块; 640免费（0块）; 384使用
pg_shadow_usesysid_index：总共1024个块; 640免费（0块）; 384使用
pg_rewrite_rel_rulename_index：1块总共1024块; 320免费（0块）; 704使用
pg_group_name_index：1块总共1024块; 640免费（0块）; 384使用
pg_opclass_am_name_nsp_index：总共1024个块; 320免费（0块）; 704使用
pg_cast_source_target_index：1块总共1024块; 320免费（0块）; 704使用
pg_language_name_index：总共1024个块; 640免费（0块）; 384使用
pg_type_oid_index：总共1024个块; 640免费（0块）; 384使用了
pg_language_oid_index：1块总共1024块; 640免费（0块）; 384使用
pg_amop_opc_strategy_index：总共1024块; 320免费（0块）; 704使用
pg_statistic_relid_att_index：总共1024个块; 320免费（0块）; 704使用
pg_amproc_opc_procnum_index：总共1024个块; 320免费（0块）; 704使用
pg_class_oid_index：总共1024个块; 640免费（0块）; 384使用
pg_class_relname_nsp_index：总共1024个块; 320免费（0块）; 704使用
pg_type_typname_nsp_index：总共1024个块; 320免费（0块）; 704使用
pg_attribute_relid_attnam_index：总共1024个块; 320免费（0块）; 704使用
pg_trigger_tgrelid_tgname_index：总共1024个块; 320免费（0块）; 704使用
pg_conversion_default_index：共计2072个积分; 712免费（0块）; 1360使用了
pg_aggregate_fnoid_index：1块总共1024块; 640免费（0块）; 384使用
pg_namespace_oid_index：总共1024个块; 640免费（0块）; 384使用
pg_group_sysid_index：总共1024个块; 640免费（0块）; 384使用
pg_attribute_relid_attnum_index：总共1024个块; 320免费（0块）; 704使用
pg_shadow_usename_index：1块总共1024块; 640免费（0块）; 384使用
pg_namespace_nspname_index：总共1024个块; 640免费（0块）; 384使用
pg_inherits_relid_seqno_index：1块总共1024块; 320免费（0块）; 704使用
pg_operator_oid_index：总共1024个块; 640免费（0块）; 384使用
pg_conversion_name_nsp_index：总共1024个块; 320免费（0块）; 704使用
pg_opclass_oid_index：1块总共1024块; 640免费（0块）; 384使用
pg_proc_proname_args_nsp_index：2072总共2个区块; 712免费（0块）; 1360使用
pg_proc_oid_index：1块总共1024块; 640免费（0块）; 384使用
pg_operator_oprname_l_r_n_index：2072总共2个区块; 712免费（0块）; 1360使用
pg_amop_opc_opr_index：1块总共1024块; 320免费（0块）; 704使用
MdSmgr：1块8192总计; 6120免费（0块）; 2072使用
DynaHash：总共8192个积木; 7064免费（0块）; 1128使用
DynaHashTable：总共8192个积木; 5080免费（0块）; 3112使用
DynaHashTable：总共8192个积木; 6112免费（0块）; 2080使用
DynaHashTable：总共8192个积木; 3016免费（0块）; 5176使用
DynaHashTable：总共8192个积木; 4040免费（0块）; 4152使用
DynaHashTable：总共24576个积木; 13240免费（4块）; 11336使用
DynaHashTable：总共8192个积木; 8176免费（0块）; 16使用
DynaHashTable：总共8192个积木; 8176免费（0块）; 16使用
DynaHashTable：总共8192个积木; 8176免费（0块）; 16使用
DynaHashTable：总共8192个积木; 8176免费（0块）; 16使用
DynaHashTable：总共8192个积木; 8176免费（0块）; 16使用
ErrorContext：总共8192块; 8176免费（0块）; 16使用
2004-09-29 18：20：56.580 [3728]错误：AllocSetAlloc内存耗尽（1189）
2004-09-29 18：20：56.580 [3728]日志：声明：分析审核
---------------------------（广播结束） - --------------------------
提示9：如果您的计划者忽视您选择索引扫描的愿望
加入列的数据类型不匹配
I''m getting a slew of these repeatable errors when running ANALYZE
and/or VACUUM ANALYZE (from an autovacuum process) against a
7.3.4 cluster on HP-UX B.11.00:
2004-09-29 18:14:53.621 [520] ERROR: Memory exhausted in AllocSetAlloc(1189)
This error is in the FAQ, but that answer does not appear applicable.
The error is occurring on 2 different databases, on multiple tables,
and all tables involved are frequently updated.
Any clues?
Here''s an example with more context:
2004-09-29 18:20:55.426 [3728] LOG: query: ANALYZE audit
TopMemoryContext: 32792 total in 4 blocks; 11664 free (23 chunks); 21128 used
TopTransactionContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
DeferredTriggerXact: 0 total in 0 blocks; 0 free (0 chunks); 0 used
TransactionCommandContext: 8192 total in 1 blocks; 8176 free (9 chunks); 16 used
QueryContext: 8192 total in 1 blocks; 7440 free (1 chunks); 752 used
Analyze: 132263832 total in 27 blocks; 2984 free (35 chunks); 132260848 used
Vacuum: 8192 total in 1 blocks; 8152 free (0 chunks); 40 used
DeferredTriggerSession: 0 total in 0 blocks; 0 free (0 chunks); 0 used
PortalMemory: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
CacheMemoryContext: 516096 total in 6 blocks; 170872 free (1 chunks); 345224 used
pg_index_indrelid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_toast_16410_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_stat_all_tables: 19456 total in 19 blocks; 216 free (0 chunks); 19240 used
pg_settings: 5120 total in 5 blocks; 336 free (0 chunks); 4784 used
pg_conversion_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_index_indexrelid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_shadow_usesysid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_group_name_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_cast_source_target_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_language_name_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_type_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_language_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_amop_opc_strategy_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_statistic_relid_att_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_amproc_opc_procnum_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_class_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_class_relname_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_type_typname_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_conversion_default_index: 2072 total in 2 blocks; 712 free (0 chunks); 1360 used
pg_aggregate_fnoid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_namespace_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_group_sysid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_shadow_usename_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_namespace_nspname_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_inherits_relid_seqno_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_operator_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_conversion_name_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_opclass_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_proc_proname_args_nsp_index: 2072 total in 2 blocks; 712 free (0 chunks); 1360 used
pg_proc_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_operator_oprname_l_r_n_index: 2072 total in 2 blocks; 712 free (0 chunks); 1360 used
pg_amop_opc_opr_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
MdSmgr: 8192 total in 1 blocks; 6120 free (0 chunks); 2072 used
DynaHash: 8192 total in 1 blocks; 7064 free (0 chunks); 1128 used
DynaHashTable: 8192 total in 1 blocks; 5080 free (0 chunks); 3112 used
DynaHashTable: 8192 total in 1 blocks; 6112 free (0 chunks); 2080 used
DynaHashTable: 8192 total in 1 blocks; 3016 free (0 chunks); 5176 used
DynaHashTable: 8192 total in 1 blocks; 4040 free (0 chunks); 4152 used
DynaHashTable: 24576 total in 2 blocks; 13240 free (4 chunks); 11336 used
DynaHashTable: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
DynaHashTable: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
DynaHashTable: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
DynaHashTable: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
DynaHashTable: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
2004-09-29 18:20:56.580 [3728] ERROR: Memory exhausted in AllocSetAlloc(1189)
2004-09-29 18:20:56.580 [3728] LOG: statement: ANALYZE audit
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column''s datatypes do not match
推荐答案
" Ed L." < PG *** @ bluepolka.net>写道：
"Ed L." <pg***@bluepolka.net> writes:
运行ANALYZE
和/或VACUUM ANALYZE（来自autovacuum进程）对一个
7.3.4集群时，我得到了一大堆这些可重复的错误HP-UX B.11.00：
2004-09-29 18：14：53.621 [520]错误：AllocSetAlloc内存耗尽（1189）
分析：132263832共计27个区块; 2984免费（35块）; 132260848使用
I''m getting a slew of these repeatable errors when running ANALYZE
and/or VACUUM ANALYZE (from an autovacuum process) against a
7.3.4 cluster on HP-UX B.11.00: 2004-09-29 18:14:53.621 [520] ERROR: Memory exhausted in AllocSetAlloc(1189) Analyze: 132263832 total in 27 blocks; 2984 free (35 chunks); 132260848 used
要么增加每进程内存限制，要么减少统计数据
此表的目标...
问候，汤姆小巷
-------------------------- - （广播结束）---------------------------
提示5：您是否查看了我们广泛的常见问题解答？
http：//www.postgresql .org / docs / faqs / FAQ.html
Either increase your per-process memory limit, or reduce the statistics
targets for this table ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
2004年9月29日星期三5:17，Tom Lane写道：
On Wednesday September 29 2004 5:17, Tom Lane wrote:
Ed L. < PG *** @ bluepolka.net>写道：
"Ed L." <pg***@bluepolka.net> writes:
运行ANALYZE
和/或VACUUM ANALYZE（来自autovacuum进程）对一个
7.3.4集群时，我得到了一大堆这些可重复的错误HP-UX B.11.00：
2004-09-29 18：14：53.621 [520]错误：内存耗尽
AllocSetAlloc（1189）
分析：132263832共27个街区; 2984免费（35块）; 132260848
使用
I''m getting a slew of these repeatable errors when running ANALYZE
and/or VACUUM ANALYZE (from an autovacuum process) against a
7.3.4 cluster on HP-UX B.11.00:
2004-09-29 18:14:53.621 [520] ERROR: Memory exhausted in
AllocSetAlloc(1189)
Analyze: 132263832 total in 27 blocks; 2984 free (35 chunks); 132260848
used
要么增加每个进程的内存限制，要么减少此表的统计目标...
Either increase your per-process memory limit, or reduce the statistics
targets for this table ...
我缺少什么？
What am I missing?
ulimit -a
时间（秒）无限
文件（块）无限
数据（千字节）131072
堆栈（kbytes）8192
内存（kbytes）无限制
coredump（blocks）4194303
nofiles（descriptors）120
ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 131072
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 120
这篇关于7.3.4真空/分析错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
