一篇文章彻底搞懂TiDB集群各种容量计算方式

news2024/11/16 4:38:17

背景

TiDB 集群的监控面板里面有两个非常重要、且非常常用的指标，相信用了 TiDB 的都见过：

企业微信截图_20231220162826.png

  • Storage capacity：集群的总容量

  • Current storage size：集群当前已经使用的空间大小

当你准备了一堆服务器，经过各种思考设计部署了一个 TiDB 集群，有没有想过这两个指标和服务器磁盘之间到底是啥关系？

反正我们经常被客户问这个问题，以前虽然能说出个大概，总体方向上没错，但是深究一下其实并不严谨，这次翻了源码彻底把这个问题搞清楚。开始之前再卖一个关子，大家可以看看自己手上的集群监控有没有这种情况：

企业微信截图_20231220165625.png

TiKV 实例的已用空间（store size）+ 可用空间（available size） ≠ 总空间（capacity size）

盘越大越明显。

再仔细点看，监控上显示的总容量大小和 TiKV 实例所在盘大小也不匹配。

是不是有亿点意外。

结论先行

  • PD 监控下的Storage capacity和 Current storage size来自各个 store 的累加，这里 store 包含了 TiKV 和 TiFlash

  • Current storage size包含了多个数据副本（TiKV 和 TiFlash 的所有副本数），非真实数据大小

  • TiKV 实例容量统计的是 TiKV 所在磁盘的整体大小与raftstore.capacity参数较小的值，同时监控用的 bytes(SI) 标准显示，就是说不是用1024做的转换而是1000，所以和df -h输出的盘大小有差距

  • TiKV 实例的已用空间只统计了data-dir下的部分目录，非整个data-dir或整块盘

  • 基于前两条，可用空间也就不等于总空间减去已用空间了

看到的现象

本文描述的内容基于以下集群：

[tidb@localhost ~]$ tiup cluster display tidb-test
tiup is checking updates for component cluster ...
Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.13.0/tiup-cluster display tidb-test
Cluster type:       tidb
Cluster name:       tidb-test
Cluster version:    v6.5.5
Deploy user:        tidb
SSH type:           builtin
Dashboard URL:      http://x.236:2379/dashboard
Grafana URL:        http://x.242:3000
ID          Role        Host    Ports        OS/Arch       Status   Data Dir     Deploy Dir
--          ----        ----    -----        -------       ------   --------     ----------
x.242:3000   grafana     x.242  3000         linux/x86_64  Up       -            /data/tidb-deploy/grafana-3000
x.235:2379   pd          x.235  2379/2380    linux/x86_64  Up       /data/tidb-data/pd-2379               /data/tidb-deploy/pd-2379
x.236:2379   pd          x.236  2379/2380    linux/x86_64  Up|L|UI  /data/tidb-data/pd-2379               /data/tidb-deploy/pd-2379
x.237:2379   pd          x.237  2379/2380    linux/x86_64  Up       /data/tidb-data/pd-2379               /data/tidb-deploy/pd-2379
x.242:9090   prometheus  x.242  9090/12020   linux/x86_64  Up       /data/tidb-data/prometheus-9090       /data/tidb-deploy/prometheus-9090
x.235:4000   tidb        x.235  4000/10080   linux/x86_64  Up       -            /data/tidb-deploy/tidb-4000
x.236:4000   tidb        x.236  4000/10080   linux/x86_64  Up       -             /data/tidb-deploy/tidb-4000
x.237:4000   tidb        x.237  4000/10080   linux/x86_64  Up       -             /data/tidb-deploy/tidb-4000
x.241:9000   tiflash     x.241  9000/8123/3930/20170/20292/8234  linux/x86_64  Up /data/tiflash/tidb-data/tiflash-9000  /data/tiflash/tidb-deploy/tiflash-9000
x.238:20160  tikv        x.238  20160/20180  linux/x86_64  Up       /data/tidb-data/tikv-20160            /data/tidb-deploy/tikv-20160
x.239:20160  tikv        x.239  20160/20180  linux/x86_64  Up       /data/tidb-data/tikv-20160            /data/tidb-deploy/tikv-20160
x.240:20160  tikv        x.240  20160/20180  linux/x86_64  Up       /data/tidb-data/tikv-20160            /data/tidb-deploy/tikv-20160

