# Aborted compaction **URL:** \ **Category:** Systems\ **Tags:** influxdb\ **Created:** [December 1, 2019, 11:24pm UTC](https://community.influxdata.com/t/aborted-compaction/12144 "2019-12-01T23:24:01Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![somera](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/somera/32/3991_2.png) [@somera](https://community.influxdata.com/u/somera)\ **Post date:** [December 1, 2019, 11:24pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/1 "2019-12-01T23:24:01Z")
Hi, I’m using InfluxDB 1.7.9. And now I have some problems with compaction. My InfluxDB is running on Raspberry Pi. I didn’t have any problems. This is from the syslog: Dec 2 00:21:03 pi-server influxd[1321]: [httpd] 2001:16b8:c215:cd00:61cb:d50c:cadb:fdce - admin [02/Dec/2019:00:21:02 +0100] “POST /write?db=telegraf HTTP/1.1” 204 0 “-” “Telegraf/1.12.6” 3deaa4bd-1491-11ea-875f-b827eb5ed7a5 27091 Dec 2 00:21:03 pi-server influxd[1321]: ts=2019-12-01T23:21:03.628706Z lvl=info msg=“TSM compaction (end)” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7Pdl000 op\_name=tsm1\_compact\_group op\_event=end op\_elapsed=1001.551ms Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627120Z lvl=info msg=“TSM compaction (start)” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group op\_event=start Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627250Z lvl=info msg=“Beginning compaction” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_files\_n=10 Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627310Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=0 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000032-000000003.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627374Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=1 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000064-000000003.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627436Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=2 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000072-000000002.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627497Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=3 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000081-000000002.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627559Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=4 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000089-000000002.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627620Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=5 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000090-000000001.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627681Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=6 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000091-000000001.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627742Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=7 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000092-000000001.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627803Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=8 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000093-000000001.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.627864Z lvl=info msg=“Compacting file” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group tsm1\_index=9 tsm1\_file=/var/lib/influxdb/data/telegraf/autogen/93/000000094-000000001.tsm Dec 2 00:21:04 pi-server influxd[1321]: ts=2019-12-01T23:21:04.628324Z lvl=info msg=“Aborted compaction” log\_id=0JSvpwlG000 engine=tsm1 tsm1\_strategy=full tsm1\_optimize=false trace\_id=0JSx7XSl000 op\_name=tsm1\_compact\_group error=“compaction in progress: open /var/lib/influxdb/data/telegraf/autogen/93/000000094-000000002.tsm.tmp: file exists” InfluxDB is using a lot of RAM and CPU. I restarted InfluxDB. But without any changes. ---
**Author:** ![rawkode](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/rawkode/32/5161_2.png) [@rawkode](https://community.influxdata.com/u/rawkode)\ **Post date:** [December 2, 2019, 12:24pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/2 "2019-12-02T12:24:56Z")
Hi, You can delete the `.tmp` file and retry. This should happen automatically, though there was an issue that we fixed recently that you could be hitting. If you delete the `.tmp` files and this continues, do let us know by opening an issue. It would also help if you confirm which version of InfluxDB you are running. Thanks. NB: This command should help delete `.tmp` files: **WARNING: I have not tested this command, so run it without “-delete” first to see a list of files it finds.** `find /var/lib/influxdb -name "*.tmp" -type f -delete` ---
**Author:** ![somera](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/somera/32/3991_2.png) [@somera](https://community.influxdata.com/u/somera)\ **Post date:** [December 2, 2019, 12:40pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/3 "2019-12-02T12:40:04Z")
Thx. I did this yesterday. Than I converted my indexes from TSM to TSI. I will check this today. But it looks than better. ---
**Author:** ![somera](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/somera/32/3991_2.png) [@somera](https://community.influxdata.com/u/somera)\ **Post date:** [December 2, 2019, 5:56pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/4 "2019-12-02T17:56:38Z")
Today I had the same error in syslog: root@pi-server:/var/log# grep “Aborted compaction” syslog | wc -l 26111 Why this happens? And what can be done to prevent this? ---
**Author:** ![Esity](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/esity/32/5864_2.png) [@Esity](https://community.influxdata.com/u/Esity)\ **Post date:** [December 3, 2019, 4:27pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/5 "2019-12-03T16:27:29Z")
Trying this process Stop the influxdb service delete the tmp files like @rawkode said earlier run a chown -R command on /var/lib/influxdb to make sure all the permissions are set correctly restart the influxdb service If that doesn’t work, I would try rebuilding your tsi index. Make sure the service is stopped when you do this! > **[Rebuild the TSI index | InfluxDB OSS 1.8 Documentation](https://docs.influxdata.com/influxdb/v1.7/administration/rebuild-tsi-index/)** > > Use the influxd\_inspect buildtsi command to rebuild your InfluxDB TSI index. ---
**Author:** ![somera](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/somera/32/3991_2.png) [@somera](https://community.influxdata.com/u/somera)\ **Post date:** [December 5, 2019, 6:27am UTC](https://community.influxdata.com/t/aborted-compaction/12144/6 "2019-12-05T06:27:39Z")
I did this. But after 2-3 days the problem with “Aborted compaction” is back. Why so often?! I’m using it on Raspberry Pi with SQLlite DB. ---
**Author:** ![somera](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/somera/32/3991_2.png) [@somera](https://community.influxdata.com/u/somera)\ **Post date:** [December 5, 2019, 7:20pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/7 "2019-12-05T19:20:37Z")
I know now the problem. This is the 32 Bit problem with “cannot allocate memory” during the process. ---
**Author:** ![davidgs](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/davidgs/32/6936_2.png) [@davidgs](https://community.influxdata.com/u/davidgs)\ **Post date:** [December 5, 2019, 8:11pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/8 "2019-12-05T20:11:58Z")
My experience is that you need to pay close attention to your shard size on these SBCs due to their limited RAM space. If you use too large a shard size you will eventually end up in an OOM-loop (Out Of Memory) while trying to compact shards. dg ---
**Author:** ![somera](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/somera/32/3991_2.png) [@somera](https://community.influxdata.com/u/somera)\ **Post date:** [December 5, 2019, 8:37pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/9 "2019-12-05T20:37:56Z")
Can you give here some tips? ---
**Author:** ![davidgs](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/davidgs/32/6936_2.png) [@davidgs](https://community.influxdata.com/u/davidgs)\ **Post date:** [December 5, 2019, 8:42pm UTC](https://community.influxdata.com/t/aborted-compaction/12144/10 "2019-12-05T20:42:52Z")
Here are the docs on it: [Database management using InfluxQL | InfluxDB OSS 1.7 Documentation](https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#create-retention-policies-with-create-retention-policy) But it all depends on how much data you are writing to the DB. If you are writing a lot of data – your shards will be large – you’ll want the duration shorter. It’s really a function of how long your retention policy is, and how much data is in each shard, based on the data ingestion rate. dg