mongodb-user
[Arriba] [Todas las Listas]

Re: [mongodb-Usuario] MongoDB chunk migración - "Pasos" explicación de

To: mongodb-user@xxxxxxxxxxxxxxxx
Subject: Re: [mongodb-Usuario] MongoDB chunk migración - "Pasos" explicación detallada (en Changlog)
From: "Joe,Yu" <smartjoe@xxxxxxxxx>
Date: Mon, 14 Sep 2015 23:26:07 +0800
Delivery-date: Mon, 14 Sep 2015 11:37:32 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=nKq1Oe34u6NYAac1oa2ie8Btt+j4rtMNvP8QTLTDCiA=; b=fTyesBfP6kjKNinWJYcC8yseKv2WJJdXv+0/+gno3eczcS+RgoeYDW8WPawQQIfTMY G54yDyztomBXrXCGoYYGNCL76qILHzkSysok/CH4Z/Bt1npywJTtcj+ga0XJCQDSrNs4 GlgdlxCLINKKLiFWkyMQXIhWBXdndrdou3Yw+NQ1ZZqTT+F4pFpZt5jKK8OP92f0Qegb 0BCuI56pvtuXQ+wP4S1hJ60ZNc8459Shw1zWN/BLET0jnrEJz1hNvhKHxuEgvd+0HiIA CRV3kxu6vPh78ITH1/Q5GR6ZAT7cmnnH2zpeUlaNWZgKes9CY1rXFUxuW/zVAJJmDbwG ukaQ==
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <CAOe6dJAHiBz=w_=pzexco2mzGY-pyRZaR05Th-Q79oLzPuUh=w@mail.gmail.com>
List-archive: <http://groups.google.com/group/mongodb-use>
List-help: <http://groups.google.com/support/>, <mailto:mongodb-user+help@googlegroups.com>
List-id: <mongodb-user.googlegroups.com>
List-post: <http://groups.google.com/group/mongodb-user/post>, <mailto:mongodb-user@googlegroups.com>
List-subscribe: <http://groups.google.com/group/mongodb-user/subscribe>, <mailto:mongodb-user+subscribe@googlegroups.com>
List-unsubscribe: <mailto:googlegroups-manage+1044811755470+unsubscribe@googlegroups.com>, <http://groups.google.com/group/mongodb-user/subscribe>
Mailing-list: list mongodb-user@xxxxxxxxxxxxxxxx; contact mongodb-user+owners@xxxxxxxxxxxxxxxx
References: <80A1F782AAC5B665.B0D8138F-25F4-405F-98C7-A2B78345E349@mail.outlook.com> <CAOe6dJAHiBz=w_=pzexco2mzGY-pyRZaR05Th-Q79oLzPuUh=w@mail.gmail.com>
Reply-to: mongodb-user@xxxxxxxxxxxxxxxx
Sender: mongodb-user@xxxxxxxxxxxxxxxx
*Thanks *Asya Para vuestra información valiosa.

Hace el tiempo total para paso 3 de 5  también incluye crear índice después de cada
copia de objeto y escribir al destino *shard?

>Del *mongodb código de fuente(*v 2.4.5) :

antes de que el "3. Inicial *bulk paso" de clon
allí es

 "0. Sistema de copia.*namespaces Entrada si la colección  no ya existe"
(inicio de línea 1621 de *d_emigra.*cpp)  
 "1. Índices de copia" (inicio de línea 1637 de *d_emigra.*cpp)

*whithin Paso"1. Índices de copia" , el destino *shard estructuras de índices
del clon de la fuente *shard

Y *i intenta entender en paso 3 "3.Inicial *bulk el clon" después de cada objeto
escribe al destino *shard,  aquello también provoca un índice actualiza(o *re-crear)
también? Si tan , *i tener que también tendría que considerar el paso de tiempo total 3
utilizado es de hecho marca por tres parte : 1) el dato de copia del tiempo de fuente
*shard 2) los tiempos escriben al destino *shard 3) los tiempos actualizan índice
inmediatamente después de cada objeto escribe al *shard.

*Thanks,

Joe


En *Thu, *Sep 10, 2015 en 6:29 AM, *Asya *Kamsky <asya@xxxxxxxxxxx> escribió:

