Re: High I/O writes activity on disks causing images on browser to lag and not load
| От | Jennifer Trey |
|---|---|
| Тема | Re: High I/O writes activity on disks causing images on browser to lag and not load |
| Дата | |
| Msg-id | 863606ec0906040348h20cd2a36w137002411326b917@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: High I/O writes activity on disks causing images on browser to lag and not load (Scott Marlowe <scott.marlowe@gmail.com>) |
| Ответы |
Re: High I/O writes activity on disks causing images on
browser to lag and not load
(Karsten Hilbert <Karsten.Hilbert@gmx.net>)
|
| Список | pgsql-general |
Sorry, went to bed yesterday :D
I have installed postgresql-8.3.7-1-windows.exe
Bill, you are right. The app does do tons of small queries, and its possible that the two drives are misconfigured. I have checked into that a little and can't rule it out completely.
Yes, my images hang indefinitly, until the browser gives up. Note that, if I reload the page it will normally reload fine, or possibly that some other image hangs instead. The images are on the other 1TB disk drive, and there is almost no activity on that drive(seen from perfmon), but it seems to be going through the C:drive so if there is a queue on C: then there will be a problem fetching from I:Image as well. I would prefer if the I:Image drive just flushed out the images (not sure how I can accomplish that) it self but the overwhelming disk activity seems to be the disk writes on C... thats what I noticed on perfmon. I/O transfers and I/O writes graphs where almost identical. Would you say that these I/O writes are normal?
I could move the pgdata to the image drive and have that one busy with the writing instead. Not sure that will help though.
When it come to turning of the Statistics, I saw your link and looked into my config file.. those settings where all off or commented :
#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------
# - Query/Index Statistics Collector -
#track_activities = on
#track_counts = on
#update_process_title = on
# - Statistics Monitoring -
#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
#log_statement_stats = off
#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# NOTE: This parameter is been added by EnterpriseDB's Tuning Wiard on 2009/04/08 13:33:58
autovacuum = true # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least that time.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
#autovacuum_naptime = 1min # time between autovacuum runs
# NOTE: This parameter is been added by EnterpriseDB's Tuning Wiard on 2009/04/08 13:33:58
autovacuum_naptime = 60 # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# NOTE: This parameter is been added by EnterpriseDB's Tuning Wiard on 2009/04/08 13:33:58
autovacuum_vacuum_threshold = 1000 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# NOTE: This parameter is been added by EnterpriseDB's Tuning Wiard on 2009/04/08 13:33:58
autovacuum_analyze_threshold = 250 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
# NOTE: This parameter is been added by EnterpriseDB's Tuning Wiard on 2009/04/08 13:33:58
autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
# NOTE: This parameter is been added by EnterpriseDB's Tuning Wiard on 2009/04/08 13:33:58
autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20 # default vacuum cost delay for
# autovacuum, -1 means use
# vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit
Just turn off autovacuum ?
/ Jennifer
В списке pgsql-general по дате отправления: