[horde] Memcache server questions

[Steve Devine]

Quoting "Andrew Morgan" <morgan at orst.edu>:

> On Wed, 12 Nov 2008, Steve Devine wrote:
>
>>  We are about a month away from full release of our Horde
implementation.
>> Twice we have had hard failures of our session management system.
>> We are using memcache on a separate server. Its a SunX4100 with  
>> 8gigs of available ram, we gave memcached 4Gigs to use and it had  
>> been running fine. Yesterday our Communication manager sent out a  
>> huge mass mailing inviting people to try the system and after an  
>> hour it went right in the tank.
>> We are in the process of getting another machine to run memcached
on
>> line so we can do failover but this whole thing spooks me a bit.
>> I have read many times on this list that memcache is the best way
to
>> handle sessions on a large installation. Is this still the feeling

>> of the list?
>> One of the problems is when the apache server cannot write the  
>> session it just hangs and the user gets a blank screen. Soon it  
>> seems to cascade out of control and stopping and restarting the  
>> memcache process did not seem to help.
>> If I decide to abandon the memcache server in favor of mysql am I  
>> heading down the same road? Anyone out there with experience in  
>> either of these methods care to comment?
>> Thanks
>> /sd
>
> I've been running memcached on a Sun x4100 with 8GB of RAM.  I
gave
> it 2GB of RAM because this machine also runs our MySQL instance for

> Horde.  I'm running Debian Etch, stock packages.  It has been  
> rock-solid for us.
>
> Can you be more specific when you say "it went right in the
tank"? 
> Did memcached stop responding?

Yes as near as I can tell it did. The main page would display but you  
couldn't get much further that that .. I know part of my problem is I  
just don't have enough experience with memcache and this kind of high  
volume traffic. My web servers were all pegged at 259 processes. That  
one issue .. I think I have to compile apache to allow more servers.  
We are running quad core machines with 8G ram.

>
> Sessions are really really hard on MySQL.  The session table is  
> updated so frequently that it is almost never able to use the MySQL

> query cache.  You can also have locking problems unless you use  
> InnoDB tables.  Even still, every session update must be written
to
> disk, which is a lot slower than memory.  Last time I checked, it  
> isn't possible to use memory-based MySQL tables for the session
table
> either (locking not supported? I forget).
>
>         Andy

 

Steve Devine
Email & Storage
Academic Technical Services
Michigan State University

313 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327