activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lionel Cons (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APLO-245) The LevelDB store does not seem to get cleaned/compacted
Date Mon, 20 Aug 2012 05:15:38 GMT

    [ 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

        

Mime
View raw message