-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! I've read the description for the network.ping-timeout option, but the admonishment at the end isn't particularly helpful: "This reconnect is a very expensive operation and should be avoided." Can that be quantified at all? Does this boil down to a "thundering herd" problem, such that the problem is exacerbated by lots of clients? If the client count is relatively low, is the problem reduced in any way? The bot in #gluster provides a little more info, but not enough: "The reason for the long (42 second) ping-timeout is because re-establishing fd's and locks can be a very expensive operation. Allowing a longer time to reestablish connections is logical, unless you have servers that frequently die." If I'm using a distributed replicated volume to ensure availability of my data, it seems sub-optimal to block all Gluster I/O for 42 seconds. Is there guidance on how to balance the timeout for different scenarios? My searching hasn't provided much useful insight on the matter. If there are documents available online for me to review, I'll happily read them. Thanks! Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4NraAAoJENjy5XvtDywKAyQP/jN60O2tEaw1r+zKiD5r1uav RjPrlsMZJ6S55HOt6wZ/i9H4u+skMHIgGeo5/4mTnkDzB6OybeSp3efv5l2rycxX IPhF3RCbpkSQa7il+5TldG21zHrfBlyf05LEFEMk6XqF6pswhIxjiWoOMjkKrY03 IGXVRd6VV6CQ5dQMYprQr6XYs90tKxgWNzFwxTfyk1jaLHo07ocBz5L6b8gYiBg2 4oZgI9EJnahHferfZJwqkH1609sAc37akrauLRSyDzHYpwJTTgVhslwFW6dzFI2A U0GA95uuu4sOf4AhXOOHUTwWVeqHNBizQdJuP/KcVv/lX/eC+yC48o1gifPYLcJs EluIQdY6a3SknwHmaSNBRGfehc7sWUjO1Nrz2JFtjfjRAtEgGTNL0tiJkUKJxL2U UGhRSGF3dNz8DkqjrXVIyMXiujLIR3uLNsa/KqwaJvac1m82tJWu7pC4zva2XjjF j+d/4LNLznSfkyq4C+l5qAe8sM5L4GSgbJVsSiUecl432sV6RhgBTvE/Gbk2Klnb 1FXMYy10VFeSmDM4etoJsMxy0EjyLyQAMcO//GU+FV2kwr+wsTStMHoOzzqOApY+ V5SFHjA18TFYxyN5DICLXTCn6J81aoJXnd7+cDWM0jOhUbhxtS7KSnidqWwj+TLH gV+5608dxtmFgOKCF/55 =iDza -----END PGP SIGNATURE-----
Pranith Kumar Karampuri
2014-Aug-06 15:15 UTC
[Gluster-users] network.ping-timeout details
hi, Do you think you have any workload you can generate to see the kind of latency numbers your setup has? You can probably use 'gluster volume profile <volname> start/info/stop' to figure out the maximum latencies and configure a number closer to the numbers you get in this profile? The following contains steps to perform profiling. http://gluster.org/community/documentation/index.php/Gluster_3.2:_Running_Gluster_Volume_Profile_Command HTH Pranith On 08/05/2014 06:53 PM, Scott Merrill wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello! > > I've read the description for the network.ping-timeout option, but the > admonishment at the end isn't particularly helpful: > > "This reconnect is a very expensive operation and should be avoided." > > Can that be quantified at all? Does this boil down to a "thundering > herd" problem, such that the problem is exacerbated by lots of > clients? If the client count is relatively low, is the problem > reduced in any way? > > The bot in #gluster provides a little more info, but not enough: > > "The reason for the long (42 second) ping-timeout is because > re-establishing fd's and locks can be a very expensive operation. > Allowing a longer time to reestablish connections is logical, unless > you have servers that frequently die." > > > If I'm using a distributed replicated volume to ensure availability of > my data, it seems sub-optimal to block all Gluster I/O for 42 seconds. > > Is there guidance on how to balance the timeout for different scenarios? > > My searching hasn't provided much useful insight on the matter. If > there are documents available online for me to review, I'll happily > read them. > > Thanks! > Scott > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQIcBAEBCgAGBQJT4NraAAoJENjy5XvtDywKAyQP/jN60O2tEaw1r+zKiD5r1uav > RjPrlsMZJ6S55HOt6wZ/i9H4u+skMHIgGeo5/4mTnkDzB6OybeSp3efv5l2rycxX > IPhF3RCbpkSQa7il+5TldG21zHrfBlyf05LEFEMk6XqF6pswhIxjiWoOMjkKrY03 > IGXVRd6VV6CQ5dQMYprQr6XYs90tKxgWNzFwxTfyk1jaLHo07ocBz5L6b8gYiBg2 > 4oZgI9EJnahHferfZJwqkH1609sAc37akrauLRSyDzHYpwJTTgVhslwFW6dzFI2A > U0GA95uuu4sOf4AhXOOHUTwWVeqHNBizQdJuP/KcVv/lX/eC+yC48o1gifPYLcJs > EluIQdY6a3SknwHmaSNBRGfehc7sWUjO1Nrz2JFtjfjRAtEgGTNL0tiJkUKJxL2U > UGhRSGF3dNz8DkqjrXVIyMXiujLIR3uLNsa/KqwaJvac1m82tJWu7pC4zva2XjjF > j+d/4LNLznSfkyq4C+l5qAe8sM5L4GSgbJVsSiUecl432sV6RhgBTvE/Gbk2Klnb > 1FXMYy10VFeSmDM4etoJsMxy0EjyLyQAMcO//GU+FV2kwr+wsTStMHoOzzqOApY+ > V5SFHjA18TFYxyN5DICLXTCn6J81aoJXnd7+cDWM0jOhUbhxtS7KSnidqWwj+TLH > gV+5608dxtmFgOKCF/55 > =iDza > -----END PGP SIGNATURE----- > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users