List of played hands loading very long time

[dvvv]

Hi, this is second week when I am experiencing such issue:
list of hands is loading very long time, does not matter if it is in the reports section or where the sessions are.. last 100 hands could take up to several minutes.

Can I do something to fix this?

http://img214.imageshack.us/img214/5821/70436179.png

p.s. I have been doing vacuum / analyze / reindexing recently... and I am wondering could that be the reson of usch begavior?

[Patvs]

What sort of harddisk do you have? (take a look at my response in your other thread: http://forums.holdemmanager.com/showthread.php?t=18584 What are your 4K read/write speeds?)

Update to 1.09.02
http://www.holdemmanager.com/downloads/HmUpdate.exe


You have 180.000+ players in your database and probably a very large database... Can you DEFRAG your harddisk, and edit your postgreSQL.conf

http://www.revsys.com/writings/postgresql-performance.html

And read this (http://208.109.95.123/forum/showthread.php?t=11194)

[dvvv]

1. Thank you for following up on my previous topic.
2. I have 7200 Standard SATA 2 hard drive, seagate baracuda 11. I will test it @home but result I expect to be the same as the one you provided for just standard 7200 drive. Database is stored on a separate logic drive, nothing else is there, drive id defragmented.
3. all performance tips used

And the most important: this did not happen step by step, I started HM one day and it took 2+ minutes to load the page. On the previous day it took 2 sec. That is why I think hard drive speed could be not so critical here...

[Patvs]

I was going to add "purge hands" to decrease the size of your database, but now that you've stated a simple task used to take 2 seconds now takes 2 minutes, it must be a completely different problem:

Could something be blocking communications to port 5432.
A firewall/antivirus program that still allows communication through port 5432, yet severely is straining the data traffic: either by scanning every file that comes through, or only allowing a max. transfer rate?

I have no idea how you can TEST that. But do add PostgreSQL, port 5432, HoldemManager.exe, HMhud.exe, dbcontrolpanel.exe, to every exceptions list of every program that could possibly do that.


-

What do you mean exactly with a "separate logic drive"? (your database is on a logical drive/separate partition?) Did you test what happens if you create a new database on your primary partition, and import a couple of thousand hands?

[dvvv]

Ok. Thanks for suggestion, anti-virus has been installed recently (it even could be the day before I started to feel such speed decrease, could be the cause) I will try to switch it off or uninstall and test then. (btw I purged hands recently)

-

yes on my database is on a separate partition.
I will test this if switching off anti-virus does not help.

Thank you.

[Patvs]

Also in the postgresql.conf file, start by increasing the size of your "shared_buffers = xMB" and set it to 25% of your RAM.

shared_buffers = — Editing this option is the simplest way to improve the performance of your database server. The default is pretty low for most modern hardware. General wisdom says that this should be set to roughly 25% of available RAM on the system. Like most of the options I will outline here you will simply need to try them at different levels (both up and down ) and see how well it works on your particular system. Most people find that setting it larger than a third starts to degrade performance.

effective_cache_size = — This value tells PostgreSQL's optimizer how much memory PostgreSQL has available for caching data and helps in determing whether or not it use an index or not. The larger the value increases the likely hood of using an index. This should be set to the amount of memory allocated to shared_buffers plus the amount of OS cache available. Often this is more than 50% of the total system memory.

The default setting is 16 MB (or 32 MB) for shared_buffers...

Also check if the "max_connections" in postgresql.conf is set to default (=100).