Posts

前言 最近经常看 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....

本文更新于 2022-12-26，Kuberbetes 更新非常快，请注意可能有过时信息 前言 最近公司业务场景要一个高可用的集群节点用于工业环境，而且数据量非常大，刚刚好手上有一台 IDC 淘来的机架服务器，借机复习一下 K8s 的手动部署。 系统资源 虚拟机配置 $ free -h total used free shared buff/cache available Mem: 31Gi 901Mi 25Gi 4.0Mi 5.4Gi 30Gi Swap: 0B 0B 0B $ cat /proc/cpuinfo | grep -c processor 32 集群的安装 由于只安装一个 Control Panel，我们只需要配置好以下几个组件即可 ETCD Kube-ApiServer Kube-Controller-Manager Kube-Scheduler Kube-Proxy Kubelet 基础的配置 安装基础软件 $ apt install bash-completion git net-tools sudo build-essential golang conntrack $ go version # 这里的 Go 版本需要大于 1.12 go version go1....

前言 Pods 是 Kubernetes 集群中的基础单元，它们可以组织和运行多个容器。从用户的角度，Pods 可以很方便地被创建和管理，但是它们的实际工作原理却鲜有人关注或者一知半解。在这篇文章中，我们将从 Kubernetes 源码的角度，详细剖析一个 Pods 建立的背后。同时会分析各个组件的工作流程，以及它们如何协同工作，以实现创建和管理 Pods 的目标。我们还将在代码解读中，讲解每个组件的职责和实现原理，以更好地理解 Pods 工作的核心机制。 Pods基础知识 Pods 由一个或多个 Container 组成，或者可以说是容器的抽象，所有容器共享一个网络命名空间、存储卷等，可以很方便地共享数据和通信。 首先我们需要通过声明式配置文件来创建 Pod，描述容器的配置和所需的资源，并通过 kubectl 命令提交给 Kubernetes 集群中，而后集群的调度器也就是 Scheduler 组件会根据预先配置的亲和性与对硬件资源的考量，将 Container 放到一个合适的节点，一旦调度成功，Kubernetes 会启动其中的容器并为其分配网络命名空间、IP 地址和存储卷。 在 Pod 启动成功后，Kubernetes 会不断监视其状态，并提供了更新、扩展和故障转移等编排功能。 创建Pods的过程 ApiServer的角色 Controller Manager的角色 Scheduler的角色 Kubelet的角色 Pods的运行过程 Kubelet的监视工作 容器的启动与停止 Pods状态的更新与管理 Pods的持久化 Volumes原理

文章施工中 - 2022-03-02

文章施工中 - 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 相比不同的是：它只是发送方的一个内部记数，无需通知给接收方，其初始值往往会比较小，然后随着报文被接收方确认，窗口成倍扩大，有点类似拳击比赛，开始时候不了解对方情况只能先行试探，后来心里有底了逐渐加大进攻力度。...

虽然说 Nginx 的标准模块非常强大，然而如果遇到了一些不能灵活适应系统要求的功能时候，我们往往会考虑使用 Lua 拓展和定制 Nginx 服务，目前对于这种需要拓展性的项目一般采用 OpenResty ，按照官方的介绍，OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web 应用、Web 服务和动态网关 但是，有的时候服务已经部署完成，包括配置都已经写好了，直接对线上的 Nginx 进行替换显然是一种非常冒险与费神的行为，又或者是只需要某一项功能的拓展，并不需要整体做大改动，这个时候用 Lua 模块就是一种很好的选择。 模拟线上环境 这里我启用了虚拟机作为线上的机器，因此需要重新安装 Nginx，Arguments 这边是需要单独记下来的，和后面编译做到尽量一个参数，这样对配置文件不会造成任何影响 $ sudo add-apt-repository ppa:nginx/stable $ sudo apt-get update $ sudo apt install nginx $ nginx -V nginx version: nginx/1.18.0 (Ubuntu) built with OpenSSL 1.1.1f 31 Mar 2020 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-d4S6DH/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx....