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 Wed, 30 Jan 2013 13:37:12 GMT

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

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

Indeed, we see Apollo triggering compaction:

2013-01-29 18:35:34,782 | INFO  | Compacting the leveldb index at: /var/lib/apollo/data/dirty.index
| 
2013-01-29 18:53:45,720 | INFO  | Compacting the leveldb index at: /var/lib/apollo/data/dirty.index
| 
2013-01-29 18:54:56,379 | INFO  | Compacting the leveldb index at: /var/lib/apollo/data/dirty.index
| 
2013-01-29 19:09:17,156 | INFO  | Compacting the leveldb index at: /var/lib/apollo/data/dirty.index
| 
2013-01-29 19:21:07,598 | INFO  | Compacting the leveldb index at: /var/lib/apollo/data/dirty.index
| 
2013-01-29 19:32:58,434 | INFO  | Compacting the leveldb index at: /var/lib/apollo/data/dirty.index
| 

Unfortunately, it now uses a lot of CPU and becomes unresponsive. Can this be linked to this
compaction?
                
> 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
>          Components: apollo-leveldb
>            Reporter: Lionel Cons
>            Assignee: Hiram Chirino
>             Fix For: 1.5, 1.6
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message