Memcached缓慢获取，高CPU使用率 [英] Memcached slow gets, high CPU usage

问题描述

我在计算机上运行了一个memcached实例来减轻数据库的压力. 目前，通过PHP每秒大约有350个请求，根据memcached文档，这应该是完全可行的，但是我看到的get()时间太短了.平均约60毫秒，两种方式都有尖峰(0.1毫秒和250毫秒).

I've got a memcached instance running on a machine to take the stress of the database. Currently there are about 350 requests per second via PHP, which should be perfectly doable according to the memcached docs, but I'm seeing ridiculously slow get() times. Averaging around 60 ms, with spikes in both ways (0.1 ms and 250 ms).

memcached进程也一直使用大约80％的CPU.由于将所有内容组合在一起需要花费5秒钟才能完成页面，因此这确实变得很麻烦.

The memcached process is also using around 80% CPU all the time. It's getting really problematic as with all the gets combined it takes over 5 seconds for the page to complete.

我很确定这是get命令，因为我已经在代码中注释掉了，数据库接管了该任务，使memcached进程使用了​​0个CPU.

I'm pretty sure it's the get command as I've commented out in the code and the database takes over, making the memcached process use 0 CPU.

以下是统计信息:

stats
STAT pid 617
STAT uptime 855901
STAT time 1370358572
STAT version 1.4.5
STAT pointer_size 32
STAT rusage_user 15472.778988
STAT rusage_system 38712.971409
STAT curr_connections 175
STAT total_connections 4423163
STAT connection_structures 252
STAT cmd_get 319670822
STAT cmd_set 48996864
STAT cmd_flush 0
STAT get_hits 233440856
STAT get_misses 86229966
STAT delete_misses 11025386
STAT delete_hits 11131141
STAT incr_misses 27702934
STAT incr_hits 19471007
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 25484001864
STAT bytes_written 77617943971
STAT limit_maxbytes 201326592
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT bytes 47135355
STAT curr_items 539471
STAT total_items 21293860
STAT evictions 3183365
STAT reclaimed 3222011
END

和设置:

stats settings
STAT maxbytes 201326592
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 11211
STAT inter 127.0.0.1
STAT verbosity 0
STAT oldest 0
STAT evictions on
STAT domain_socket NULL
STAT umask 700
STAT growth_factor 1.25
STAT chunk_size 48
STAT num_threads 4
STAT stat_key_prefix :
STAT detail_enabled no
STAT reqs_per_event 20
STAT cas_enabled yes
STAT tcp_backlog 1024
STAT binding_protocol auto-negotiate
STAT auth_enabled_sasl no
STAT item_size_max 1048576
END

现在我将memcached配置错误吗?还是还有其他事情发生?

Now did I configure memcached wrong? Or is there something else going on?

根据要求，这是带有get的代码(没有太多内容):

On request, here's the code with the get (there's not much to it):

function getItem($memcached, $key, $id) {
    $md5key = md5($key.":".$id);
    $v = $memcached->get($md5key); // changing this to $v = false made the memcached CPU usage go to 0
    if ($v === false) {
        //code that fetches the correct data for each key, stores it in memcached and in $v.
    }
    return $v;
}

在主脚本中有以下内容:

And in the main script there's the following:

$memcached = new Memcached;
$memcached->addServer('localhost', 11211) or die ("Could not connect to memcached server");
$memcached->setOption(Memcached::OPT_COMPRESSION, false);

$myItem = getItem($memcached, "key", "123");

由于某些原因，我仍然注意到数据库的高负载.现在，当我通过telnet手动检查要在缓存中显示的数据时，就很好了.可能是memcached客户端认为与缓存的连接正在超时，因此转到数据库了吗?那将使我想到一个问题，为什么连接到底在超时...

For some reason I'm still noticing a high load on the database. Now when I manually check for the data to be present in the cache via telnet it's just fine. Could it be that the memcached client thinks the connection to the cache is timing out and hence goed to the database? That would leave me with the question why on earth the connection is timing out...

推荐答案

好，我发现了问题！ 为了了解每秒的请求，我使用了那里的memcache.php文件.它告诉我每秒有350个请求.事实是，过去几天的使用量已经大大增加，每秒请求数实际上只是整个正常运行时间的平均值.通过(点击次数+错过的次数)/正常运行时间计算得出. 现在，重新启动内存缓存后，该平均值将返回更多正确的值，并且实际上每秒有4000个请求.

Well, I've found the problem! To get an idea of the requests per second I used the memcache.php file that's available out there. It told me that there were 350 requests per second. The thing is that there has been quite an increase of use in the past few days, and the requests/second is really just an average over the entire uptime. Calculated by (hits+missed)/uptime. Now after restarting memcached this average returns more correct values and there are actually 4000 requests per second.

tl; dr:第一篇文章中的统计信息有误.正确的统计数据是:4000个请求/秒.

tl;dr: Wrong stats in first post. Correct stats are: 4000 requests/second.

我想我的硬件根本无法解决这个问题.

I suppose my hardware simply can't cope with that.

这篇关于Memcached缓慢获取，高CPU使用率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！