公司的某一台即将交付的生产环境数据库处理异步请求忽然异常缓慢，而且同事反馈说安装软件也有卡顿情况。 问题排查流程 初步尝试 首先我尝试将 PgSQL 服务进行重启，因为服务的异步处理速度延迟达到了1秒之久，况且该服务的依赖性没有那么高 $ kubectl rollout restart -n databases statefulset postgres-postgresql 结果出现了麻烦，整个 Pods 一直处于 Terminating 状态，一开始还以为是 PreStop 任务没有处理结束导致堵塞，后来发现 PgSQL 的日志已经在几分钟之前就不输出了，看起来是集群没有进行处理。 $ kubectl get event -n databases 47m Warning Unhealthy pod/postgres-postgresql-0 Liveness probe errored: rpc error: code = NotFound desc = failed to exec in container: failed to load task: no running task found: task dbd0aae87722bdababfdf720ec389aaeaab040f594b782451ea39edfbc1261bb not found: not found 47m Warning Unhealthy pod/postgres-postgresql-0 Readiness probe errored: rpc error: code = NotFound desc = failed to exec in container: failed to load task: no running task found: task dbd0aae87722bdababfdf720ec389aaeaab040f594b782451ea39edfbc1261bb not found: not found 通过查看错误事件即可发现，是清理 Container 的任务无法被正确处理，让我们手动清理一下 ...

前言 最近有在帮公司制作一个 OpenVpn Snap 安装包，然而频繁遇到了 Apparmor 错误，其实之前安装 Shadowsock 包的时候也见过，但是当时没怎么太认真探究，现在回看起来发现国内这方面的相关资料还是比较少的，本篇博文从介绍到实践由浅到深，帮助自己也帮助读者理解。 错误样例 $ sudo snap install easy-openvpn-server_0.2_amd64.snap --dangerous error: cannot perform the following tasks: - Setup snap "easy-openvpn-server" (unset) security profiles (cannot setup apparmor for snap "easy-openvpn-server": cannot unload apparmor profile: exit status 2 apparmor_parser output: File snap-update-ns.easy-openvpn-server not found, skipping... File snap.easy-openvpn-server.easy-openvpn-server not found, skipping... File snap.easy-openvpn-server.hook.configure not found, skipping... File snap.easy-openvpn-server.hook.connect-plug-firewall-control not found, skipping... File snap.easy-openvpn-server.hook.connect-plug-network-control not found, skipping... File snap.easy-openvpn-server.openvpn not found, skipping... File snap.easy-openvpn-server.status not found, skipping... File snap.easy-openvpn-server.tcp-server not found, skipping... File snap.easy-openvpn-server.udp-server not found, skipping... ) - Setup snap "easy-openvpn-server" (unset) security profiles (cannot unload apparmor profile: exit status 2 apparmor_parser output: File snap-update-ns.easy-openvpn-server not found, skipping... File snap.easy-openvpn-server.easy-openvpn-server not found, skipping... File snap.easy-openvpn-server.hook.configure not found, skipping... File snap.easy-openvpn-server.hook.connect-plug-firewall-control not found, skipping... File snap.easy-openvpn-server.hook.connect-plug-network-control not found, skipping... File snap.easy-openvpn-server.openvpn not found, skipping... File snap.easy-openvpn-server.status not found, skipping... File snap.easy-openvpn-server.tcp-server not found, skipping... File snap.easy-openvpn-server.udp-server not found, skipping... ) - Run configure hook of "easy-openvpn-server" snap if present (run hook "configure": cannot open directory /tmp/snap.0_easy-openvpn-server_XXXXXX: Permission denied) 什么是AppArmor？ 1. 安全模型描述 在谈论一个具体的实现之前，避免不了需要了解一下较为完整的背景，AppArmor 作为 Liunx 安全模型中的点亮的某个技能树叉，从操作系统的权限管理与访问机制来入手是一个比较好的选择。其基础的权限管理与访问控制机制和加强的 ACL 机制、SELinux，都对这些安全模型与安全机制有所实现。 ...