各节点磁盘情况（来自TiDB Dashboard统计）：

企业微信截图_20231222145642.png

在此之前，我一直以为 PD 监控面板下的集群总空间是 PD 读取了所有 TiKV+TiFlash 实例部署盘的累计大小，所以我尝试把上图的4个存储节点的磁盘容量相加发现并不等于集群总容量（文章开头的图片有显示），差了100多个G：

Dashboard上4个存储节点磁盘容量均为475.8G，累计容量475.8G * 4 = 1903.2G

Grafana显示的单个 TiKV 实例：510.9G，总空间：2.04 T

再和操作系统显示的磁盘容量对比，发现能和 Dashboard 显示的对应上：

[tidb@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  476G  347G  110G  77% /
devtmpfs                  31G     0   31G   0% /dev
tmpfs                     31G  4.0K   31G   1% /dev/shm
tmpfs                     31G  3.1G   28G  10% /run
tmpfs                     31G     0   31G   0% /sys/fs/cgroup
/dev/sda1                477M  138M  310M  31% /boot

但仔细看容量单位的区别，发现 Dashboard 显示的是GiB，Grafana 显示的是GB，两者是有区别的。尝试在系统中用GB显示磁盘大小：

[tidb@localhost ~]$ df -H
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  511G  372G  118G  77% /
devtmpfs                  34G     0   34G   0% /dev
tmpfs                     34G  4.1k   34G   1% /dev/shm
tmpfs                     34G  3.3G   30G  10% /run
tmpfs                     34G     0   34G   0% /sys/fs/cgroup
/dev/sda1                500M  145M  325M  31% /boot

这里输出的511G能和 Grafana 监控对应上，同时按4个511G的存储节点计算也能和总容量对应上。

但是用同样的方法并不能解释 TiKV 已用空间的偏差问题，检查结果如下：

# 输出内容为240节点tikv数据目录大小，但监控显示tikv已用空间333.7GB
[tidb@localhost ~]$ du -sh /data/tidb-data/tikv-20160
329G    /data/tidb-data/tikv-20160
[tidb@localhost ~]$ du -sh --si /data/tidb-data/tikv-20160
353G    /data/tidb-data/tikv-20160

总结一下看到的现象：

  • Dashboard 上显示的 TiKV 盘大小（GiB）是实际部署盘的总大小，Grafana 也是部署盘的总大小但单位是GB

  • Grafana 集群总容量是所有存储节点部署盘的累计大小（GB）

  • TiKV 实例已用空间大小计算方式未知（要搞清楚只能扒源码了）

不同进制转换带来的影响

这里简单提一下GB和GiB的区别，帮助大家理解。

  • GB 是按10进制来转换，也就是说1GB=1000MB，市面上厂商宣传的大小都是10进制，可理解为商业标准

  • GiB 是按2进制来转换，也就是说1GiB=1024MiB，计算机系统只认这个，可理解为事实标准

那么当你买了一台128G存储的手机，实际使用中会发现空间“缩水”了，U盘、硬盘等也类似。

与这两个进制差异有关的还有两个行业标准，即byte(SI)和byte(IEC)，感兴趣的可以去查一下历史，这里只需要知道：

  • byte(SI)对应十进制

  • byte(IEC)对应二进制

Grafana 里面可以使用编辑监控面板调整显示单位，例如：

企业微信截图_20231222164440.png

如果把单位统一的话，前2个现象就很好解释了。

但需要注意的是，在 Grafana 中并不是所有面板都采用了byte(SI)，甚至同一个指标也出现不同面板显示的单位不一样，比如Overview下面的TiDB分组内存面板使用十进制，System Info分组内存面板使用二进制，用的时候要小心。

TiKV 的数据文件

要搞清楚 TiKV 的已用空间是怎么计算的，先提一下 TiKV 相关的数据文件。大家都知道 TiKV 底层用的 RocksDB 作为持久层，并且 raft 日志和实际数据分别对应一个RocksDB 实例，那么看看 TiKV 的数据目录到底放了啥东西，以前面的集群为例：

[tidb@localhost ~]$ cd /data/tidb-data/tikv-20160
[tidb@localhost tikv-20160]$ ll -h
total 14G
drwxr-xr-x 2 tidb tidb 1.1M Dec 22 15:22 db
drwxr-xr-x 4 tidb tidb 132K Dec 21 18:20 import
-rw-r--r-- 1 tidb tidb  20K Nov 15 14:47 last_tikv.toml
-rw-r--r-- 1 tidb tidb    0 Nov 15 14:53 LOCK
-rw-r--r-- 1 tidb tidb 301M Mar  3  2023 raftdb-2023-03-03T17-32-13.506.info
...
-rw-r--r-- 1 tidb tidb 301M Nov 13 21:51 raftdb-2023-11-13T21-51-00.249.info
-rw-r--r-- 1 tidb tidb  31M Nov 15 14:47 raftdb.info
drwxr-xr-x 2 tidb tidb 4.0K Dec 22 00:08 raft-engine
-rw-r--r-- 1 tidb tidb 301M Jan 18  2023 rocksdb-2023-01-18T10-12-55.000.info
...
-rw-r--r-- 1 tidb tidb 301M Dec  7 03:01 rocksdb-2023-12-07T03-01-02.905.info
-rw-r--r-- 1 tidb tidb 197M Dec 22 17:11 rocksdb.info
drwxr-xr-x 2 tidb tidb 4.0K Dec 21 16:27 snap
-rw-r--r-- 1 tidb tidb 4.8G Nov 15 14:53 space_placeholder_file

几类文件解读一下：

  • db 目录，这是最终数据的存放目录，db在源码中写死无法修改

  • rocksdb[-xxx-xxx].info文件，数据 RocksDB 实例的日志文件，已经按日期归档好的可手动删除

  • raft-engine 目录，这是 raft 日志存放目录，受参数raft-engine.dir控制，没有开启Raft Engine特性时名称默认为raft，受参数raftstore.raftdb-path控制

  • raftdb[-xxx-xxx].info文件，raft日志 RocksDB 实例的日志文件，已经按日期归档好的可手动删除

  • snap 目录，快照数据存放目录

  • import 目录，看名字是和导入相关，具体什么作用未知

  • space_placeholder_file 文件，预留空间的临时文件（TiKV磁盘告警救急用，磁盘越大这个文件越大），相关参数storage.reserve-space

  • last_tikv.toml 和 LOCK 文件，看名字猜测就行

从前面的观察来看，被监控统计到的 TiKV 已用空间比整个数据目录要小，那么可以推测出只统计了数据目录下的部分文件或目录，具体是哪些就要从源码里寻找答案。

Show Me The Code

TiDB的监控数据分为两类，一类是服务器环境信息（CPU、内存、磁盘、网络等），一类是TiDB运行指标（Duration、QPS、Region数、容量等）。前者通过与Prometheus配套的标准探针采集，即node_exporter和black_exporter，后者通过在源码中类似埋点方式采集数据然后由Prometheus来拉取。

import (
    ...
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/collectors"
    ...
)
​
var (
    // PanicCounter measures the count of panics.
    PanicCounter *prometheus.CounterVec
​
    // MemoryUsage measures the usage gauge of memory.
    MemoryUsage *prometheus.GaugeVec
)

以集群总容量这个指标入手，看看在源码中它是如何采集的。对应的公式：

pd_cluster_status{k8s_cluster="$k8s_cluster", tidb_cluster="$tidb_cluster", instance="$instance",type="storage_capacity"}

用关键字storage_capacity去 PD 源码里搜索找到如下代码：

func (s *storeStatistics) Collect() {
    placementStatusGauge.Reset()
​
    metrics := make(map[string]float64)
    ...
    metrics["storage_capacity"] = float64(s.StorageCapacity)
​
    for typ, value := range metrics {
        clusterStatusGauge.WithLabelValues(typ).Set(value)
    }
    ...
}

数据来自storeStatistics的StorageCapacity字段，根据引用关系继续往上翻：

func (s *storeStatistics) Observe(store *core.StoreInfo) {
    ...
    // Store stats.
    s.StorageSize += store.StorageSize()
    s.StorageCapacity += store.GetCapacity()
    ...
}

从这里可以看出总容量（Storage capacity）和总已用空间（Current storage size）都是从各个store累加得来，并不是pd直接从存储节点计算。

继续看GetCapacity()是如何实现：

func (ss *storeStats) GetCapacity() uint64 {
    ss.mu.RLock()
    defer ss.mu.RUnlock()
    return ss.rawStats.GetCapacity()
}
func newStoreStats() *storeStats {
    return &storeStats{
        rawStats:     &pdpb.StoreStats{},
        avgAvailable: movingaverage.NewHMA(60), // take 10 minutes sample under 10s heartbeat rate
    }
}

这里rawStats 是一个pdpb.StoreStats类型，引用了另一个仓库：GitHub - pingcap/kvproto: Protocol buffer files for TiKV 。最终实现为：

// https://github.com/pingcap/kvproto/blob/master/pkg/pdpb/pdpb.pb.go#L4371C1-L4376C2
func (m *StoreStats) GetCapacity() uint64 {
    if m != nil {
        return m.Capacity
    }
    return 0
}

从调用关系来看，说明 PD 采集的数据都是来自 TiKV 上报（heartbeat）。继续追踪 TiKV 源码，以heartbeat为突破口：

pub fn handle_store_heartbeat(
        &mut self,
        mut stats: pdpb::StoreStats,
        is_fake_hb: bool,
        store_report: Option<pdpb::StoreReport>,
    ) {
        ...
        let (capacity, used_size, available) = self.collect_engine_size().unwrap_or_default();
        if available == 0 {
            warn!(self.logger, "no available space");
        }
​
        stats.set_capacity(capacity);
        stats.set_used_size(used_size);
        stats.set_available(available);
        ...
  }

这里的stats正是一个pdpb::StoreStats类型，我们想要分析的3个指标都在这，继续看他们的出处collect_engine_size():

fn collect_engine_size<EK: KvEngine, ER: RaftEngine>(
    coprocessor_host: &CoprocessorHost<EK>,
    store_info: Option<&StoreInfo<EK, ER>>,
    snap_mgr_size: u64,
) -> Option<(u64, u64, u64)> {
    if let Some(engine_size) = coprocessor_host.on_compute_engine_size() {
        return Some((engine_size.capacity, engine_size.used, engine_size.avail));
    }
    let store_info = store_info.unwrap();
    // 这里跟根据kv engine的目录（${data_dir}/db）获取了所在磁盘的信息
    let disk_stats = match fs2::statvfs(store_info.kv_engine.path()) {
        Err(e) => {
            error!(
                "get disk stat for rocksdb failed";
                "engine_path" => store_info.kv_engine.path(),
                "err" => ?e
            );
            return None;
        }
        Ok(stats) => stats,
    };
    // total_space得到磁盘的总容量，参考API：https://docs.rs/fs2/latest/fs2/fn.total_space.html
    let disk_cap = disk_stats.total_space();
    // 计算得出tikv实例的容量，用磁盘容量与参数设置的容量（raftstore.capacity）相比
    // 如果没有设置raftstore.capacity参数，或者是磁盘容量小于设置的容量，那么取磁盘容量，否则取设置的容量，本质就是取较小的那个
    let capacity = if store_info.capacity == 0 || disk_cap < store_info.capacity {
        disk_cap
    } else {
        store_info.capacity
    };
    // 计算已用大小，快照大小（snap目录） + kv engine大小（db目录） + raft engine大小（raft-engine目录）
    let used_size = snap_mgr_size
        + store_info
            .kv_engine
            .get_engine_used_size()
            .expect("kv engine used size")
        + store_info
            .raft_engine
            .get_engine_size()
            .expect("raft engine used size");
    // 计算逻辑可用空间，总容量-已用空间
    let mut available = capacity.checked_sub(used_size).unwrap_or_default();
    // We only care about rocksdb SST file size, so we should check disk available
    // here.
    // 最终可用空间是取逻辑可用和磁盘可用的较小值
    available = cmp::min(available, disk_stats.available_space());
    Some((capacity, used_size, available))
}

核心逻辑分析都写在注释里，值得认真一看！

以为扒到这里就happy ending了，但是偶然又发现了另一个方法让我陷入沉思：

    fn init_storage_stats_task(&self, engines: Engines<RocksEngine, ER>) {
        ...
        self.background_worker
            .spawn_interval_task(DEFAULT_STORAGE_STATS_INTERVAL, move || {
                let disk_stats = match fs2::statvfs(&store_path) {
                    Err(e) => {
                        error!(
                            "get disk stat for kv store failed";
                            "kv path" => store_path.to_str(),
                            "err" => ?e
                        );
                        return;
                    }
                    Ok(stats) => stats,
                };
                let disk_cap = disk_stats.total_space();
                let snap_size = snap_mgr.get_total_snap_size().unwrap();
​
                let kv_size = engines
                    .kv
                    .get_engine_used_size()
                    .expect("get kv engine size");
​
                let raft_size = engines
                    .raft
                    .get_engine_size()
                    .expect("get raft engine size");
               ...
                let placeholer_file_path = PathBuf::from_str(&data_dir)
                    .unwrap()
                    .join(Path::new(file_system::SPACE_PLACEHOLDER_FILE));
​
                let placeholder_size: u64 =
                    file_system::get_file_size(placeholer_file_path).unwrap_or(0);
                // 这里的已用空间计算方式与heartbeat有区别，把space_placeholder_file文件算进去了，还加了raft engine单独部署的逻辑
                let used_size = if !separated_raft_mount_path {
                    snap_size + kv_size + raft_size + placeholder_size
                } else {
                    snap_size + kv_size + placeholder_size
                };
                let capacity = if config_disk_capacity == 0 || disk_cap < config_disk_capacity {
                    disk_cap
                } else {
                    config_disk_capacity
                };
​
                let mut available = capacity.checked_sub(used_size).unwrap_or_default();
                available = cmp::min(available, disk_stats.available_space());
                ...
            })
    }

init_storage_stats_task在tikv启动时被调用，就是说这是几个指标在初始化时的计算方式，整体逻辑与heartbeat上报并无区别，但已用空间计算方式有轻微差异：

  • space_placeholder_file 被算进去了

  • 如果raft engine使用了单独的部署目录（代码里叫path_in_diff_mount_point），那么raft日志的大小是不算在tikv已用空间内的

看起来前后计算不一致，但是由于heartbeat是持续更新的，最终是以heartbeat上报的为准。

这个差异准备提issue问问看。

PD 源码仓库：GitHub - tikv/pd: Placement driver for TiKV

TiKV 源码仓库：GitHub - tikv/tikv: Distributed transactional key-value database, originally created to complement TiDB

结尾

结论已经在文章开头给出了，希望大家看了本文都能对TiDB集群的各种空间计算有了清晰的认识。

本文只讨论的 TiKV 的容量计算细节，TiFlash 的计算方式也类似，我对比了 TFlash 的数据目录大小和监控显示已用大小10多G的差距，应该也是只计算了部分目录，但是总容量还是算的整块盘。不太熟悉 c++，留给其他大佬去探索吧🤣。

文章转载自：balahoho

原文链接：https://www.cnblogs.com/hohoa/p/17959525

体验地址：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1376847.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

【JaveWeb教程】（21） MySQL数据库开发之多表设计：一对多、一对一、多对多的表关系 详细代码示例讲解

【JaveWeb教程】（21） MySQL数据库开发之多表设计：一对多、一对一、多对多的表关系 详细代码示例讲解

目录 2. 多表设计2.1 一对多2.1.1 表设计2.1.2 外键约束 2.2 一对一2.3 多对多2.4 案例 2. 多表设计 关于单表的操作(单表的设计、单表的增删改查)我们就已经学习完了。接下来我们就要来学习多表的操作&#xff0c;首先来学习多表的设计。 项目开发中&#xff0c;在进行数据库…
阅读更多...
OCR字符识别：开始批量识别身份证信息

OCR字符识别：开始批量识别身份证信息

身份证信息批量识别OCR是一项解决方案&#xff0c;它能够将身份证照片打包成zip格式或通过URL地址进行提交&#xff0c;并能够识别照片中的文本信息。最终&#xff0c;用户可以将识别结果生成为excel文件进行下载。 API接口功能&#xff1a; 1. 批量识别&#xff1a;支持将多…
阅读更多...
SPDK中常用的性能测试工具

SPDK中常用的性能测试工具

本文主要介绍磁盘性能评估的方法&#xff0c;针对用户态驱动Kernel与SPDK中各种IO测试工具的使用方法做出总结。其中fio是一个常用的IO测试工具&#xff0c;可以运行在Linux、Windows等多种系统之上&#xff0c;可以用来测试本地磁盘、网络存储等的性能。为了和SPDK的fio工具相…
阅读更多...
大模型学习与实践笔记（四）

大模型学习与实践笔记（四）

一、大模型开发范式 RAG&#xff08;Retrieval Augmented Generation&#xff09;检索增强生成&#xff0c;即大模型LLM在回答问题或生成文本时&#xff0c;会先从大量的文档中检索出相关信息&#xff0c;然后基于这些检索出的信息进行回答或生成文本&#xff0c;从而可以提高回…
阅读更多...
Prepar3D设置全屏显示设置方法

Prepar3D设置全屏显示设置方法

一、 基础设置 当视景软件显示的屏幕超过一个的时候&#xff0c;需要将多个显示屏幕在设置->屏幕设置->多显示器这里设置为扩展这些显示器。 二、全屏方法说明 一般情况只需要设置了多屏显示扩展并设置了P3D软件全屏设置&#xff08;即下面的步骤一&#xff09;保存后…
阅读更多...
D2576 DC-DC降压芯片用于直流充电桩，具备3A的输出电流能力，输入电压6~40VDC

D2576 DC-DC降压芯片用于直流充电桩，具备3A的输出电流能力，输入电压6~40VDC

随着新能源汽车的不断普及&#xff0c;如何解决新能源车充电的问题也成为大热话题&#xff0c;充电桩的数量与质量也是目前急需提升的热门方面&#xff0c;现阶段人们需要的充电桩主要有交流充电桩和直流充电桩&#xff0c;直流充电桩因其节能效率高、功率因数高、充电快、逐渐…
阅读更多...
【OJ比赛日历】快周末了，不来一场比赛吗？ #01.13-01.19 #11场

【OJ比赛日历】快周末了，不来一场比赛吗？ #01.13-01.19 #11场

CompHub[1] 实时聚合多平台的数据类(Kaggle、天池…)和OJ类(Leetcode、牛客…&#xff09;比赛。本账号会推送最新的比赛消息&#xff0c;欢迎关注&#xff01; 以下信息仅供参考&#xff0c;以比赛官网为准 目录 2024-01-13&#xff08;周六&#xff09; #4场比赛2024-01-14…
阅读更多...
【一、测试基础】Java基础语法

【一、测试基础】Java基础语法

Java 的用法及注意事项有很多&#xff0c;今天的目标是了解Java基础语法&#xff0c;且能够输出"hello world" 几个基础的概念 对象&#xff1a;对象是类的一个实例&#xff0c;有状态和行为。一只猫是一个对象&#xff0c;猫的状态有&#xff1a;颜色、名字、品种&…
阅读更多...
通信原理 | 累积谱的概念 | Python案例代码介讲解

通信原理 | 累积谱的概念 | Python案例代码介讲解

文章目录 累积谱的概念Python案例代码讲解结果展示拓展累积幅值什么意思累积谱的概念 累积谱（Cumulative Spectrum）是信号处理领域的一个概念，它用于描述信号的频谱分布。具体来说，累积谱是一个函数或者图表，用来表示信号频谱中的能量分布，通常是从最低频率开始累积到某…
阅读更多...
AI智能分析网关V4：太阳能+4G智慧水库远程可视化智能监管方案

AI智能分析网关V4：太阳能+4G智慧水库远程可视化智能监管方案

一、背景需求分析 由于水库位置分散的原因&#xff0c;水库视频监控建设在立杆、布线等方面都存在一定的难度&#xff0c;且需要人力、物力的前期投入和后期维护。目前水库的监管存在一定的问题&#xff0c;管理人员工作强度大但管理质量并不高&#xff0c;人为巡检无法实时发…
阅读更多...
C# OpenCvSharp DNN 部署yoloX

C# OpenCvSharp DNN 部署yoloX

目录 效果 模型信息 项目 代码 下载 C# OpenCvSharp DNN 部署yoloX 效果 模型信息 Inputs ------------------------- name&#xff1a;images tensor&#xff1a;Float[1, 3, 640, 640] --------------------------------------------------------------- Outputs ---…
阅读更多...
Java异常处理--异常处理的方式1

Java异常处理--异常处理的方式1

文章目录 一、异常处理概述二、方式1&#xff1a;捕获异常&#xff08;try-catch-finally&#xff09;&#xff08;1&#xff09;抓抛模型&#xff08;2&#xff09;try-catch-finally基本格式1、基本语法2、整体执行过程3、try和catch3.1 try3.2 catch (Exceptiontype e) &…
阅读更多...
系列二、Spring Security中的核心类

系列二、Spring Security中的核心类

一、Spring Security中的核心类 1.1、自动配置类 UserDetailsServiceAutoConfiguration 1.2、密码加密器 1.2.1、概述 Spring Security 提供了多种密码加密方案&#xff0c;官方推荐使用 BCryptPasswordEncoder&#xff0c;BCryptPasswordEncoder 使用 BCrypt 强哈希函数&a…
阅读更多...
element-ui 如何修改el-popconfirm的样式

element-ui 如何修改el-popconfirm的样式

改造之前效果 改造之后效果 代码&#xff1a; <style lang"scss"> .my-popconfirm {width: 92% !important;height: 130px !important;padding: 14px !important;font-size: 28px !important;.el-popper {font-size: 28px !important;}.el-popconfirm__main {…
阅读更多...
ChatGPT：人工智能与人类交流的桥梁

ChatGPT：人工智能与人类交流的桥梁

在人工智能的浪潮中&#xff0c;ChatGPT以其独特的交流能力成为了一个亮点。作为一个基于强大的GPT-4模型的聊天机器人&#xff0c;ChatGPT不仅仅是技术的展示&#xff0c;它更是人工智能与人类交流的桥梁。 人工智能的语言理解革命 ChatGPT的出现标志着人工智能在语言理解和…
阅读更多...
怎么挑选一体化污水处理设备

怎么挑选一体化污水处理设备

选择一体化污水处理设备是一个关键决策&#xff0c;它直接影响到污水处理系统的效能和运行成本。随着环保意识的日益提高&#xff0c;各种污水处理设备也不断地涌现出来。那么&#xff0c;在众多选项中&#xff0c;如何挑选一体化污水处理设备&#xff1f;本文将为您提供一些建…
阅读更多...
了解PyTorch中的缩放点积注意力及演示

了解PyTorch中的缩放点积注意力及演示

torch.nn.functional.scaled_dot_product_attention 函数在 PyTorch 框架中用于实现缩放点积注意力&#xff08;Scaled Dot-Product Attention&#xff09;。这是一种在自然语言处理和计算机视觉等领域常用的注意力机制。它的主要目的是通过计算查询&#xff08;query&#xff…
阅读更多...
详解动态网页数据获取以及浏览器数据和网络数据交互流程-Python

详解动态网页数据获取以及浏览器数据和网络数据交互流程-Python

前言 动态网页是一种在用户浏览时实时生成或变化的网页。与静态网页不同&#xff0c;后者通常是预先编写好的HTML文件&#xff0c;直接由服务器传送给浏览器&#xff0c;内容在服务端生成且固定不变&#xff0c;获取静态数据的文章课查阅博主上一篇文章&#xff1a;详解静态网…
阅读更多...
小区楼盘3D场景可视化：重塑您对家的想象

小区楼盘3D场景可视化：重塑您对家的想象

随着科技的飞速发展&#xff0c;我们的生活正经历着前所未有的变革。曾经&#xff0c;我们只能通过文字和二维图片来了解楼盘的布局和设计&#xff1b;而今&#xff0c;3D技术的引入&#xff0c;让这一切变得栩栩如生。今天&#xff0c;就让我们一起走进小区楼盘3D场景可视化&a…
阅读更多...
虹科新闻丨LIBERO医药冷链PDF温度计完成2024年航空安全鉴定，可安全空运！

虹科新闻丨LIBERO医药冷链PDF温度计完成2024年航空安全鉴定，可安全空运！

来源&#xff1a;虹科环境监测技术 虹科新闻丨LIBERO医药冷链PDF温度计完成2024年航空安全鉴定&#xff0c;可安全空运&#xff01; 原文链接&#xff1a;https://mp.weixin.qq.com/s/XHT4kU27opeKJneYO0WqrA 欢迎关注虹科&#xff0c;为您提供最新资讯&#xff01; 虹科LIBE…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023