Re: Building an home computer for best Poker Tracker performance

On 21/07/11 23:03, mdxxd wrote:

> I'm still not sure what should I get. If i understand correctly Greg
> message, despite my workload, i7 won't have much benefit for me and I should
> get i5(i7=4 cores with HT=8, i5=4 cores)?

Probably, yeah. To be sure, you should *measure* your current workload.
Get an idea of how many concurrent queries you have running and whether
they're limited by CPU time or disk access.

You're trying to ask for an answer without providing all of the
question. The whole question is "Given my current workload, which looks
like <this>, THEN what kind of computer should I get?"

Great hardware for one workload can be crappy hardware for another workload.

Greg knows about Poker Tracker, so he's probably going to be much more
able to guestimate what you need without sufficient information. Follow
his advice when in doubt.

> From Scot/Craig I understood that I'm going to want to have my whole DB fit
> into my RAM. But I don't think it is possible, even with 16GB RAM. From Greg
> I understood that I only need the data that is being processed to fit into
> my RAM. So i'm a bit confused. Should I get 8GB or 16GB?

To answer this accurately, you need to know more about your database.

How big is it right now? In bytes on disk? use pg_database_size() :

http://www.postgresql.org/docs/current/interactive/functions-admin.html


Are all the tables used frequently? Or are some of them "history" tables
that are less used? You can use some of the statistics PostgreSQL
collects to find out more about your use.

http://www.postgresql.org/docs/current/static/monitoring-stats.html


What you need for best performance is to make sure that all the
_heavily_ _used_ parts of the database fit in RAM. This might be all the
database, or it might only be a small fragment of it.

If you cannot achieve that, then you need to make sure that your indexes
fit in RAM and that you have fast disks. Whether you need fast
sequential access, fast random access, or both depends a lot on your
query patterns.

> SSD:
> This one is the most tricky. I read that consumer SSD is not reliable
> enough(can have BSOD, can cause in data corruption, in case of power
> shutdown data might be lost etc), also I read that SQL will tear-up a
> consumer SSD.

Greg notes that the Intel 320s are a safe(ish) consumer SSD, but they're
buggy at the moment - see Greg's post today - so they should be used in
RAID 1 or with extremely frequent backups.

As for SQL "tearing up" an SSD: It has nothing to do with SQL. The point
is that SSDs have a LIMITED WRITE LIFE. You can only write and overwrite
so much data before they'll die. Exactly when is unpredictable, but
it'll happen sooner the more you write to them.

A read-only SQL database won't affect an SSD at all. A read-mostly
database probably won't generate anywhere near as much write activity as
your regular Windows updates, program updates, work with documents,
temporary file access, etc. It's only when working with databases that
are quite write-heavy (especially REwrite activity) that can cause
issues. Even then it's hard to kill most SSDs within a couple of years
unless you're unlucky.

The answer here is: Get ones that're power-loss safe like the Intel
320s, run them in RAID 1, and keep backups.

> Therefore i'm not sure what should I do. Getting 2 7200 rpm
> hdd's in raid 0 will still cause big bottleneck right?

You haven't provided enough data to answer that.

If your DB can fit in RAM, or at least the heavily used parts can, then
a single 5400RPM disk might be good enough for a low write load! If it
doesn't fit in RAM, there's no such thing as storage that is too fast.

> Getting an SSD and
> UPS for power shutdown protection should cut it or is it still not reliable
> enough and prone to failure(or slowing down due to massive write)? What
> should I do?

Keep good backups.

--
Craig Ringer