"phpguy99" wrote : | I haven't changed my code to spread objects further down the tree. | BTW, this seems odd or I may have missed something, but shouldn't the cache system do this spreading behind the scene? Depends on the key of the objects to cache, it could be difficult to balance the tree. And to know the "path" before I can do a "get". It's much simpler to do straight "key" lookup. (just my 2cents) |
Could you tell us about your access patterns? How often do you insert? How many simultaneous writers will you have on the same server/process? A node currently has 4 segments, so it's tuned for allowing 4 simultaneous child node inserts. So, only if you have > 4 concurrent threads (more than 4 cpu cores) all inserting at the same time, that could become a bottleneck. If this is the case, and you need to spread, you don't really need to do active balancing, just a simple modulus of a spread would work fine. Like | x = ID % 10000 | fqn = /x/ID | We do plan to make this concurrency level configurable in 3.0, so you won't need to spread things out if you don't need to. anonymous wrote : | Back to performance and memory. | It's stable now with 2 nodes. The rate of my insert is increased from 2000/s to 4000/s. This is one at a time and SYNC that is 0.25ms/operation which is very good and multithreaded should increase this by a lot (I hope). | But the memory consumption is still very high (maybe b/c I put everything right under "root"). 4GB for my 1M objects | You are still experiencing JBCACHE-1383. Which causes 16 CHM segments and locks to be created per node. The update reduced it to 4. It is not yet in a release, although you can build the latest 2.2.x branch if you want. The MVCC locking mode in 3.0 completely eliminates the 4 CHM segment and lock overhead, so you might want to give that a try. anonymous wrote : | I constantly see: | 2008-07-23 10:09:47,929 [Incoming,JBossCache-Cluster,10.57.132.54:38174] WARN org.jgroups.protocols.pbcast.NAKACK.handleMessage - 10.57.132.54:38174] discarded message from non-member 10.57.132.53:33187, my view is [10.57.132.54:38174|0] [10.57.132.54:38174] | This could indicate you have other traffic on the same multicast address. You might want to make sure the nodes in your cluster are the only ones using that address. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166265#4166265 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166265 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
