about slow query! how to disable auto split chunk

[Chancey]

the cluster system often has slow query, then I debug the mongos.

the slow reason is sleepsecs().

the code:

 

        if ( op == dbQuery ) {

            iscmd = isCommand();                                                                                      

            try {

                s->queryOp( *this );                                                                                 

            }

            catch ( StaleConfigException& staleConfig ) {

                log() << staleConfig.what() << " attempt: " << attempt << endl;

                uassert( 10195 ,  "too many attempts to update config, failing" , attempt < 5 );                     

                ShardConnection::checkMyConnectionVersions( getns() );                                                

                if (!staleConfig.justConnection() )                                                                  

                    sleepsecs( attempt );

                reset( ! staleConfig.justConnection(), attempt >= 2 );                                                

                _d.markReset();

                process( attempt + 1 );                                                                              

                return;                                                                                               

            }                                                                                                        

        }

 

I go deepi in the code, the StaleConfigException has relationship between chunkManager and shardVersion.

is these normal? if disable auto split chunk, can slow query be solved?

 

thanks!

[Greg Studer]

There's no explict way top disable splitting - migrations would also have the same impact?  What's your traffic pattern (for example, lots of inserts, lots of queries on static data)?  You're correct that disabling migrations and split would avoid this problem, but that can lead to data imbalances and other issues.

The logic there is designed to avoid DOSing the config server on multiple reloads, it's being reworked in newer versions.  There's no delay for the first reload, so to manifest the problem here mongos metadata has to be changing very quickly.