距离考试倒计时只剩下约 3 天，可是几乎没怎么学习，就是把 500 题刷了一遍，视频过了一遍而已，干脆和学计算机一样来个总结 扣分须知 目前国内考试基本用的是四月一日后新出的新规题目，经常会遇到视频和实际考题不一致的情况，这里重新巩固一下对于扣分的理解 扣一分的情况 最轻微或者不会造成事故的扣分，这一档次也是我们生活中时时刻刻会触犯到的 不按规定使用灯光 不系安全带 普通道路不按规定倒车/掉头，或者超速 10%-20% 违反禁令标志禁止标线（例如压线等情况） 普通客车未按规定年检就上路 货车超载不超过 30%，或者擅自改变已登记结构 做题的时候，想一下自己在路上是不是经常触碰到某些行为，或者事件发生在普通道路或者载货汽车危害不严重的时候，基本就是一分没跑了 扣三分的情况 这一类扣分行为是种类最多也是易错点最多的，如果我们想要强行总结，可以概括为 此类行为可能造成危害，且危害后果是可以预见的 开车打电话 不避让校车：小朋友多且出事情后果相当严重，但出事概率不算大 不避让行人 不按规定超车 快速与高速路段不按规定车道行驶 出故障后停车不按规定使用灯光：可能会造成后车误判导致追尾 高速行驶低于最低时速：说的就是你，五菱牌移动路障 货车违反 420 法制（开车大于 4 小时后没有休息 20 分钟）：不过我感觉这个挺难界定的 不按规定安装号牌：咋地，照不到牌就没法扣你分了吗，当然前提是号牌要完好 需要AB照才能开的车没有按规定年检就上路：C照是1分 你看，3分基本都是与别人交互导致的事故，1分多是半惩戒性质，例如不打转向灯这种 同时注意，扣分体系中，高速/快速 和 普通道路 有的时候是两套规则，载客汽车 和 客运车/危险物品运输车 也是两套，涉及客运车这种即使是最轻微的未按规定年检上路，就已经从3分起扣了 3分这个区间还有一个关键区域值 – 20%-50%，将该区域套到普通道路与载客汽车上，即为3分 普通道路逆行 / 超速20%-50% 载客汽车超过核定人数 20%-50% 载货汽车超重 30%-50%: 30% 以下1分 载货汽车用来载客：对，躲货拉拉后备箱要扣三分 校车上路前未做车况检查 / 带隐患上路 扣六分的情况 六分一般会出现在出现在，一旦出事则会导致重大危险，且本身事故概率极大的场景中，亦或者是 AB 照相关车辆违规 不遵守交通信号灯，例如闯红灯 占用应急车道：会导致特种车无法及时作业 驾驶证被暂扣期间驾驶机动车 逃逸致人轻伤 / 财产损失：逃逸最轻的后果 载运危险物品车辆未按照指定的时间、线路、速度行驶或者未挂载警示标志 下面开始涉及到高速或者 50% 以上的区间 ...

前言 熟悉这个博客的朋友都知道，我一般都不会写语言类的说明书，但这次由于网络资料参差不齐，中间走了许多弯路，特此进行一次记录 故事背景 公司的工业机器人需要做车端行为树的汇总，系统组配合那边给出来一个 Grpc 接口（C++写），我们这边调用函数，车端进行充电等行为时候会触发行为树操作，而我们负责监听即可，本来是一个非常简单的需求。 项目准备 在这里推荐写代码还是使用 Linux 或者 Mac 更好，Windows 的配置实在是太折磨人了。 我们先来看看最终的，也就是实际跑起来的项目结构： 含有注释的都是重点文件 ➜ tree . ├── compatibility.go ├── config.go ├── debug │ └── main.go # Server ├── go.mod ├── go.sum ├── grpc.go # 主要的接受监听部分代码，也可以看成 Client ├── grpc_test.go # 测试代码 ├── main.go ├── mongo.go ├── xx.api.rfi # grpc 包名，要和调用方保持一致 │ ├── behavior_tree_engine_grpc.pb.go # 主要实现的方法 │ └── behavior_tree_engine.pb.go ├── mqtt.go ├── proto │ └── behavior_tree_engine.proto # ProtoBuf 定义文件 └── README.md 3 directories, 14 files 在开始编写代码之前，我们先要安装对应的配套工具 ...

