On Fri, Mar 13, 2009 at 1:21 AM, Stefan de Konink <[email protected]> wrote: > Grant Slater wrote: >> Summary: >> 2x Intel Xeon Processor E5420 Quad Core >> 32GB ECC (max 128GB) >> 2x 73GB SAS 15k >> 10x 450GB SAS 15k (expensive, but stupidly low latency) >> IPMI + KVM > > Maybe a stupid question; but is your database server able to exploit the > above configuration? Especially related to your processor choice.
yes. > Now it is nice you put 32GB (extra expensive) memory in there, but most > likely your hot performance would be far better with more (cheap) memory > than more disks. there's a good reason why we are using good quality server-grade memory in the OSM server. would we like more memory - of course! thats why grant has very sensibly left 8 slots free. > At the time I wrote my paper on OSM Dec2008, there was > about 72GB of CSV data. Thus with lets say 128GB you will have your > entire database *IN MEMORY* no fast disks required. in 8Gb kits? that would be *extra* expensive (about £8,680 according to froogle). > ...or are you actually moving from OS to Solaris to utilize those 10 > disks for your lets say less than 100G worth of geodata using them as > duplicates in the pool [opposed to integrity duplicates]? partly, yes. RAID10 uses a mixture of striping and mirroring to increase performance without sacrificing reliability. cheers, matt _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
