We have a bunch of boxes running memcached. Some are 32-bit and some are 64-bit, but all run a 32-bit install of RHEL due to various Perl-related things. We'll call them type A and B respectively. Both types run memcached 1.2.8 with the same amount of memory allocated via the -m
switch. Every memcached instance contains the same data -- in this installation we're not using it as a distributed hash but a local store on each machine. A separate process is responsible for seeding each instance with fresh data at a regular interval.
Today we noticed all the 64-bit machines had started evicting items:
Type A, 32-bit
STAT curr_items 115208
STAT evictions 0
STAT limit_maxbytes 67108864
Type B, 64-bit
STAT curr_items 122192
STAT evictions 1049488
STAT limit_maxbytes 67108864
Initially I thought the type B machines were using more RAM but I was misunderstanding the rusage
stats (see edit history). Any ideas why the type B machines would start evicting before the others, even with the same data seeded at the same time as the type A machines? Is it down to the underlying hardware being 64-bit? I'm displaying a shameful ignorance of computer hardware here but there's only one way to fix that.
If both A- and B- types are on 32bit OS, there should be no difference in object sizes for userland apps like memcached. Differences could be seen for kernel if PAE is enabled/disabled, but even that should not affect userland memory usage.
Could you post full output of
stats
,stats sizes
,stats items
for both types? (Two last can take long for large memory, but at 67M that's not your case).And, sure, initial output of
memcached -vv
.