first time user with out of memory question

[Garth Webb]

On Mon, 2006-06-12 at 10:59 +0200, Janning Vygen wrote:
> Am Montag, 12. Juni 2006 10:42 schrieb Garth Webb:
> > On Mon, 2006-06-12 at 09:48 +0200, Janning Vygen wrote:
> > > Am Sonntag, 11. Juni 2006 15:24 schrieb Ivan Krstic:
> > > > Janning Vygen wrote:
> > > > > and stats slab produced "out of memory" message, too. At this time it
> > > > > was impossible for many users to login to our web application.
> > > >
> > > > If memcached failure means your users can't log in, then you're using
> > > > it incorrectly.
> > >
> > > Why? You could say same thing about disks: If disk failures mean your
> > > users cant login, then you're using disk incorrectly.
> >
> > There's an important difference here; if something disappears from your
> > disk, its a failure.  If something disappears from your cache, then it
> > was probably pushed out, or the cache was cleared, or the cache was
> > turned off, etc, etc.
> 
> it would be fine if data disappears. But memcached should not send "out of 
> memory" when i try to set a value. It should push out older data. so i argue 
> that disapearing data is ok in case of a memory cache, but i should always be 
> able to save data in any case.

This is a tuning issue.  You might want to pre-populate your cache with
the largest value you think you'll receive.  This should create a slab
that can hold anything you might get.  Right now your slabs are probably
used up storing small sized data and then you get a large amount of data
that needs to be saved.

> > The point here is that a cache under normal conditions is non-permanent,
> > non-guaranteed storage with many possible ways data can disappear.
> > Under normal conditions, disk must be permanent and guaranteed.  Memory
> > under normal conditions must be guaranteed, and permanent while the
> > power is on.
> >
> > If you rely on memcached to store something permanently, then you risk
> > data loss under normal, non-error conditions.  This is why it is not a
> > good design to rely on a caching system as the only place data is
> > stored.  Any system using a cache must have permanent canonical storage
> > for that data.
> 
> I dont rsik any data loss. the user ist just logged out. Thats ok for me as 
> the oldest (session) record is normally not needed anymore.

Data loss was the example failure mode.  In your case the failure mode
is a system that is unusable because every submit button and every link
takes the user back to a login screen.

> > In the case of session management, memcached will make access to your
> > session data faster by eliminating the need to query the disk or the DB
> > on every request after the session is initially created.  However, if
> > the cache experiences a miss or is down, the session management should
> > fall back to disk or DB automatically.
> 
> Yes your are right, and i am searching quite a while for a good solution for 
> php session management. And i thought memcached was the best solution but 
> maybe i have to search for something different, but as fast and distributable 
> as memcached.

I think you're still confusing what caches are good for.  If you want
reliable, distributable session management data store, then use a
database; PostresQL, MySQL, etc.  Once that is working, you can then
make that system faster by adding a caching layer *on top* of your
existing session management system.  If you abandon memcached and look
for another caching system to use exclusively for session management,
you are going to encounter the same problem all over again.

Garth