excessive HUD CPU usage (Beta 14)

[keggler]

for some reason, a single postgres.exe process is doing all the "work." its I/O reads, writes & other, along with its page faults, are constantly increasing. it's also the only one using the cpu, most of the time.

this is because postgres is not a multi-threading rdbms and you probably have just the one active connection...


susan

[six4withafro]

i think 512 is way too high - i would not go above 128 even for a large dataset and 2GB of ram; try lowering max_connections to 25.

Postgres counts a lot on the OS to cache data files and hence does not bother with duplicating its file caching effort. The shared buffers parameter assumes that OS is going to cache a lot of files and hence it is generally very low compared with system RAM. Even for a dataset in excess of 20GB, a setting of 128MB may be too much, if you have only 1GB RAM and an aggressive-at-caching OS.

Remind me, how big is the dataset? and is this a localhost db?


susan

i have that article bookmarked. unfortunately, the default setting or anything close to it thrashes my hdd. ive found several newer articles on resource allocation that suggest playing around with the number to find the right one. 768MB is too much, but with 512 I see very little HDD or CPU activity. I'll try changing max_connections and see what happens

idk how big the dataset is; are you looking for the number of hands or size in GB? (it's definitely GB, that much i know)

yes, it's a localhost db.

and now today, my stats aren't showing up on the table, ever. i played a tourney for 2 hrs and they never appeared, although everyone else's did.

edit: 934k hands

[keggler]

so we have around a million hands? and the dataset in GB is?

can you post up a procexp grab (same columns) when you've got shared buffers at 512 - i take it the last grab was 32 (please leave that one uploaded btw)

so then we'll have 2 snap-shots where the only change is shared buffers, yes?


susan

[six4withafro]

hi susan, thanks again.

i created a new db with just one cash-game limit (except for 500 accidentally imported older hands ) that has only 132k hands in it currently, and that plus 512mb buffers has resolved my issues for now.

tomorrow i will import into the old 934k hand db with the HUD running and get another procexp screen grab with the new buffers.

how do i tell how large that 934k-hand db is? there are 6 folders in my 8.2\data\base folder, so i don't know which one would correspond to that db. it contains 3 dbs in all (2 pt3 and 1 pt2) and totals 11.1GB in size.

[six4withafro]

here is the screenshot of the import using 512mb buffers. http://img396.imageshack.us/img396/4613/clipboard03ur6.jpg
the max connections number also is different (25, not 200), but since there's only 9 connections i don't think that matters. the topmost graph history in procexp is I/O, which is minimal. idk if you can tell, but cpu activity is still greater than normal with the larger db, and after 90 minutes or so it becomes unwieldy (50%+). that's why i thought how long i'd been importing might matter.

[keggler]

been away at a conference for 2 days - will take a look at your latest posts tonight...


susan