Re: Disk filling, CPU filling, renegade inserts and deletes?
От | Richard Plotkin |
---|---|
Тема | Re: Disk filling, CPU filling, renegade inserts and deletes? |
Дата | |
Msg-id | b155378a669f04e74f597d4b105c2a10@richardplotkin.com обсуждение исходный текст |
Ответ на | Re: Disk filling, CPU filling, renegade inserts and deletes? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Disk filling, CPU filling, renegade inserts and deletes?
|
Список | pgsql-performance |
Hi Tom, > Q: what have you got the FSM parameters set to? Here's from postgresql.conf -- FSM at default settings. # - Memory - shared_buffers = 30400 # min 16, at least max_connections*2, 8KB each work_mem = 32168 # min 64, size in KB #maintenance_work_mem = 16384 # min 1024, size in KB #max_stack_depth = 2048 # min 100, size in KB # - Free Space Map - #max_fsm_pages = 20000 # min max_fsm_relations*16, 6 bytes each #max_fsm_relations = 1000 # min 100, ~50 bytes each # - Kernel Resource Usage - max_files_per_process = 750 #1000 # min 25 #preload_libraries = '' > Q: what exactly is bloating? Without knowing which tables or indexes > are growing, it's hard to speculate about the exact causes. Use du and > oid2name, or look at pg_class.relpages after a plain VACUUM. This I do not know. I've disabled the cron jobs and will let the system bloat, then I will gather statistics (I'll give it 12-24 hours). > It's likely that the real answer is "you need to vacuum more often > than every six hours", but I'm trying not to jump to conclusions. That could be it, except that I would expect the problem to then look more like a gradual increase in CPU usage and a gradual increase in use of disk space. Mine could be an invalid assumption, but the system here looks like it goes from no problem to 100% problem within a minute. Thanks again! Richard
В списке pgsql-performance по дате отправления: