Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Mon, 20 Aug 2012 16:15:38 +1100 (NCT)
From: "Lionel Cons (JIRA)" <jira@apache.org>
To: commits@activemq.apache.org
Message-ID: <375259694.28878.1345439738074.JavaMail.jiratomcat@arcas>
In-Reply-To: <2124066341.22790.1345191278057.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (APLO-245) The LevelDB store does not seem to
 get cleaned/compacted
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/APLO-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437660#comment-13437660 ] 

Lionel Cons commented on APLO-245:
----------------------------------

In fact, we looked at this broker because of poor response time. A loop test (sending and receiving a small message) takes around 8 seconds over a topic versus less than 20 ms on another identical hardware. The main difference being the LevelDB files (which are stored over NAS), this is the first thing we looked at.

Can uncompacted LevelDB files cause a performance degradation?

If not, what could explain the poor performance we see on this broker? (FWIW, we use slow_consumer_policy=queue so our topic loop test includes the creation of a temporary queue)
                
> The LevelDB store does not seem to get cleaned/compacted
> --------------------------------------------------------
>
>                 Key: APLO-245
>                 URL: https://issues.apache.org/jira/browse/APLO-245
>             Project: ActiveMQ Apollo
>          Issue Type: Bug
>            Reporter: Lionel Cons
>
> We use the default message store: LevelDB.
> On one broker with poor performance, we noticed a quite big store (file system wise) while there are zero messages in the queues.
> In concrete terms, the REST API reports for the aggregated dest-metrics:
>   'queue_items' => 0,
>   'queue_size' => 0,
> While on the box itself, in the data directory, we see:
> $ du -ks .
> 434992	.
> $ find . -type f | wc -l
> 471
> So 400MB and 471 files is a lot to hold zero messages...
> FWIW, the store page in the console reports something quite different:
> disk usage: 760.689 mb
> Log Status
> Log File             | Msg Refs   | File Size 
> 0000003a0eb4031b.log | 0          | 100.000 mb
> Index recovery starts from log position: 0000003a0eb4031b
> Append position: 0000003a13bed684
> Index Status
>                                Compactions
> Level  Files Size(MB) Time(sec) Read(MB) Write(MB)
> --------------------------------------------------
>   0        0        0         0        0         2
>   1        7        9         2       12         9
>   2      108       91         0        0         0
>   3      114      227         0        0         0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira