[Linux-cluster] Slowness above 500 RRDs
David Teigland
teigland at redhat.com
Tue Jun 12 16:17:09 UTC 2007
On Tue, Jun 12, 2007 at 05:43:24PM +0200, Ferenc Wagner wrote:
> David Teigland <teigland at redhat.com> writes:
>
> > On Tue, Jun 12, 2007 at 04:01:04PM +0200, Ferenc Wagner wrote:
> >
> >> with -l0:
> >>
> >> filecount=500
> >> iteration=0 elapsed time=5.966146 s
> >> iteration=1 elapsed time=0.582058 s
> >> iteration=2 elapsed time=0.528272 s
> >> iteration=3 elapsed time=0.936438 s
> >> iteration=4 elapsed time=0.528147 s
> >> total elapsed time=8.541061 s
> >>
> >> Looks like the bottleneck isn't the explicit locking (be it plock
> >> or flock), but something else, like the built-in GFS locking.
> >
> > I'm guessing that these were run with a single node in the cluster?
> > The second set of numbers (with -l0) wouldn't make much sense
> > otherwise.
>
> Yes, you guessed right. For some reason I found it a good idea to
> reveal this at the end only. (Sorry.)
>
> > In the end I expect that flocks are still going to be the fastest
> > for you.
>
> They really seem to be faster, but since the [fp]locking time is
> negligible, it doesn't buy much.
>
> > I think if you add nodes to the cluster, the -l0 numbers will go up
> > quite a bit.
>
> Let's see. Mounting on one more node (and switching on the third):
>
> # cman_tool services
> type level name id state
> fence 0 default 00010001 none
> [1 2 3]
> dlm 1 clvmd 00020001 none
> [1 2 3]
> dlm 1 test 000a0001 none
> [1 2]
> gfs 2 test 00090001 none
> [1 2]
!?!? but now you're using the old RHEL4 generation stuff -- gfs_controld
is completely irrelevant there. The analysis completely changes between
the RHEL4/RHEL5 (old/new) generations of infrastructure.
Dave
More information about the Linux-cluster
mailing list