Re: High I/O writes activity on disks causing images on browser to lag and not load

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