Best setup for upgraded system, splitting up data-logs-index

[scbrigad]

Hi all,

Ive been reading the forums on raid setups and other ways to speed up PT3/postgres so I decided to take the plunge in upgrading my desktop. I have a new 80gig Intel SSD drive(to go with my 250g 10k drive), a 3.16GHz Core 2 Extreme QX9750 Quad Core, Intel LGA775 G45 / ICH10R motherboard (on-board RAID for future upgrades) with new 4gb 1066MHz DDR2 memory(expandable to 8g+ when i move to a 64bit OS, only using 3g for now running Win XP 32bit).

I was going to go with 2-4 10k drives in RAID0 but from the research ive done it really seems like the new Intel SSD drives are going to be faster than a 2-3 10k/15k drive raid setup since access time is so key with database transactions... I'm far from certain about this and haven't seen much of any posts about comparing SSDs with various RAIDs in postgres... but as SSD pricing comes down and i need more space I can add 1-2 more 80g intel ssd's in Raid0 (not concerned about data loss) which most reviews say ssd's raid quite well together. Anyone else running PT3 on a non-writing-challenged SSD yet?

So if these upgrades sound ok (i can still make changes at this point, building it this weekend), I can use some help figuring out the best setup with my databases. At the moment I have 7 databases on two sites. 2 for played hands on each site and 5 for observed hands of various game types. My database will soon max out the 80g available on the Intel drive even if there was nothing else on there. Since I can't afford a second 80g drive to RAID0 at the moment, I'm trying to figure out the best layout between my 250g 10k and the 80g SSD.

So from reading another thread I can use 'initlocation' to move some of the databases to the new drive, or just create symbolic links like MiamiVice80 did... Would the best option for two drives be to move the data to the SSD and leave the logs and index on the 10k? Will it really make a big differnce adding a third drive to be able to split the data, logs, and index?

Would you suggest loading the OS and/or other key poker apps on the SSD to speed them up or leave it dedicated to postgres data and PT3?

I am also considering running Windows Server 2005 instead of XP with multiple terminal sessions, or running XP with Microsoft Virtual Server 2005 R2 (if splitting up the 3g RAM available in 32bit XP dosent slow things down too much) to save on the power bill of running multiple systems when datamining. For those who have done this I am open to ideas on which would be a better solution for my setup.

Thanks,

Scott

[heynow21]

I have the X-25 too, *high five*. i've stuck my head in the sand about my expanding poker tracker databases, I was hoping I could use Network Storage for that but I'm waiting to cross that bridge till I get to it.

[kraada]

Those upgrades sound like they'll give you a beast of a machine. I haven't heard of any benchmarks for people with SSDs as of yet since they're just starting to come down in price, but please do let me know how things turn out for you once youg et things up and running. I definitely recommend splitting the logs and the data. If there's room, putting the data on the SSD is probably best, as that's what you need the fast seek time to grab. If it won't fit, then it obviously has to go on the 10k drive and then I'd put the logs & OS on the SSD (you might as well get the speed boost from having fast access time on your OS files if you've got the room).

You can also put some data from databases on one drive and some on the other; one setup you might want is this:

SSD: OS, played hands database

10K: Logs & observed hands databases.

This way you'll get the fastest seek times when you want to run analysis on your own play, and you have as much room as you need for your observed databases. The logs will make things with the observed hands databases slightly slower but if you update the cache after doing big imports of datamined hands there won't need to be a lot of data grabbed from the observed hands databases (as the cache hits aren't that strenuous). If you then expand to another 10K drive you can move the logs over there and get the performance gain from having those split off as well.

I'm not 100% certain what is the best simply because your exact usage patterns matter here. If you run a lot of queries on your observed hands databases (going around and looking at what opponents do when you're not around), you might care more about improving speeds on those drives, etc. But that's what I'd do, for what that's worth.

[MiamiVIce80]

Kraada is 100% right, but I have some small additions. Actually it really depends how many different databases u have and how u will use them.

From my point of view the best performance is build bottem up. The more spindles u have, the more options u get.

