Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DB035D594 for ; Sat, 22 Sep 2012 11:40:14 +0000 (UTC) Received: (qmail 86742 invoked by uid 500); 22 Sep 2012 11:40:11 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 86582 invoked by uid 500); 22 Sep 2012 11:40:10 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 86539 invoked by uid 99); 22 Sep 2012 11:40:09 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Sep 2012 11:40:09 +0000 Date: Sat, 22 Sep 2012 22:40:09 +1100 (NCT) From: "Robert Muir (JIRA)" To: dev@lucene.apache.org Message-ID: <1546663008.111464.1348314009505.JavaMail.jiratomcat@arcas> In-Reply-To: <1884886112.110037.1343384974602.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Updated] (SOLR-3685) Solr Cloud sometimes skipped peersync attempt and replicated instead due to tlog flags not being cleared when no updates were buffered during a previous replication. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SOLR-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-3685: ------------------------------ Fix Version/s: (was: 4.0) 4.1 > Solr Cloud sometimes skipped peersync attempt and replicated instead due to tlog flags not being cleared when no updates were buffered during a previous replication. > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SOLR-3685 > URL: https://issues.apache.org/jira/browse/SOLR-3685 > Project: Solr > Issue Type: Bug > Components: replication (java), SolrCloud > Affects Versions: 4.0-ALPHA > Environment: Debian GNU/Linux Squeeze 64bit > Solr 5.0-SNAPSHOT 1365667M - markus - 2012-07-25 19:09:43 > Reporter: Markus Jelsma > Assignee: Yonik Seeley > Priority: Critical > Fix For: 4.1, 5.0 > > Attachments: info.log, oom-killer.log, pmap.log > > > There's a serious problem with restarting nodes, not cleaning old or unused index directories and sudden replication and Java being killed by the OS due to excessive memory allocation. Since SOLR-1781 was fixed index directories get cleaned up when a node is being restarted cleanly, however, old or unused index directories still pile up if Solr crashes or is being killed by the OS, happening here. > We have a six-node 64-bit Linux test cluster with each node having two shards. There's 512MB RAM available and no swap. Each index is roughly 27MB so about 50MB per node, this fits easily and works fine. However, if a node is being restarted, Solr will consistently crash because it immediately eats up all RAM. If swap is enabled Solr will eat an additional few 100MB's right after start up. > This cannot be solved by restarting Solr, it will just crash again and leave index directories in place until the disk is full. The only way i can restart a node safely is to delete the index directories and have it replicate from another node. If i then restart the node it will crash almost consistently. > I'll attach a log of one of the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org