influxdb - DB 文件夹占用大量空间,造成空间问题

标签 influxdb grafana

我有一个grafana Windows服务器。我们集成了HyperV快照相关信息以及HV的CPU、内存使用情况等。我可以在我们的grafana Windows服务器中看到下面的文件夹

C:\InfluxDB\data\telegraf\autogen

在此 autogen 文件夹下,我可以看到多个包含 .tsm 文件的子文件夹。每个文件每 7 天创建一次,文件夹大小约为 4 到 5GB。从2017年2月2日到2018年3月14日,这个autogen文件夹中有许多文件,占用了大约225GB的空间。

最佳答案

你所看到的: autogen 是默认值 Retention Policy (RP)由 InfluxDB 自动创建,具有无限的数据保留期限。 Influx 中的所有数据点逻辑上都存储在 shards 中。物理分片数据被压缩并存储在 .tsm 文件中。分片被统一为分片组。每个分片组覆盖由所谓的shard duration定义的特定时间范围。并存储属于该时间间隔的数据点。 By default对于保留期限 > 6 个月的 RP,分片组持续时间设置为 7 天

有关详细信息,请参阅 storage engine 上的文档.

关于您的问题:

  • “我们是否可以缩小 autogen 文件的大小?”
    可能不会。你唯一能做的就是依靠 InfluxDB 内部压缩。 Here他们说,如果增加分片持续时间,情况可能会有所改善。
    *尽管如此,因为 InfluxDB 会删除整个分片而不是单独的数据点,所以分片持续时间的增加将使您的数据被存储,直到整个分片超出当前保留持续时间的范围,然后才会存储数据。被丢弃。不过,如果您有无限的保留期限,那也没关系。这就引出了第二个问题。
  • “是否可以删除autogen文件夹下的旧文件?”
    如果您可以承受丢失旧数据的后果或者无法承受太多的存储空间,InfluxDB 可以指定数据保留策略(RP),上面已经提到过。基本上,您的所有测量值都与特定的 RP 相关联,并且一旦保留期限结束,数据将被删除。因此,如果您指定 1 年的 RP,InfluxDB 将自动删除早于 now() - 1 年 的所有数据点。 RP 是处理存储问题的标准(而且非常明显)的方法。 RP 思想的逻辑延续是在较长的离散时间间隔内对数据进行分组和聚合(下采样)。在 Influx 中,可以通过连续查询(CQ)来实现。您可以阅读更多data retention and downsamping here

总而言之,存储限制是不可避免的,正确配置保留策略才是正确的选择。

关于influxdb - DB 文件夹占用大量空间,造成空间问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49270692/

相关文章:

influxdb - 电报中的间隔与flush_interval

influxdb - 在 Platfrom.sh 上访问 InfluxDB

MySQL 将时间转换为字符串 (Grafana)

Grafana + InfluxDB Flux - 用于显示多选变量输入的查询

aggregate - 具有连续计数器的流入聚合窗口

influxdb - 当 select count 没有结果时返回 0 而不是 N/A (null)

ubuntu - 如何正确配置 telegraf 以写入来自 MQTT 的 InfluxDB 数据

graphite - 在grafana中将多个系列相互划分

grafana - 使用 prometheus 和 grafana 跟踪事件

Grafana 7.4.3/var/lib/grafana 在 AWS ECS 中不可写入 - EFS