I have questions (and answers too)

head wrote:
any idea what might be causing the performance problem?
      
What version of memcached are you using?
    

I am running the newest version of memcached available, that is
actually 1.4.1

  
What type of application/client are you using (PHP, Perl, Ruby, etc...) ?

  
If you do a quick strace of the process, is it calling epoll_wait (and
similar) or select()/poll()?
    

I am kind of beginner admin so I am not really sure on how to do the
strace, 

All you need to do is start memcached with "strace /usr/local/bin/memcached...". It spits out all the low level calls a binary is making.
also at this moment I am unable to replicate the problem
because we stopped using memcached after this problem showed up

When I add memcached to my script the entire *website* I run go down
in a matter of 5 minutes, if you really need this info to find my
problem I will run memcached again to find out

  
I'd have to see your script to see what the deal is :)

  
Can you verify that yor host is not using any swap, and is not actively
swapping? (watch vmstat 1 for a minute or two, the si/so columns).
    

The host is not using any swap (zero) I am 100% positive, there is
more than 6GB of ram free at the moment of a problem and cpu usage is
minimal

  
Are you using large multigets at all?
    

I have no idea what is "multigets", care to explain?


  
Depending on your client, you will have a "get" and a "multi get" call. "get" fetches a single item whereas "multi get" call returns multiple items (given a list of keys). For instance, Perl's Cache::Memcached client has an "mget()" and a "get_multi()" function.



  
Finally, can you pastebin the output of "stats" and "stats settings"
somewhere? (assuming you're on 1.4)
    

I am guessing you need this for a server at the moment of performance
decline, right?
  

Reply via email to