Hi Matthew, Kinda derailing here, but are you only going to run memcached on that server? If so, you really do not need the CPU power, spend the money on RAM instead.
/Henrik Schröder On Tue, Jul 1, 2008 at 10:30 PM, Matthew Drayer <[EMAIL PROTECTED]> wrote: > So, most likely our official deployment will be to a 64bit Linux machine > which would initially have 2GB of RAM and two monster CPUs. If situation #2 > isn't an issue, would it be best to run a single instance of Memcached, or > split the RAM into two instances? > > > ------------------------------ > > *From:* Stephen Johnston [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, July 01, 2008 4:26 PM > *To:* Matthew Drayer > *Cc:* [email protected] > *Subject:* Re: Multi-instance on Win2K3? > > > > I think that CPU is rarely why people do this. From what I've seen and read > there are a few common cases: > > > > 1. You have 384mb on one machine and 128mb on another available. You make 4 > instances so their eviction pattern is similar and the client can treat them > as identical, and your expected behavior for them will be similar, and write > across them equally without a 384mb <-> 128mb pair of server causing wierd > imbalances. The clients that I have seen don't take cache size into account > when considering which instance to use. > > > > 2. You have a situation where you store items with no delete time (they > live for ever), but you have limited memory. your no delete time items are > expensive to recreate. You also have alot of less expensive items to > recreate that may lead to your expensive ones being evicted. You use one > instance sized for the items that live forever and another for the ongoing > "evictable" items. > > > > I'm sure others have some use cases, but those are the two I've seen > mentioned commonly. > > > > -Stephen > > On Tue, Jul 1, 2008 at 4:17 PM, Matthew Drayer <[EMAIL PROTECTED]> > wrote: > > Probably not at such a low level, no J but, this was more for a > proof-of-concept to show my team how it might work. I assume we'll only > distribute out if we find we're pushing the limits of RAM or CPU > utilization. > > > > Matt >
