Still chasing performance/scalability issues. Two main findings: (a) The mem-pool patch[1] *is* strictly necessary to avoid serious performance degradation at higher brick counts with multiplexing. For example, on my normal test system there was little benefit at 80 bricks, but on the system I was using yesterday for longer-term higher-scale testing the multiplexed version took 2.5x longer to complete a test than the non-multiplexed version unless I applied the patch. Then, there was still a difference but it was only around 20% (and non-multiplexed was faster than before too). (b) With enough bricks, the new mem-pool code starts to exceed PTHREAD_KEYS_MAX. Therefore pthread_key_create fails, mem_pool_new fails, and everything turns ugly. To overcome this limit, I'm working on a new way of tracking and finding pointers to per-thread pools. [1] http://review.gluster.org/#/c/15645/ _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
