Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1763ED320 for ; Fri, 19 Oct 2012 04:54:05 +0000 (UTC) Received: (qmail 66710 invoked by uid 500); 19 Oct 2012 04:54:01 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 66456 invoked by uid 500); 19 Oct 2012 04:54:01 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 66409 invoked by uid 99); 19 Oct 2012 04:53:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Oct 2012 04:53:59 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of wangjundot@gmail.com designates 209.85.160.48 as permitted sender) Received: from [209.85.160.48] (HELO mail-pb0-f48.google.com) (209.85.160.48) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Oct 2012 04:53:51 +0000 Received: by mail-pb0-f48.google.com with SMTP id wy7so171339pbc.35 for ; Thu, 18 Oct 2012 21:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3D8gQ/9P8LMaXfBpvpFhTdestm7KKcH/+KfHs9F4C38=; b=YuqR3Yy3QH5D1bdtvPQmAqEioJu8jEHK1hMk3g0OoLsDpTO3mYlZUSgsThUU34Gb99 PdQXZmn/fxzeQNl7gOsNo1OFnUD3YiJNNkCmqXNRLWnEbr/pcYRNAiIKcHr7QIQl7jLT crGp6iolt1VO9m2AAzPiBZrxUEC6/oSY32RAAZ21UrApwLESul3gbVsp2shJcbQKSzOv zs8Ypy105zW+owfxbLsD4zcdrch7SSjjEhMQ6dzYYMDu9yaSVUKDChiYZl4iiXdYYxSq 8ISRk7/9eiLUeTsQu80sswaQZT4+Q96WOr9Okq4qpqALNQP46wvUsYDQAvEnbkpTC/Sh /xMQ== MIME-Version: 1.0 Received: by 10.68.239.198 with SMTP id vu6mr1740095pbc.109.1350622410424; Thu, 18 Oct 2012 21:53:30 -0700 (PDT) Received: by 10.66.159.133 with HTTP; Thu, 18 Oct 2012 21:53:30 -0700 (PDT) Date: Fri, 19 Oct 2012 12:53:30 +0800 Message-ID: Subject: Solr 4.0 segment flush times has bigger difference between tow machines From: Jun Wang To: solr-user@lucene.apache.org Content-Type: multipart/alternative; boundary=047d7b2e119dffbfb104cc62482e X-Virus-Checked: Checked by ClamAV on apache.org --047d7b2e119dffbfb104cc62482e Content-Type: text/plain; charset=ISO-8859-1 Hi I have 2 machine for a collection, and it's using DIH to import data, DIH is trigger via url request at one machine, let's call it A, and A will forward some index to machine B. Recently I have found that segment flush happened more in machine B. here is part of INFOSTREAM.txt. Machine A: ---------------------------- DWPT 0 [Thu Oct 18 20:06:20 PDT 2012; Thread-39]: flush postings as segment _4r3 numDocs=71616 DWPT 0 [Thu Oct 18 20:06:21 PDT 2012; Thread-39]: new segment has 0 deleted docs DWPT 0 [Thu Oct 18 20:06:21 PDT 2012; Thread-39]: new segment has no vectors; no norms; no docValues; prox; freqs DWPT 0 [Thu Oct 18 20:06:21 PDT 2012; Thread-39]: flushedFiles=[_4r3_Lucene40_0.prx, _4r3.fdt, _4r3.fdx, _4r3.fnm, _4r3_Lucene40_0.tip, _4r3_Lucene40_0.tim, _4r3_Lucene40_0.frq] DWPT 0 [Thu Oct 18 20:06:21 PDT 2012; Thread-39]: flushed codec=Lucene40 D Machine B ---------------------------------- DWPT 0 [Thu Oct 18 21:41:22 PDT 2012; http-0.0.0.0-8080-3]: flush postings as segment _zi0 numDocs=4302 DWPT 0 [Thu Oct 18 21:41:22 PDT 2012; http-0.0.0.0-8080-3]: new segment has 0 deleted docs DWPT 0 [Thu Oct 18 21:41:22 PDT 2012; http-0.0.0.0-8080-3]: new segment has no vectors; no norms; no docValues; prox; freqs DWPT 0 [Thu Oct 18 21:41:22 PDT 2012; http-0.0.0.0-8080-3]: flushedFiles=[_zi0_Lucene40_0.prx, _zi0.fdx, _zi0_Lucene40_0.tim, _zi0.fdt, _zi0.fnm, _zi0_Lucene40_0.frq, _zi0_Lucene40_0.tip] DWPT 0 [Thu Oct 18 21:41:22 PDT 2012; http-0.0.0.0-8080-3]: flushed codec=Lucene40 D I have found that flush occured when number of doc in RAM reached 70000~9000 in machine A, but the number in machine B is very different, almost is 4000. It seem that every doc in buffer used more RAM in machine B then machine A, that result in more flush . Does any one know why this happened? My conf is here. 64100000 -- from Jun Wang --047d7b2e119dffbfb104cc62482e--