xmemcached占用了大量的CPU

[GoogleCodeExporter]

这是我用jprofiler分析后的结果，看看是不是那里有问题，我��
�在memcached性能不是很好的说。

Original issue reported on code.google.com by Jun.T...@gmail.com on 7 Apr 2011 at 6:55

Attachments:

• xmemcached.jpg

[GoogleCodeExporter]

从这张图来看，只是证明批量获取操作非常慢，阻塞在io上了
，跟你获取的数据大小有很大关系，可以考虑缩小大小，压��
�之类，甚至做本地缓存，减少这种重量级操作。

Original comment by killme2...@gmail.com on 7 Apr 2011 at 7:15

[GoogleCodeExporter]

我的读取数据的大小非常小，譬如一个城市对象，就名称最��
�，最长也就varchar(50)

Original comment by Jun.T...@gmail.com on 7 Apr 2011 at 2:12

[GoogleCodeExporter]

在使用hibernate的时候，怎么禁用multiget?另外上面的图是我在��
�发大概100/s时候对jvm的检测结果。

Original comment by Jun.T...@gmail.com on 7 Apr 2011 at 2:14

[GoogleCodeExporter]

memcachedClient.setOptimizeGet(false);即可关闭这个合并get的优化，我
的建议还是不关闭，可以缩小合并因子看看
memcachedClient.setMergeFactor(50);   //默认是150，缩小到50

Original comment by killme2...@gmail.com on 7 Apr 2011 at 2:46

[GoogleCodeExporter]

不过从你的堆栈来看，貌似并不是xmc做优化合并，而是你本��
�就调用了批量获取的getMulti操作，从hibernate调用过来的。你��
�单个数据小，但是如果批量一次获取成千上万条数据，那仍�
��开销很大，可能你需要debug下看看为什么要批量获取这么多�
��据。

Original comment by killme2...@gmail.com on 7 Apr 2011 at 3:06

[GoogleCodeExporter]

我的调用时通过hibernate->hibernate-memcached->xmemcached,后面的基本�
��我无法控制。

Original comment by Jun.T...@gmail.com on 12 Apr 2011 at 5:01

[GoogleCodeExporter]

你应当去分析业务，是不是有这种批量查询的调用，这样的��
�询是不是该缓存，有没有必要等。这些问题跟xmc没有太大干�
��了，我关掉这个issue了。

Original comment by killme2...@gmail.com on 13 Apr 2011 at 5:57

• Changed state: Invalid