kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian McCague (JIRA)" <j...@apache.org>
Subject [jira] [Created] (KAFKA-8042) Kafka Streams creates many segment stores on state restore
Date Tue, 05 Mar 2019 18:14:00 GMT
Adrian McCague created KAFKA-8042:

             Summary: Kafka Streams creates many segment stores on state restore
                 Key: KAFKA-8042
                 URL: https://issues.apache.org/jira/browse/KAFKA-8042
             Project: Kafka
          Issue Type: Bug
          Components: streams
    Affects Versions: 2.1.1, 2.1.0
            Reporter: Adrian McCague
         Attachments: StateStoreSegments-StreamsConfig.txt

Note that this from the perspective of one instance of an application, where there are 8 instances
total, with partition count 8 for all topics and of course stores. Standby replicas = 1.

h2. Actual Behaviour

During state restore of an application, many segment stores are created (I am using MANIFEST
files as a marker since they preallocate 4MB each):
bash-4.2# pwd
bash-4.2# for dir in $(find . -maxdepth 1 -type d); do echo "${dir}: $(find ${dir} -type f
-name 'MANIFEST-*' -printf x | wc -c)"; done
.: 8058
./KSTREAM-JOINOTHER-0000000025-store: 851
./KSTREAM-JOINOTHER-0000000040-store: 819
./KSTREAM-JOINTHIS-0000000024-store: 851
./KSTREAM-JOINTHIS-0000000029-store: 836
./KSTREAM-JOINOTHER-0000000035-store: 819
./KSTREAM-JOINOTHER-0000000030-store: 819
./KSTREAM-JOINOTHER-0000000045-store: 745
./KSTREAM-JOINTHIS-0000000039-store: 819
./KSTREAM-JOINTHIS-0000000044-store: 685
./KSTREAM-JOINTHIS-0000000034-store: 819

There are many (x800 as above) of these segment files:

Once re-balancing and state restoration is complete - the redundant segment files are deleted
and the segment count drops to 508.

We have seen the number of these segment stores grow to as many as 15000 over the baseline
508 which can fill smaller volumes. *This means that a state volume that would normally have
~300MB total disk usage would use in excess of 30GB during rebalancing*, mostly preallocated

h2. Expected Behaviour

For this particular application we expect 508 segment folders total to be active and existing
throughout rebalancing. Give or take migrated tasks that are subject to the {{state.cleanup.delay.ms}}.

h2. Preliminary investigation

* This does not appear to be the case in v1.1.0. With our application the number of state
directories only grows to 670 (over the base line 508)
* The MANIFEST files were not preallocated to 4MB in v1.1.0 they are now in v2.1.x, this appears
to be expected RocksDB behaviour, but exacerbates the many segment stores.
* Suspect https://github.com/apache/kafka/pull/5253 to be the source of this change of behaviour.

A workaround is to use {{rocksdb.config.setter}} and set the preallocated amount for MANIFEST
files to a lower value such as 64KB, however the number of segment stores appears to be unbounded
so disk volumes may still fill up for a heavier application.

This message was sent by Atlassian JIRA

View raw message