I would always split OS and pagefile and move the /pg_xlog folder to a different drive.

After that it really depends on your way of using PT. If u use many different databases i would spread them to different drives, cause multiple reading will speed things up. With only 2-3 databases i would try to split log / index /data to different harddisks.

But after a lot of tweaking i would not go for Windows and it doesnt matter if it a 64bit Microsoft OS.
Postgres is a 32bit application and doesnt perform well on Windows. Even Vista 64bit is not able to assign more than 2GB to a single thread. Postgres has some ristrictions as well and 8GB doesnt give a great boost.

I´m not sure what i will do but the obly way to get real performance is to run postgres on a Linux-Server and use an cheap office PC as terminal running Windows the get access to your poker site.

Or u run postgress on Linux and use a VM to run Windows and play. Some people already announced that they run that kind of system.
Maybe someone using Linux+Windows could post some details how fast his setup is by running pgbench or import 1mio hands into a big database.

[kraada]

Actually I run linux with a Windows VM. I've actually got Win2k in the VM (I've used this particular VM for a while; I should get around to upgrading to XP at some point), and I'm running Ubuntu 8.10 on the machine generally. Windows is pretty much just for PT3 & poker software. I just have one hard drive, it's a 7200RPM drive, and I get ~70h/sec importing when importing large groups (I've imported 1M+ hands this way). With the new cluster improvements which will be in the next Beta, cluster time takes about 30 min for a 2M hand database, vacuum/analyze is in the 1-2 min range, and update cache is another 30-45 min.

I have no lag while playing at all in the VM playing up to 8 tables at FTP. The machine is a Core 2 Quad Q6700 machine with 8G of RAM, running 2.6.27-11 x64 (I'm due for a kernel upgrade, but I haven't rebooted; I hate rebooting).

I'd be happy to run any benchmarks you'd like to see, Miami, are there any particular settings you'd like me to use with pgbench?

[LVgamb00ler]

I just finished a post on how to save space on observed hand DB's. This would be very useful to SSD users.

Let me try and link to it:
http://www.pokertracker.com/forum/viewtopic.php?f=15&t=16258

Hope that worked

G'luck all,
LVgamb00ler

[scbrigad]

Thanks guys.... I'll let you know how it turns out when I build it this weekend. Rereading my post I must have had Raptor's on the brain from comparing them to SSD's as my current 250g Hard Drive is a 7.5k not a 10k.

My thoughts are to do these upgrades incrementally, so for now I'm looking for a two drive solution but I'll hopefully upgrade it another spinner or SSD sooner or later so I can split the index, logs, and data. (Although at that point is splitting these going to be faster than running a RAID0 on the two spinners or two SSDs with my new motherboards built in RAID?)

I know Linux is always going to be faster but for now this is not a dedicated server, some of my play will be from this desktop as well and possibly doing other things so sticking to a Win OS would be optimal if I can make it fast enough for my purposes. I'll start with running Windows Virtual Machine with instances of TinyXP for the dataminers all writing to subdirectories of the Hand History folder, then let 1 instance of PT3 recurse them in auto-import mode (2 if mining both limit and NL observed tables). I have a friend who has already done this and said it works well.

So with the VM setup allowing one instance of PT3 to import from multiple poker clients, I envision condensing the observed DB's down to only "Observed Ring Limit" and "Observed Ring NL" (unless perhaps leaving them more split up increases efficiency?) and of course my "Played" database... Is there a way to combine databases in PT3 yet or in the near future (I dont have alll my processed files to recreate them)?

I am running 2 client instances mining to the observed limit and 2 clients mining to observed NL and only have two drives, so yes I could split these two databases across the SSD and 7.5k drive... would this really be faster than putting all the data on the SSD and splitting the index & log to the OS 7.5k drive? I'd really love to leave the OS on the SSD too if it wouldnt slow things down too much but it sounds like it would. I suppose I could bite the bullet now and buy another 7.5k or 10k drive now but I'd rather wait 6mo until the SSD's come down in price more and my database grows >80g...

LVgambl00r your idea may come in very handy for condensing the DB in another couple months, thanks.

Regards,

Scott

[kraada]

I'm not sure if splitting the data up vs using Raid 0 is a benefit, I haven't done any tests personally on this one (lacking a computer with RAID), so I can't give you a concrete analysis there.

There isn't yet any way to combine PT3 databases short of importing hands from one into the other. Splitting up the databases only increases efficiency for things like reports run on a given database as for any report the larger a database you run it on, the longer it will take. Most people (myself included) only run large reports on played hands, or would want to run it on all observed hands (like the "Is it ever +ev to get it all in with KK PF?" question that pops up every now and again), so while splitting them up to Limit an NL makes sense, I wouldn't split them up without a reason to do so beyond that.

Another option that I just thought of which is a little odd and perhaps counterintuitive but might work well is:

Put the played hands DB on the SSD with the played hands DB's log and index on the 7.5k. Then put the observed hands on the 7.5k disk -- and it's logs & index on the SSD. Unless you're importing to both simultaneously -- which seems unlikely, as I presume you stop datamining for the few minutes while you're running a session -- you'll get the full benefit when importing to each drive of having the logs & index split off. Your datamined DB will get all of the extra space of the 7.5k disk. Your played hands DB will get all of the benefit of being on the super fast drive for when you want to go into PT3 and actually do some analysis. And the logs from the observed hands database can be deleted routinely to save space on the smaller drive (as postgres logs can get large depending on how you have them configured).

I'm not sure this is optimal but it's a suggestion that hadn't come up and it just occurred to me so I thought I'd throw that out there for you

[MiamiVIce80]

I´m running a raid0 system atm, but with no reliability (for testing)

2xraid0:
1. raid0: 2xSeagate ST3250410AS (2x232.8gb) (OS and pg_xlog)
2. raid0: 2xWD 6400AAKS (2x596.1gb) (postgres-data)

on a Intel E6750 with 8GB running Windows Vista Buisness 64bit (splitted logs and data, tweaked postgresql.conf)

I get an import speed of about 500h/s on average. Still having problems with housekeeping, cause big databases causes a lot of hard faults, cause postgres can´t keep more than 1gb in memory and my normal database tables are around 10gb.

Maybe we could get some more result to compare different setups.

[scbrigad]

Well I'd be happy to compare stats once I actually the the database working again... I got the new motherboard, CPU, and memory installed this weekend and the XP Media Center OS did not require a reinstall, which I thought was nice at first... Postgres and PT3 seemed to still work fine so I moved the whole postgres directory over to my new X25-M drive and reinstalled Postgres... as far as I can remember this still worked fine, and my problems started when I created dynamic links using the suggested "junction" app for "pg_log" "pg_clog" and "pg_xlog"... I now cannot get postgres to start without immediately crashing. I have tried removing the dynamic links, reinstalling the postgres app, reinstalling the service, using multiple versions of my database data directory (which I had as a backup on another drive, and that backup had been used for successful reinstall before) but nothing seems to fix the postgres crashing issue besides reinstalling with a completely new initialized database. This happens regardless of which drive I use, which copy of the database I use, even which postgres isntall package I use so I am totally out of ideas other than rebuilding the parts of the database that I have have processed hand histories for.

I'm thinking this all had something to do with postgres/XP not liking a change in the system's motherboard, CPU, or memory but I dont see any log files to debug it being generated, and the postgres install verbose logs didnt offer much help (look the same as a clean install). I just don't see how those temporary dynamic links could have corrupted anything, but maybe the registry got messed up and it's not being fixed with the reinstalls.

The only thing I can think of is to reinstall the OS for the new motherboard to clean off any drivers and such for the old motherboard, but I don't want to do that unless I really think it would help since its about as much work as rebuilding my whole database. But then why would postgres work fine with a newly initialzied databse?

Blah... On a side note the extreme processor, new board & memory seem to make a for a lightning fast combo with the new X25 drive. I can't wait to see how it handles my mega-database. I just hope I haven't torched the half of it which I don't have hand histories for.