NYCPHP Meetup

NYPHP.org

[nycphp-talk] What with you do with 4Gig of RAM?

Rob Marscher rmarscher at beaffinitive.com
Mon Jan 21 21:16:16 EST 2008


On Jan 21, 2008, at 8:52 PM, Cliff Hirsch wrote:
> Have I asked this already?

I don't think so :)

> So I negotiated 4Gig of memory in my server. Hey, ya always got to  
> ask for a little “extra.” I got 15K scsci drives and know what to do  
> with them. The question is, what do I do with all that memory?

I have a similar server that I increased all of the mysql buffers on,  
gave 1GB to memcached (amazing how much you can fit in 1GB...  
especially compressed data), and then have a sphinx search server  
running on it as well.  Those three apps have been running pretty  
happily for 6 months now.  This server is strictly mysql, memcached,  
and searchd -- no apache... so there wasn't a real need for increasing  
apc's cache -- but if you are running a web server on yours...  
increasing APC is definitely a good thing to do.  In fact... if your  
app is entirely contained to this server, I'd recommend using APC over  
memcache because it's faster.  The main benefit of memcached is that  
you can access it over the network and it can be spread among a bunch  
of servers.  If you have multiple front-end servers, they can all use  
the same memcache -- the cache doesn't need to be repeated on multiple  
servers.

A side note about the mysql cache... I've learned that it's best to  
use it only on demand when you know that a query is cachable.  The  
cache gets invalidated every time an update/insert is made on one of  
the underlying tables (that's my primary reason for using a different  
cache solution -- I actually use a combo of APC, memcache, and  
sqlite).  Because of the way the cache gets invalidated, your wasting  
a lot of effort if you enable the query cache on sql statements for  
tables that change frequently.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20080121/153e5682/attachment.html>


More information about the talk mailing list