前言 最近经常看 Youtube 有很多的钢琴家在分享他们的曲子，有的时候很想将其稍微做一点修改，但是这样的话就要扒谱到 FlStudio 里面，即使有 MIDI 键盘辅助，手工扒谱也是一项非常吃力的活，于是就想着能不能借助 AI，这不，Google MT3 模型就出现在了我的眼前。 需要注意的是，MT3 项目并不是 Google 官方推出的，而是 Google 使用了 T5X 训练框架而已，T5X 框架是一个研究友好的框架，可以用于高性能、可配置、自助式训练、评估和序列模型（从语言开始）的推理，而 MT3 是一个多乐器自动音乐转录模型。 环境 我的配置单 运行环境：WSL2 Ubuntu 22.04（我甚至不愿意用虚拟机） 显卡：NVIDIA RTX 3080 CPU：Intel i9-11900K 内存：64G 安装模型相应的依赖 我们需要安装如 Python、TensorFlow、NumPy、Pandas 等依赖项目 $ sudo apt-get update $ sudo apt install \ python3 python3-pip python3-dev python3-venv \ gcc g++ make build-essential \ libicu-dev libbz2-dev liblzma-dev \ libssl-dev libxml2-dev libxslt-dev ffmpeg libsndfile1-dev $ python3 -m pip install --upgrade pip $ pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple 接下来如果需要使用 GPU 进行加速处理的话，我们需要安装 CUBA 软件包，下面的安装方式只是一个参考，更具体的信息可以查阅 Ubuntu 官方网站 ...

文章施工中 - 2022-03-02

建议就着咖啡观看，避免干着 实验环境 操作系统：Debian 10 Linux Kernel：5.10.x 前言 我在编写之前的文章《服务器性能优化之网络性能优化》中，其实有想把 BBR 作为一种优化手段写进去的，然而受限于篇幅不能过多讲解，因此特地单独细致地研究一遍。 通常我们在研究 BBR 算法的时候，会很难不将其与 Cublic 算法做比较，作为 Linux 内核默认的 TCP 拥塞控制算法，我们在这里也将会一并列入对比和实验中。 基本的概念 盖房先建地基，对应的学习一门知识也要先掌握与巩固前置基础，这里先将几个较为关键和频繁出现的知识要点来回顾一下，但在这里我将默认你已经掌握了基本的网络技术（例如滑动窗口，重传定时器等概念），否则你更需要的可能是一本网络入门书。 拥塞控制四板斧 由于 TCP 协议向应用层提供不定长的字节流发送方法，使得 TCP 协议先天性地有意愿去占满网络中的整个带宽，这时候当网络中许多连接同时试图去占满整个带宽的时候，就有可能发生恶性拥塞事件，因此 TCP 拥塞控制算法的作用，它能有效防止过多的数据注入到网络中，导致出现网络负载过大的情况。当 TCP 拥塞控制算法无法满足当前互联网应用对网络传输高实时性、高带宽利用率、高吞吐量的需求，在这种背景下 BBR 应运而生。 注意它和流量控制的区别，流量控制更多是作用于接收者，它控制发送者的发送速度从而使接收者来得及接收，防止数据分组丢失 在我们逐步分析对应控制手段之前，需要先行假设： 数据是单方向传递，另一个窗口只发送确认 接收方的缓存足够大，因此发送方的窗口大小由网络的拥塞程度来决定 慢启动 概念 我们都有过从互联网下载东西的经历，通常来说，文件的下载速率并不是一开始就达到到你的宽带上限，而是逐步从例如 1MB/s → 4MB/s 递增上去，这其实就是我们能看见的一种很典型的慢启动策略。 在这场下载中，发送方（即内容提供服务器）会维持一个叫做拥塞窗口 cwnd 的状态变量。它用来表示发送方在得到接收方确认前，最大允许传输的未经确认的窗口。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。 这时候我们又要引入两个新的词，即 通告窗口 rwnd 发送窗口 swnd = min(cwnd, rwnd) 虽然是新的词，但概念大体是新瓶装老酒，通告窗口就是我们 TCP 报文头的 Window 字段，也就是对方的接收窗口，例如我这里截了一张随手抓的报文内容，这里的 rwnd 就为 1021 而发送窗口的概念就更简单了，它将 rwnd 与 cwnd 做比较，取两者最小值，如果我们将整条连接堪称一个水桶，那么它代表水桶中最短的那块木板，而 cwnd 与 rwnd 相比不同的是：它只是发送方的一个内部记数，无需通知给接收方，其初始值往往会比较小，然后随着报文被接收方确认，窗口成倍扩大，有点类似拳击比赛，开始时候不了解对方情况只能先行试探，后来心里有底了逐渐加大进攻力度。 ...