mongodb-user
[Arriba] [Todas las Listas]

[no subject]

To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Subject:
From: prasad2019 <prasad212019@xxxxxxxxx>
Date: Mon, 14 Sep 2015 16:41:16 -0700 (PDT)
Delivery-date: Mon, 14 Sep 2015 19:52:43 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe; bh=+atvdySIwRGvJ838Sce+WQlS1XcChcBplkGfnHcEZnE=; b=TqrERD3DD5LpC8FF3zu6uGandwUscNdeGuV3GwEsXvJsypfbgKYDevVcUrVcsbbSPU SyrN6XuYdsj3nxJbvvkYqPjO74PBOJSYr6+RgnHMMGyDE/YV94VnRqjFavqHF2j09v0x VOJWbF05mUs1pxfgllqfgtWZSMSyFIQjLNMAe6fTfKmcX1ZiXk324XGISxs6tNglKiMB EKXDCfBWavDeb15jnHepv/DqOYa4mMpXo5qxbdgPQuhav6nvlQjPM9JoFdS9Kkru2cMh u25ErQyEpbjcLPLjmPJNjk++oJvAbP3e16Tz6UvBsLVVvPIDPxpHOslk7Mib51Mgi2fd gTQA==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe; bh=+atvdySIwRGvJ838Sce+WQlS1XcChcBplkGfnHcEZnE=; b=MlvosVU62VlBoouBcBfYpK2w8l7G3qETx6TCMjw6x9DGc59BelaGMycna/pnL2Mtgo UqfoFXiWUvwYqExVnm0pf2gzpIX86CBwVE1HnSusw+Cfqmvfm80S8p8bklMCHVhkR+6U vsrurietJq9OlU36xSwe8/iog9Y85II5171D5qxj0cB42O5qHo2u4P8W+OwVdZMBW+ZZ M9w46fyokk7YgWUBCyp2wJAeEGSaelZkkAE5FV+ddaQ6+LEDLOLdmiKS+++4lXSLUvrd I8hR2w6JTkqfneFoUcXqUw5n0xOBREPUsUHuR3MfEX3FuV4ewJIMT5pXSS4XIj8JK29T b44A==
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <CAOe6dJBa7Oni1U+9wcrGMWvWUCyOx_Syn8eev-zN09pcoUp=Mw@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: <6aed493d-b684-49e0-ab57-5a6832c3680e@googlegroups.com> <83ef9f60-8f6b-4a9f-96cd-0eb7bd78695a@googlegroups.com> <425d9972-32c2-4426-ae83-16adf65f9aff@googlegroups.com> <50127ebc-730c-4f7c-b4e0-0d9f770f5dfa@googlegroups.com> <85e254c9-0fd4-49a5-acd0-9c774ecb00ed@googlegroups.com> <CAOe6dJDaYs+To5T3YQKiZ==kSjBQxN9Rv4OPBTP7U6Z34h41Ug@mail.gmail.com> <51aa6800-068d-4292-9b73-eb5cf17bf326@googlegroups.com> <CAOe6dJBa7Oni1U+9wcrGMWvWUCyOx_Syn8eev-zN09pcoUp=Mw@mail.gmail.com>
Reply-to: mongodb-user@xxxxxxxxxxxxxxxx
Sender: mongodb-user@xxxxxxxxxxxxxxxx
*Hi *Aysa,

   *Thanks era asunto con *XFS sistema de archivo en *RHEL 7.1, sí ahora he 
*repopulated con aumentado *dataset de 30 Millones a 300 Millones 
documentos. El Dato que carga fue bastante bien pero realizado más tarde el *replica 
los conjuntos no fueron capaces de coger hasta el dato que carga 

