restarting every night?

[Brandon Ooi]

Hi,

These machines are running 32-bit OS (but the chip itself is a 64-bit 
xeon). Memcached 1.2.2 with libevent 1.3b. I would expect it to be able 
to use up to 4gb of space but any more than 2 it seems to get unstable 
and crash.

I've tested this on a 64-bit machine and it seems to eat as much memory 
as we throw at it.

Is the moral of the story "use 64-bit"?

Brandon

Steve Grimm wrote:
> Which memcached version? Which system architecture (AMD64, etc.)? Which
> libevent version? If you were running it on a 64-bit architecture, was it
> compiled as a 32-bit app or a 64-bit one?
>
> Our memcached instances are all 13GB and they all run until we have to take
> the machine down or install a new version. We compile in 64-bit mode and
> memcached happily chews up all the memory we throw its way.
>
> -Steve
>
>
> On 6/6/07 1:01 PM, "Brandon Ooi" <brandon at hotornot.com> wrote:
>
>   
>> Hi,
>>
>> We've seen corruption too on some older linux kernels (2.6.11) with
>> memcache instances larger than 2gb (no idea why) this would cause weird
>> issues and if we kept using it would eventually crash by themselves
>> after a few days. we saw this on 4 different machines. When kept under
>> 2gb they seemed stable. Perhaps this is your issue?
>>
>> Brandon
>>
>> Brian Moon wrote:
>>     
>>> andrew at flypublishing.com wrote:
>>>       
>>>> A friend of mine says he restarts his memcached servers every night
>>>> because after a few days the data gets corrupted.
>>>>
>>>> Is this common practice?  Does anyone have experience running
>>>> memcached for months on end with no data corruption?
>>>>
>>>> Thanks.
>>>>         
>>> STAT uptime 5610211
>>>
>>> That is 65 days.  And we took it down then to physically move the
>>> server.  We don't even think about it.  It just runs.  No issue with
>>> "data corruption", whatever that means.
>>>
>>>       
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070607/4e30d414/attachment.htm