I'm trying to get gluster working on a test lab and had excellent success setting up a volume and 14 bricks on the first go around. However I realized the reasoning behind using a subdirectory in each brick and decommissioned the whole volume to start over. I also deleted the /var/lib/glusterd directory and removed/installed the necessary gluster packages. I'm running Scientific linux 6.4 with all recent updates. Upon recreating the new volume with the new brick, I found the process very very slow, about 2-3 minutes to process the change. Adding additional bricks also takes the same amount of time as well as simple set parameter actions. This was with a distributed volume with only one host involved. I notice in the cli log file, it constantly complains about not being able to guess the transport family, which an online search for the error or parts of the error only brought up issues that apply to older versions of gluster. One thing of note, is I'm currently trying a distributed volume with a 2nd host, and actions are still slow on the host containing the batch of bricks I'm trying to add is very slow, however the other host with no volumes at this time runs gluster vol info volname very quickly. I will be trying to add bricks shortly, but since I had very quick response the first time around I'm hoping someone may be able to shed some light for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140521/572d6e4a/attachment.html>
One of the reasons for this could be address resolution. This is generally, in my observation, what takes up the longest time. In any gluster operation involving addresses, including create volume, add-brick etc, address resolution is done to validate that the brick(s) given belong(s) to a member of the cluster. The address resolution is a blocking operation, and could lead to long waits like you've observed. A volume info command on the other hand, does not involve any address resolution and returns instantly. ~kaushal On Wed, May 21, 2014 at 1:41 PM, Benjamin Kingston <list at nexusnebula.net>wrote:> I'm trying to get gluster working on a test lab and had excellent success > setting up a volume and 14 bricks on the first go around. However I > realized the reasoning behind using a subdirectory in each brick and > decommissioned the whole volume to start over. I also deleted the > /var/lib/glusterd directory and removed/installed the necessary gluster > packages. I'm running Scientific linux 6.4 with all recent updates. > > Upon recreating the new volume with the new brick, I found the process > very very slow, about 2-3 minutes to process the change. Adding additional > bricks also takes the same amount of time as well as simple set parameter > actions. This was with a distributed volume with only one host involved. > > I notice in the cli log file, it constantly complains about not being able > to guess the transport family, which an online search for the error or > parts of the error only brought up issues that apply to older versions of > gluster. > > One thing of note, is I'm currently trying a distributed volume with a 2nd > host, and actions are still slow on the host containing the batch of bricks > I'm trying to add is very slow, however the other host with no volumes at > this time runs gluster vol info volname very quickly. I will be trying to > add bricks shortly, but since I had very quick response the first time > around I'm hoping someone may be able to shed some light for me. > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140521/349e8373/attachment.html>
Is it possible that each of your bricks is in its own vm, and the vm system drives (where /var/lib/glusterd resides) are all placed on the same host drive? Glusterd updates happen synchronously even in the latest release and the change to use buffered writes + fsync went into master only recently.. On May 21, 2014 1:25 AM, "Benjamin Kingston" <list at nexusnebula.net> wrote:> I'm trying to get gluster working on a test lab and had excellent success > setting up a volume and 14 bricks on the first go around. However I > realized the reasoning behind using a subdirectory in each brick and > decommissioned the whole volume to start over. I also deleted the > /var/lib/glusterd directory and removed/installed the necessary gluster > packages. I'm running Scientific linux 6.4 with all recent updates. > > Upon recreating the new volume with the new brick, I found the process > very very slow, about 2-3 minutes to process the change. Adding additional > bricks also takes the same amount of time as well as simple set parameter > actions. This was with a distributed volume with only one host involved. > > I notice in the cli log file, it constantly complains about not being able > to guess the transport family, which an online search for the error or > parts of the error only brought up issues that apply to older versions of > gluster. > > One thing of note, is I'm currently trying a distributed volume with a 2nd > host, and actions are still slow on the host containing the batch of bricks > I'm trying to add is very slow, however the other host with no volumes at > this time runs gluster vol info volname very quickly. I will be trying to > add bricks shortly, but since I had very quick response the first time > around I'm hoping someone may be able to shed some light for me. > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140521/cdf4e0ad/attachment.html>