índice ( Escritura 180 MB/*s de dato (este tiempo era Disco Duro con REDADA 10 en 
él y Con SSD era 420 MB/*s) con el *default *oplogSize=1024 MB  ). A *sync 
arriba  traje abajo el *mongo casos y en *replicaset *servers 
cayó 

el *datapath directorios.   *OplogSize=5GB cambiado en ambos primario y *replicas 
con este cambio *replicaset cogido arriba de con Primario (Incluyendo 
complexión de Índice) para un *dataset medida de 358medida de GB en  1 Hora 51 Minutos 
(Contra 3 Horas con *OPLOGSIZE=1024 MB incluso con SSD). 

 

Así que habiendo un más grande *Oplogsize parcela hecha de diferencia,  empezando gustando estas 
operaciones internas que explica por qué *MongoDB motor *ranking está subiendo 
rápidamente (*http://*db-motores.*com/*en/*ranking)


*BTW Quise validar estos *YCSB resultados de prueba con *MongoDB cómo  yo  
él, cualquier *pointers.



*Thanks





*Prasad *Thanks




*Prasad *Thanks



*Prasad En viernes, septiembre 11, 2015 en 12:41:35 SOY *UTC-7, *Asya *Kamsky escribió:
>
> Esto fuertemente sugiere un asunto con *underlying *storage capa - si el 
> archivo en disco consigue *corrupt no hay cualquier manera *journaling puede ayudar.
>
> Desde esto es *YCSB dato puedes justo *wipe fuera del directorio y *repopulate 
> - que sería mi sugerencia pero yo  *verify el sistema de archivo primero.
>
> *Asya
>
>
> En *Thu, *Sep 10, 2015 en 2:00 PM, *prasad2019 <prasad...@xxxxxxxxx 
> <*javascript:>> escribió:
>
>> *Hi  *Aysa,
>>
>>    *Thanks realicé que también después del par de CPU de sistema de las pruebas era justo 
>> 15% así que abundancia de habitación, era el IO que conseguía *maxed fuera de (450MB 
>> /*Sec Escribe) durante carga de Dato, para confirmar esto estoy planeando añadir 
>> discos adicionales para realizar el beneficio de *Batchsize de *default 1 para ver 
>> si estas ayudas en ayudas crecientes para el dato que carga. 
>>
>> Bien ahora estoy encontrando *checksum error en uno del *datafile, *Beacuse 
>> de este primario *MongoDB accidentes de caso y dos *replicas no está cogiendo 
>> arriba de con el primario.  Incluso después de primario retoma esperar con *Journaling encima, 
>> corregirá ninguna necesidad de correr "Reparación *Database" orden.  
>>
>> "2015-09-10*T13:03:45.678-0600 *E *STORAGE  [*conn47] *WiredTiger (0) 
>> [1441911825:678595][11777:0*x7*f7#uno6*aa06700], 
>> archivo:colección-12--8249752617800779708.*wt, *cursor.Próximo: leído *checksum 
>> error para 32768*B bloque en *offset 24421470208: bloque calculado *checksum de 179228071 
>> no empareja esperado *checksum de 2102742815"
>> "2015-09-10*T13:03:45.678-0600 *E *STORAGE  [*conn47] *WiredTiger (0) 
>> [1441911825:678683][11777:0*x7*f7#uno6*aa06700], 
>> archivo:colección-12--8249752617800779708.*wt, *cursor.Próximo: 
>> colección-12--8249752617800779708.*wt: Encontrado un formato de archivo ilegal 
>> o valor interno"
>> "2015-09-10*T13:03:45.678-0600 *E *STORAGE  [*conn47] *WiredTiger (-31804) 
>> [1441911825:678705][11777:0*x7*f7#uno6*aa06700], 
>> archivo:colección-12--8249752617800779708.*wt, *cursor.Próximo: el proceso tiene que 
>> salir y retomar: PÁNICO_de WT: *WiredTiger pánico de biblioteca"
>>
>> te #Poder complacer ayudarme cómo  recupero este bloque *checksum error, es 
>> allí orden de reparación del bloque que puedo utilizar?
>>
>>
>> *Thanks
>> 
>>
>>
>>
>> *Prasad En miércoles, septiembre 9, 2015 en 3:22:00 PM *UTC-7, *Asya *Kamsky escribió:
>>>
>>> *Hi *Prasad:
>>>
>>> Cuando *Rob señalado fuera de - puedes hacer el lote inserta en cualquier rama - de hecho, 
>>> el 10*gen-rama de laboratorios fue creada porque *YCSB parecido para tener ido 
>>> muy *dormant como proyecto, pero recientemente acontecían muy activos otra vez, 
>>> fusionando peticiones de atracción, sacando viejo *crufty material que no ha trabajado, y en 
>>> general *revitalizing el proyecto.   Tan desde *Rob ha entregado un número de las 
>>> mejoras similares a lo que creamos en la versión de laboratorios, es probablemente 
>>> mejor de utilizar el maestro para regular *YCSB probando.   Nuestro plan de plazo largo es 
>>> para utilizar nuestra rama propia para añadir alguna funcionalidad que falta en *YCSB - 
>>> habilidad de utilizar dato aquello es más realista (no aleatorio *byte corrientes), utilizando 
>>> índices secundarios, y consultas por índices secundarios, también cuando más 
>>> flexibilidad en tipo de lee y escribe.
>>>
>>> Cuándo originalmente añadimos el lote inserta era para reducir el tiempo toma a *wipe y *repopulate un grupo a entonces corrido alguna clase de mixto 
>>> *workload.  Dependiendo en la configuración del grupo, *batching podría 
>>> obtener *anywhere de 2*x a 6*x en mi experiencia.   Pero cuánto obtienes 
>>> fuertemente depende en dónde el *bottleneck es para el documento solo inserta 
>>> caso.  Si ya estás escribiendo tanto cuando el *server puede escribir, entonces 
>>> aquello es vuestro límite - pero si el *server es *underloaded porque el 
>>> atrás-y-adelante en la red está retrasando cosas abajo, *batching puede ayudar 
>>> mucho.
>>>
>>> Hope que ayudas,
>>> *Asya
>>>
>>>
>>> En Sentado, *Sep 5, 2015 en 3:58 PM, *prasad2019 <prasad...@xxxxxxxxx> escribió:
>>>
>>>> *Rob,
>>>>
>>>>  tengo 4 físico *servers cada cual con 28 Núcleos/256RAM de GB y SSD 
>>>> *Storage.   *MongoDB 3.0.6 con uno Primario y dos *replica conjunto y *YCSB  y *YCSB 
>>>> el cliente provocado de cuarto *server.
>>>>
>>>>  Otro punto interesante observé con *BatchSize=1  el *datadisk 
>>>> ubicación alrededor de 400MB por segundo escribe y *Log alrededor de 30 a 40MB cierra a 12 
>>>> a #15% Utilización de CPU con coherentemente 60*K *ops/*sec.
>>>>
>>>> Mientras que con *BatchSize=1 el *datadisk la ubicación escribe alrededor de 50  a 450MB 
>>>> por segundo y *Log alrededor de 10 a 20 CPU de MB 4 a #15% CPU y 15*K a 72*K 
>>>> *ops/*sec variación. *Bottomline *BatchSize Con 100 variación 
>>>>
>>>> de rendimiento bastante parcela.
>>>>
>>>> Bien con respecto a *YCSB medida de documento 1*KB a 151 *bytes aquello es punto bueno yo 
>>>> amable de *overlooked. Intentará cambiar y comprobar. 
>>>>
>>>>
>>>> Finalmente te #poder complacer punto cómo para cambiar compresión y  no 
>>>> entendido *wipe fuera del dato significa cae el *default *database y cambiar la compresión 
>>>> y cargarlo otra vez.
>>>>
>>>>
>>>>
>>>> *Thanks
>>>> 
>>>>
>>>>
>>>> *Prasad En sábado, septiembre 5, 2015 en 8:34:26 SOY *UTC-7, *Rob *Moore escribió:
>>>>>
>>>>> En viernes, septiembre 4, 2015 en 6:53:29 PM *UTC-4, *prasad2019 escribió:
>>>>>>
>>>>>>   *Thanks para el *pointer, utilicé *BatchSize parámetro para *YCSB 
>>>>>> pruebas de carga y los resultados bajaron.
>>>>>>
>>>>>>
>>>>>> Operaciones de Medida de los documentos/*Sec *YCSB Hilos *AverageLatency(nos) 
>>>>>> 95*thPercentileLatency(*ms) 99*thPercentileLatency(*ms)   Remarca 30 
>>>>>> Millones 61004 64 1036 0 1   *Batchsize=*Default 30 Millones 50119 64 
>>>>>> 1236 2 3   *Batchsize=100
>>>>>>
>>>>>
>>>>> Puede describes vuestro *setup un poco mejor. Qué es el *MongoDB 
>>>>> configuración? Cuántos *servers? Dónde es el cliente en relación al 
>>>>> *servers? Qué versión de *MongoDB? 
>>>>>
>>>>> En papel *batching en un más alto *latency el entorno tendría que mejorar 
>>>>> *throughput pero nunca vi el dato para probarlo. *Asya *blog No habla 
>>>>> sobre utilizarlo y la configuración para las charlas de característica sobre mejorar 
>>>>> la carga "" del *dataset no la carrera.
>>>>>
>>>>> También, para emparejar *Asya rendimiento necesitas hacer seguro tú *shrink el 
>>>>> *YCSB medida de documento del *default de 1*KB a 151 *bytes. En el *workload 
>>>>> conjunto de archivo/añade:
>>>>>
>>>>> *fieldcount=1
>>>>> *fieldlength=100
>>>>>
>>>>>  
>>>>>
>>>>>> yo también probado poniendo  Lee preferido a Primario 
>>>>>>  "*db.*getMongo().*setReadPref('*primaryPreferred')"   Y reemplazado  el 
>>>>>> *MongoDB archivo de Conductor de 3.0.2 a más tardío 3.0.3
>>>>>>
>>>>>
>>>>> FYI - puedes poner la preferencia leída *via el *MongoDb *URI:
>>>>>
>>>>>
>>>>> *http://*docs.*mongodb.*org/Conexión/de referencia/manual-la cadena/#leída-preferencia-opciones
>>>>>
>>>>>   
>>>>>
>>>>>> “ *log_leyó: *Compressed registro con ningún configurado *compressor: 
>>>>>> ERROR_de WT: no-específico *WiredTiger error”
>>>>>>
>>>>>
>>>>> sospecho que cambiando la compresión te requerirá a *wipe de los 
>>>>> archivos de dato.
>>>>>
>>>>>
>>>>> -- 
>>>> 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-user...@xxxxxxxxxxxxxxxx.
>>>> A correo a este grupo, envía *email a mongod...@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/85*e254*c9-0*fd4-49#uno5-*acd0-9*c774*ecb00*ed%40*googlegroups.*com 
>>>> <*https://Grupos.*google.*com/*d/*msgid/*mongodb-Usuario/85*e254*c9-0*fd4-49#uno5-*acd0-9*c774*ecb00*ed%40*googlegroups.*com?*utm_Medio=*email&*utm_fuente=*footer>
>>>> .
>>>>
>>>> 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-user...@xxxxxxxxxxxxxxxx <*javascript:>.
>> A correo a este grupo, envía *email a mongod...@xxxxxxxxxxxxxxxx 
>> <*javascript:>.
>> 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/51*aa6800-068*d-4292-9*b73-*eb5*cf17*bf326%40*googlegroups.*com 
>> <*https://Grupos.*google.*com/*d/*msgid/*mongodb-Usuario/51*aa6800-068*d-4292-9*b73-*eb5*cf17*bf326%40*googlegroups.*com?*utm_Medio=*email&*utm_fuente=*footer>
>> .
>>
>> 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/*d050*bcc5-8942-4*e92-*b5*e9-82*c95*f266246%40*googlegroups.*com.
Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
Hi Aysa,

   Thanks it was issue with XFS file system on RHEL 7.1, yes now I have 
repopulated with increased dataset from 30 Million to 300 Million 
documents. Data loading went pretty fine but realized later the replica 
sets were not able to catch up to the data loading 

rate ( Writing 180 MB/s of data (this time it was Hard Disk with RAID 10 on 
it and With SSD it was 420 MB/s) with the default oplogSize=1024 MB  ). To 
sync up  I brought down the mongo instances and on replicaset servers 
dropped 

the datapath directories.   OplogSize=5GB changed on both primary and 
replicas with this change replicaset caught up with Primary (Including 
Index build) for a dataset size of 358GB size in  1 Hour 51 Minutes 
(Against 3 Hours with OPLOGSIZE=1024 MB even with 

SSD). 

So having a larger Oplogsize made lot of difference,  starting liking these 
internal operations that explains why MongoDB engine ranking is going up 
rapidly (http://db-engines.com/en/ranking)


BTW I wanted to validate these YCSB test results with MongoDB how do I do 
it, any pointers.



Thanks
Prasad




Thanks
Prasad



Thanks
Prasad


On Friday, September 11, 2015 at 12:41:35 AM UTC-7, Asya Kamsky wrote:
>
> This strongly suggests an issue with underlying storage layer - if the 
> file on disk gets corrupt there isn't any way journaling can help.
>
> Since this is YCSB data you can just wipe out the directory and repopulate 
> - that would be my suggestion but I would verify the file system first.
>
> Asya
>
>
> On Thu, Sep 10, 2015 at 2:00 PM, prasad2019 <prasad...@xxxxxxxxx 
> <javascript:>> wrote:
>
>> Hi  Aysa,
>>
>>    Thanks I realized that too after couple of tests system CPU was just 
>> 15% so plenty of room, it was the IO which was getting maxed out (450MB 
>> /Sec Writes) during Data load, To confirm this I am planning to add 
>> additional disks to realize the benefit of Batchsize from default 1 to see 
>> if this helps in increasing helps for data loading. 
>>
>> Well now I am encountering checksum error on one of the datafile, Beacuse 
>> of this primary MongoDB instance crashes and two replicas are not catching 
>> up with the primary.  Even after primary restart hoping with Journaling on, 
>> it will correct no need to run "Repair Database" command.  
>>
>> "2015-09-10T13:03:45.678-0600 E STORAGE  [conn47] WiredTiger (0) 
>> [1441911825:678595][11777:0x7f7a6aa06700], 
>> file:collection-12--8249752617800779708.wt, cursor.next: read checksum 
>> error for 32768B block at offset 24421470208: calculated block checksum of 
>> 179228071 doesn't match expected checksum of 2102742815"
>> "2015-09-10T13:03:45.678-0600 E STORAGE  [conn47] WiredTiger (0) 
>> [1441911825:678683][11777:0x7f7a6aa06700], 
>> file:collection-12--8249752617800779708.wt, cursor.next: 
>> collection-12--8249752617800779708.wt: encountered an illegal file format 
>> or internal value"
>> "2015-09-10T13:03:45.678-0600 E STORAGE  [conn47] WiredTiger (-31804) 
>> [1441911825:678705][11777:0x7f7a6aa06700], 
>> file:collection-12--8249752617800779708.wt, cursor.next: the process must 
>> exit and restart: WT_PANIC: WiredTiger library panic"
>>
>> Can you please help me how do I recover this block checksum error, is 
>> there block repair command that I can use?
>>
>>
>> Thanks
>> Prasad
>>
>>
>>
>> On Wednesday, September 9, 2015 at 3:22:00 PM UTC-7, Asya Kamsky wrote:
>>>
>>> Hi Prasad:
>>>
>>> As Rob pointed out - you can do batch inserts on either branch - in 
>>> fact, the 10gen-labs branch was created because YCSB seemed to have gone 
>>> very dormant as a project, but recently they became very active again, 
>>> merging pull requests, removing old crufty stuff that hasn't worked, and in 
>>> general revitalizing the project.   So since Rob has submitted a number of 
>>> improvements similar to what we created in the labs version, it's probably 
>>> better to use the master for regular YCSB testing.   Our long term plan is 
>>> to use our own branch to add some functionality that is missing in YCSB - 
>>> ability to use data that's more realistic (not random byte streams), using 
>>> secondary indexes, and queries by secondary indexes, as well as more 
>>> flexibility in types of reads and writes.
>>>
>>> When we originally added batch inserts it was to reduce the time it 
>>> takes to wipe and repopulate a cluster to then run some sort of mixed 
>>> workload.  Depending on the configuration of the cluster, batching could 
>>> gain anywhere from 2x to 6x in my experience.   But how much you gain 
>>> heavily depends on where the bottleneck is for the single document insert 
>>> case.  If you're already writing as much as the server can write, then 
>>> that's your limit - but if the server is underloaded because the 
>>> back-and-forth on the network is slowing things down, batching can help 
>>> hugely.
>>>
>>> Hope that helps,
>>> Asya
>>>
>>>
>>> On Sat, Sep 5, 2015 at 3:58 PM, prasad2019 <prasad...@xxxxxxxxx> wrote:
>>>
>>>> Rob,
>>>>
>>>>  I have 4 physical servers each with 28 Cores/256GB RAM and SSD 
>>>> Storage.   MongoDB 3.0.6 with one Primary and two replica set and YCSB  and 
>>>> YCSB client triggered from fourth server.
>>>>
>>>>  Another interesting point I observed with BatchSize=1  the datadisk 
>>>> location around 400MB per second writes and Log around 30 to 40MB close to 
>>>> 12 to 15% CPU Utilization with consistently 60K ops/sec.
>>>>
>>>> Whereas with BatchSize=1 the datadisk location writes around  50 to 
>>>> 450MB per second and Log around 10 to 20 MB CPU 4 to 15% CPU and 15K to 72K 
>>>> ops/sec variation. Bottomline BatchSize with 100 performance 
>>>>
>>>> variation quite lot.
>>>>
>>>> Well regarding YCSB document size 1KB to 151 bytes that's good point I 
>>>> kind of overlooked. Will try to change and check out. 
>>>>
>>>>
>>>> Finally can you please point how to switch compression and didn't 
>>>> understood wipe out data means drop the default database and change the 
>>>> compression and load it again.
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Prasad
>>>>
>>>>
>>>> On Saturday, September 5, 2015 at 8:34:26 AM UTC-7, Rob Moore wrote:
>>>>>
>>>>> On Friday, September 4, 2015 at 6:53:29 PM UTC-4, prasad2019 wrote:
>>>>>>
>>>>>>   Thanks for the pointer, I did used BatchSize parameter for YCSB 
>>>>>> load tests and results went down.
>>>>>>
>>>>>>
>>>>>> Documents Size Operations/Sec YCSB Threads AverageLatency(us) 
>>>>>> 95thPercentileLatency(ms) 99thPercentileLatency(ms)   Remarks 30 
>>>>>> Million 61004 64 1036 0 1   Batchsize=Default 30 Million 50119 64 
>>>>>> 1236 2 3   Batchsize=100
>>>>>>
>>>>>
>>>>> Can you describe your setup a little bit better. What is the MongoDB 
>>>>> configuration? How many servers? Where is the client in relation to the 
>>>>> servers? What version of MongoDB? 
>>>>>
>>>>> On paper batching in a higher latency environment should improve 
>>>>> throughput but I never saw the data to prove it. Asya's blog does not talk 
>>>>> about using it and the configuration for the feature talks about improving 
>>>>> the "load" of the dataset not the run.
>>>>>
>>>>> Also, to match Asya's performance you need to make sure you shrink the 
>>>>> YCSB document size from the default of ~1KB to 151 bytes. In the workload 
>>>>> file set/add:
>>>>>
>>>>> fieldcount=1
>>>>> fieldlength=100
>>>>>
>>>>>  
>>>>>
>>>>>> I also tried setting  Read preferred to Primary 
>>>>>>  "db.getMongo().setReadPref('primaryPreferred')"   and  replaced the 
>>>>>> MongoDB Driver file from 3.0.2 to latest 3.0.3
>>>>>>
>>>>>
>>>>> FYI - You can set the read preference via the MongoDb URI:
>>>>>
>>>>>
>>>>> http://docs.mongodb.org/manual/reference/connection-string/#read-preference-options
>>>>>
>>>>>   
>>>>>
>>>>>> “ log_read: Compressed record with no configured compressor: 
>>>>>> WT_ERROR: non-specific WiredTiger error”
>>>>>>
>>>>>
>>>>> I suspect that switching compression will require you to wipe of the 
>>>>> data files.
>>>>>
>>>>>
>>>>> -- 
>>>> 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...@xxxxxxxxxxxxxxxx.
>>>> To post to this group, send email to mongod...@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/85e254c9-0fd4-49a5-acd0-9c774ecb00ed%40googlegroups.com 
>>>> <https://groups.google.com/d/msgid/mongodb-user/85e254c9-0fd4-49a5-acd0-9c774ecb00ed%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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...@xxxxxxxxxxxxxxxx <javascript:>.
>> To post to this group, send email to mongod...@xxxxxxxxxxxxxxxx 
>> <javascript:>.
>> 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/51aa6800-068d-4292-9b73-eb5cf17bf326%40googlegroups.com 
>> <https://groups.google.com/d/msgid/mongodb-user/51aa6800-068d-4292-9b73-eb5cf17bf326%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/d050bcc5-8942-4e92-b5e9-82c95f266246%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Anterior por Tema] Tema Actual [Siguiente por Tema>