> no soy seguro por qué la respuesta de SO(*s) no es *adequate - naturalmente el
> código de fuente es el *canonical prueba de lo que el tiempo está siendo gastado encima.
>
> Un par de *clarifications aun así:  el tiempo es grabado en
> *Milliseconds.  Así que cuándo dices "consume espectáculo y tiempo" loco 1,551,243
> - aquello es 1550 segundos - aquello es 25 minutos.  Dependiendo en cuántos
> documentos son en vuestro *chunk, y si secundario *throttle es encima, podría ser un bastante cercano a cantidad esperada de tiempo para encontrar y copiar
> todo de aquellos documentos del *donor *shard al *recipient *shard.
>
> 3 no es el "tratar secundario *throttle" parte, 3 es el real
> copiando sobre la parte de documentos, la lectura en el de *shard y la escritura
> en el a *shard.
> Tan si vuestro de *shard es muy *busy y no tiene bastante RAM para
> el conjunto laborable **plus* este *chunk, entonces la lectura será muy despacio y tiene
> que esperar para mucho IO de disco.   Si el "a *shard" es muy *busy
> entonces la escritura competirá con todo el escribiendo aquello es ya
> "normalmente" yendo en en este *shard.
>
> Miraría en las cargas en el *shards y ver si sencillamente no tienes bastante capacidad para migración arriba de vuestras operaciones normales.
>
> *Asya
>
>
> En *Wed, *Sep 9, 2015 en 10:35 AM, JOE *YU <smartjoe@xxxxxxxxx> escribió:
> > Hola lista,
> >
> > estoy analizando un *chunk problema de rendimiento de la migración de *mongodb(*v 2.4.6)
> > *sharding grupo.
> > Después de que comprobar el *changelog de *config *db, *i encontró hay alguna información
> > útil que me puede ayudar para diagnosticar el tiempo más largo utilizado en pasos
> > de detalle.
> > Primer *i comprobó "*moveChunk.De y" encontrado abajo resultado:
> >     "paso1 de 6" : 0,
> >                 "paso2 de 6" : 196,
> >                 "paso3 de 6" : 18234,
> >                 "paso4 de 6" : 1551243,
> >                 "paso5 de 6" : 262,
> >                 "paso6 de 6" : 0
> >         }
> > Lo parece paso4(F4:*T1-*T5) parcela utilizada de tiempo, entonces *i comprobar el correspondiente
> > *moveChunk.A y intentar imaginar fuera de qué paso en *T1-*T5 consume tiempo
> loco,
> > aquí es el resultado:
> >     "paso1 de 5" : 2,
> >                 "paso2 de 5" : 0,
> >                 "paso3 de 5" : 1448987,
> >                 "paso4 de 5" : 0,
> >                 "paso5 de 5" : 741
> > Lo parece paso3(*T3) es la mayoría de tiempo-consumiendo operación.
> > Tan *i probado para entender lo que es "paso3 de 5" (*T3) exactamente haciendo.
> > Tengo comprueba
> >
> el *http://*docs.*mongodb.*org/Núcleo/manual/*sharding-*chunk-migración/#*chunk-migración
> > pero hay información detallada no sobre "paso3 de 5".
> > Y entonces *i encontró un correo similar en SO cuando aquí:
> >
> *http://*stackoverflow.*com/Cuestiona/18103220/*mongodb-*chunk-migración-pasos-dentro-*changelog-colección
> > , todavía ninguna bastante información en él.
> > Podría cualquiera da una pista dónde puede *i encontrar el *accurate descripción en
> paso3
> > de 5 y otro "*stepX en 6" y *stepY "en 5" o proporcionar una respuesta aquí?
> > He también comprobar el código de fuente de *mongodb *chunk la migración y el
> > código correspondiente es tan abajo
> >     // 3. Inicial *bulk clon
> >         CLON estatal;
> >         mientras ( cierto )
> >             #unknown{^*BSONObj *res;
> >             si ( ! *conn->*runCommand( "*admin" , *BSON( "_*migrateClone" <<
> 1 )
> > , *res ) ) // #get variedad de objetos para copiar, en estado de orden
> >                 del disco = FALLA;
> >                 *conn.Hecho();
> >                 regreso;
> >             }
> >             *BSONObj *arr = *res["objetos"].*Obj();
> >             *int *thisTime = 0;
> >             *BSONObjIterator *i( *arr );
> >             mientras( *i.Más() )
> >                 #unknown{^*BSONObj *o = *i.Próximo().*Obj();
> >                     #unknown{^*PageFaultRetryableSection *pgrs;
> >                     Mientras ( 1 )
> >                         #verbcj
> >                             #nom::*DBWrite *lk( *ns );
> >                             *Helpers::*upsert( *ns, *o, cierto );
> >                             rotura;
> >                         }
> >                         coge ( *PageFaultException& *e )
> >                             #unknown{^*e.Tacto();
> >                         }
> >                     }
> >                 }
> >                 *thisTime++;
> >                 *numCloned++;
> >                 *clonedBytes += *o.*objsize();
> >                 Si ( *secondaryThrottle )
> >                     #cnj ( ! *waitForReplication( *cc().*getLastOp(), 2, 60 /*
> > segundos para esperar */ ) ) {
> >                     }
> >                 }
> >             }
> >             si ( *thisTime == 0 )
> >                 rotura;
> >         }
> >     }
> > parece *T3 tiene tres tiempo potencial-consumiendo procesos
> > 1) dato leído de F(*rom) lado (I/O de red)
> > 2) inserta a *T(*o) lado (I/O de disco
> > 3) trata "*secondaryThrottle" proceso relacionado con el *replica
> > Tan en mi caso,  ["paso3 de 5" :1448987] significa mucho I/O de disco (o I/O
> 
> > pobre )? ( *i  No controlando el I/O de red grande y también *i ha puesto
> > *secondaryThrottle=falso)
> > *Thanks,
> > Joe
> >
> > --
> > recibiste este mensaje porque eres *subscribed al *Google Grupos
> > "*mongodb-grupo"
> > de usuario.
> >
> > Para otro *MongoDB opciones de apoyo técnico, ve:
> > *http://www.mongodb.org/sobre/apoyo/.
> > ---
> > Recibiste este mensaje porque eres *subscribed al *Google Grupos
> > "*mongodb-grupo" de usuario.
> > A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un
> > *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
> > A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
> > Visita este grupo en *http://grupos.*google.*com/Grupo/*mongodb-usuario.
> > Para ver esta discusión en la visita de web
> >
> *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/80Un1F782AAC5*B665.*B0*D8138F-25F4-405F-98*C7-#Uno2*B78345*E#349%40correo.*outlook.*com
> .
> > Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
>
> --
> Recibiste este mensaje porque eres *subscribed al *Google Grupos
> "*mongodb-grupo"
> de usuario.
>
> Para otro *MongoDB opciones de apoyo técnico, ve:
> *http://www.mongodb.org/sobre/apoyo/.
> ---
> Recibiste este mensaje porque eres *subscribed al *Google Grupos
> "*mongodb-grupo" de usuario.
> A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un
> *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
> A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
> Visita este grupo en *http://grupos.*google.*com/Grupo/*mongodb-usuario.
> Para ver esta discusión en la visita de web
> *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/*CAOe6*dJAHiBz%3*Dw_%3*Dpzexco2*mzGY-*pyRZaR05*Th-*Q79*oLzPuUh%3*Dw%40correo.*gmail.*com
> .
> Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
>



-- 
*jOe

-- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo"
de usuario.

Para otro *MongoDB opciones de apoyo técnico, ve: *http://www.mongodb.org/sobre/apoyo/.
--- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo" de usuario.
A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
Visita este grupo en *http://grupos.*google.*com/Grupo/*mongodb-usuario.
Para ver esta discusión en la visita de web *https://grupos.*google.*com/*d/*msgid/*mongodb-CA/de usuario%2*BXGj5*CmszwATXEyehBUGK8*FCzsebwwLXLkom0*uER9*oeJDLXyw%40correo.*gmail.*com.
Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
Thanks Asya for your valuable information.

Does the total time for step 3 of 5  also include creating index after each
object copy and write to the destination shard?

>From the mongodb's source code(v 2.4.5) :

before the "3. initial bulk clone" step
there are

 "0. copy system.namespaces entry if collection doesn't already exist"
(start from line 1621 of  d_migrate.cpp)
 "1. copy indexes" (start from line 1637 of d_migrate.cpp)

whithin step"1. copy indexes" , the destination shard clone indexes
structures from the source shard

And i try to understand in step 3 "3.initial bulk clone" after each object
write to the destination shard, will that also trigger an index update(or
re-create) too? If so , i should also should consider the total time step 3
used are actually make by three part : 1) the time copy data from source
shard 2) the time write to the destination shard 3) the time update index
immediately after each object write to the shard.

Thanks,

Joe


On Thu, Sep 10, 2015 at 6:29 AM, Asya Kamsky <asya@xxxxxxxxxxx> wrote:

> I'm not sure why the SO answer(s) are not adequate - of course the
> source code is the canonical proof of what the time is being spent on.
>
> A couple of clarifications though:  the time is recorded in
> Milliseconds.  So when you say "consume crazy time" and show 1,551,243
> - that's 1550 seconds - that's 25 minutes.  Depending on how many
> documents are in your chunk, and whether secondary throttle is on, it
> could be a pretty close to expected amount of time to find and copy
> all of those documents from the donor shard to the recipient shard.
>
> 3 is not the "deal with secondary throttle" part, 3 is the actual
> copying over the documents part, the reading on the from shard and the
> writing on the to shard.
> So if your from shard is very busy and doesn't have enough RAM for the
> working set *plus* this chunk, then the reading will be very slow and
> have to wait for lots of disk IO.   If the "to" shard is very busy
> then the writing will compete with all the writing that's already
> "normally" going on on this shard.
>
> I would look at the loads on the shards and see if you simply don't
> have enough capacity for migration on top of your normal operations.
>
> Asya
>
>
> On Wed, Sep 9, 2015 at 10:35 AM, JOE YU <smartjoe@xxxxxxxxx> wrote:
> > Hello list,
> >
> > I am analyzing a chunk migration performance problem of mongodb(v 2.4.6)
> > sharding cluster.
> > After check the changelog of config db, i found there are some useful
> > information that can help me to diagnose the longest time used in detail
> > steps.
> > First i checked "moveChunk.from" and found below result:
> >     "step1 of 6" : 0,
> >                 "step2 of 6" : 196,
> >                 "step3 of 6" : 18234,
> >                 "step4 of 6" : 1551243,
> >                 "step5 of 6" : 262,
> >                 "step6 of 6" : 0
> >         }
> > It seems step4(F4:T1-T5) used lot of time, then i check the corresponding
> > moveChunk.To and try to figure out which step in T1-T5 consume crazy
> time,
> > here is the result:
> >     "step1 of 5" : 2,
> >                 "step2 of 5" : 0,
> >                 "step3 of 5" : 1448987,
> >                 "step4 of 5" : 0,
> >                 "step5 of 5" : 741
> > It seems step3(T3) is the most time-consuming operation.
> > So i tried to understand what is "step3 of 5" (T3) exactly doing.
> > I have check the
> >
> http://docs.mongodb.org/manual/core/sharding-chunk-migration/#chunk-migration
> > but there is no detailed information about "step3 of 5".
> > And then i found a similar post on SO as here:
> >
> http://stackoverflow.com/questions/18103220/mongodb-chunk-migration-steps-in-changelog-collection
> > , still no enough information on it.
> > Could any one give a clue where can i find the accurate description on
> step3
> > of 5 and other "stepX on 6" and "stepY on 5" or provide a answer here?
> > I have also check the source code of mongodb's chunk migration and the
> > corresponding code is as below
> >     // 3. initial bulk clone
> >         state = CLONE;
> >         while ( true ) {
> >             BSONObj res;
> >             if ( ! conn->runCommand( "admin" , BSON( "_migrateClone" <<
> 1 )
> > , res ) ) { // gets array of objects to copy, in disk order
> >                 state = FAIL;
> >                 conn.done();
> >                 return;
> >             }
> >             BSONObj arr = res["objects"].Obj();
> >             int thisTime = 0;
> >             BSONObjIterator i( arr );
> >             while( i.more() ) {
> >                 BSONObj o = i.next().Obj();
> >                 {
> >                     PageFaultRetryableSection pgrs;
> >                     while ( 1 ) {
> >                         try {
> >                             Lock::DBWrite lk( ns );
> >                             Helpers::upsert( ns, o, true );
> >                             break;
> >                         }
> >                         catch ( PageFaultException& e ) {
> >                             e.touch();
> >                         }
> >                     }
> >                 }
> >                 thisTime++;
> >                 numCloned++;
> >                 clonedBytes += o.objsize();
> >                 if ( secondaryThrottle ) {
> >                     if ( ! waitForReplication( cc().getLastOp(), 2, 60 /*
> > seconds to wait */ ) ) {
> >                     }
> >                 }
> >             }
> >             if ( thisTime == 0 )
> >                 break;
> >         }
> >     }
> > It seems T3 has three potential time-consuming processes
> > 1) read data from F(rom) side (network I/O)
> > 2) insert into T(o) side (disk I/O
> > 3) deal with "secondaryThrottle" related process with the replica
> > So in my case, does ["step3 of 5" :1448987] means a lot of disk I/O (or
> poor
> > I/O )? ( i did not monitoring the large network I/O and also i have set
> > secondaryThrottle=false)
> > Thanks,
> > Joe
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "mongodb-user"
> > group.
> >
> > For other MongoDB technical support options, see:
> > http://www.mongodb.org/about/support/.
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "mongodb-user" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
> > To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
> > Visit this group at http://groups.google.com/group/mongodb-user.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/mongodb-user/80A1F782AAC5B665.B0D8138F-25F4-405F-98C7-A2B78345E349%40mail.outlook.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user"
> group.
>
> For other MongoDB technical support options, see:
> http://www.mongodb.org/about/support/.
> ---
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
> To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
> Visit this group at http://groups.google.com/group/mongodb-user.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mongodb-user/CAOe6dJAHiBz%3Dw_%3Dpzexco2mzGY-pyRZaR05Th-Q79oLzPuUh%3Dw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
jOe

-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CA%2BXGj5CmszwATXEyehBUGK8FCzsebwwLXLkom0uER9oeJDLXyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
<Anterior por Tema] Tema Actual [Siguiente por Tema>