第5章 · 播客 第6集
系统性能评价 · 服务器负载均衡与系统监视
🎙️ 本集播客:第6集:本章收官——服务器负载均衡的目的与本地、全域之分,系统监视要收集的三种性能数据逐一辨析(识别内存泄漏这种短期趋势的是哪一种,这是必考点)、三种监视方式与 Tivoli、Sitescope 两个工具,末尾附全章必背清单:性能指标公式、基准程序对应关系、负载均衡与监视全部串一遍,并引出第 6 章开发方法。 语音由微软 Edge 神经网络语音预生成(女声·晓伊,男声·云希)。点击下方任意对话可直接从该句开始播,当前句朗读时下一句已预先加载,无缝衔接。
明
阿明
上集五种负载均衡讲完了。原文后面还讲了「服务器负载均衡」,跟这五种是什么关系?
雅
小雅
那是换一个维度看同一件事:前五种是按实现技术分类,服务器负载均衡讲的是目的和结构。目的原文写得很清楚:服务器负载均衡一般用于提高服务器的整体处理能力,并提高可靠性、可用性和可维护性,最终目的是加快服务器的响应速度,从而提高用户的体验度。结构上分两种——本地负载均衡 Local Server Load Balance,是指对本地的服务器群做负载均衡;全域负载均衡 Global Server Load Balance,是指对分别放置在不同的地理位置、有不同的网络及服务器群之间做负载均衡。
明
阿明
全域的特点是不是要背?
雅
小雅
五条,考过。一,解决网络拥塞问题,服务就近提供,实现地理位置无关性;二,对用户提供更好的访问质量;三,提高服务器响应速度;四,提高服务器及其他资源的利用效率;五,避免了数据中心单点失效。抓两个只属于全域的关键词——「服务就近提供、地理位置无关性」和「避免数据中心单点失效」,本地负载均衡给不了这两条,因为它只管一个机房。
明
阿明
本地和全域怎么区分最快?
雅
小雅
看服务器群在不在一个地方:本地负载均衡是对本地的服务器群做负载均衡;全域负载均衡是对分别放置在不同的地理位置、有不同的网络及服务器群之间做负载均衡。多机房、跨地域部署才谈得上全域。
明
阿明
最后一块系统监视。目标是什么?
雅
小雅
原文第一句就是答案:系统监视的目标是为了评估系统性能。然后是本章的另一个必考点——要监视系统性能,需要收集某个时间段内的 3 种不同类型的性能数据。三种,我逐个念定义,你听的时候盯住每一种「能帮你发现什么」,题目就考这个。
明
阿明
来吧。
雅
小雅
第一种,常规性能数据。该信息可帮助识别短期趋势,如内存泄漏。后半段是:经过一两个月的数据收集后,可以求出结果的平均值并用更紧凑的格式保存这些结果;这种存档数据可帮助人们在业务增长时作出容量规划,并有助于在日后评估上述规划的效果。第二种,比较基准的性能数据。该信息可帮助人们发现缓慢、历经长时间才发生的变化——通过将系统的当前状态与历史记录数据相比较,可以排除系统问题并调整系统;由于该信息只是定期收集的,所以不必对其进行压缩存储。
明
阿明
等一下,识别内存泄漏这种短期趋势的是「常规性能数据」,可我总想选「比较基准的性能数据」——听起来那个才像在做趋势分析。
雅
小雅
这就是这道题唯一的坑,两个「趋势」的时间尺度完全相反。常规性能数据对应的是短期趋势,原文举的例子就是内存泄漏——内存泄漏几小时几天就能看出曲线一路往上爬,所以要靠高频采集的常规数据。比较基准的性能数据对应的是缓慢、历经长时间才发生的变化,靠的是拿当前状态跟历史记录比。一句话卡死:短期趋势、内存泄漏,选常规;长期缓慢变化,选比较基准。
明
阿明
那为什么常规的要压缩、比较基准的反而不用?
雅
小雅
因为常规性能数据是持续收集、数据量大,经过一两个月的数据收集后就求出结果的平均值,并用更紧凑的格式保存;比较基准的性能数据只是定期收集,量小,所以不必对其进行压缩存储。
明
阿明
那第三种服务水平报告数据呢?会不会也来抢?
雅
小雅
它抢不着,因为它压根不是拿来找趋势的。原文:服务水平报告数据可帮助人们确保系统能满足一定的服务或性能水平,也可能会将该信息提供给并不是性能分析人员的决策者;收集和维护该数据的频率取决于特定的业务需要。看出区别了吗——常规是自己找短期毛病、比较基准是跟历史比找慢变化、服务水平是拿去向决策者证明达标。还有一个干扰项要小心:选项里常放「系统日志数据」,这四个字不在原文这三类里,是彻头彻尾的编造项,见到直接划掉。
明
阿明
「提供给决策者」这个特征我记下了——这是服务水平报告数据独有的。那具体怎么监视?
雅
小雅
进行系统监视通常有 3 种方式,按抽象层次从低到高。一是通过系统本身提供的命令,如 UNIX 和 Linux 中的 w、ps、last,Windows 中的 netstat 等。二是通过系统记录文件查阅系统在特定时间内的运行状态。三是集成命令、文件记录和可视化技术,提供直观的界面,操作人员只需要进行一些可视化的设置,而不需要记忆繁杂的命令行参数,即可完成监视操作,如 Windows 的 Perfmon 应用程序。
明
阿明
那 Perfmon 就是第三种的代表。厂商的商业工具算第四种吗?
雅
小雅
不算第四种,原文的说法是把前三种集成起来:目前已经有些厂商提供专业化的监视平台,将上面 3 种方式集成到一个统一的监控平台,进行统一监控,并提供各类分析数据和分析报表,帮助用户进行性能的评估和诊断,如 IBM 公司提供的 Tivoli、HP 公司提供的 Sitescope 等。两个名字和两家公司别配错——Tivoli 是 IBM,Sitescope 是 HP。
明
阿明
三种监视方式的命令名也容易混:w、ps、last 是哪一家的?
雅
小雅
那是 UNIX 和 Linux 的命令,跟第一种「系统本身提供的命令」绑定;Windows 里给的是 netstat。第三种的可视化代表是 Windows 的 Perfmon 应用程序;第二种不靠命令靠翻记录——通过系统记录文件查阅系统在特定时间内的运行状态。
明
阿明
全章讲完了。师姐给个必背清单,我这两天照着默。
雅
小雅
第一组,性能指标与计算。MIPS 是百万条指令每秒、描述定点运算能力,MFLOPS 是百万次浮点运算每秒、表示浮点运算能力,这俩别对调;MIPS 等于 IPC 乘 Fz,IPC 是每个时钟周期平均执行的指令条数、CPI 是每条指令所需的平均时钟周期数,例题 IPC 等于 2、Fz 等于 2400MHz,得 4800MIPS。
雅
小雅
理论浮点峰值等于 CPU 主频,乘 CPU 每个时钟周期执行浮点运算的次数,再乘系统中 CPU 数。PDR 等于 L 除以 R。吉普森法的比例:加减法 50%、乘法 15%、除法 5%、程序控制 15%、其他 15%。米勒三个数:0.1 秒感觉不到延迟、1 秒是愿意接受的立即响应极限、10 秒是保持注意力的极限。RASIS 五个词,S 是可维护性 Serviceability。
明
阿明
第二组基准程序我上集刚默过,正好当场验一遍。
雅
小雅
第二组,基准程序对应关系。Dhrystone 测整数、C 语言 100 条语句、1VAXMIPS 等于 1757 Dhrystones 每秒;Linpack 测浮点、FORTRAN;Whetstone 是综合性测试、结果用 Kwips 表示;SPEC 能全面反映机器性能;TPC-C 是衡量 OLTP 系统的工业标准;HPL 是 TOP500 排名的重要依据、浮点运算次数为三分之二乘 N 的三次方减二乘 N 的平方。
雅
小雅
第三组就是今天的:阿姆达尔的加速比取决于增强比例和改进程度;负载均衡五种,随机名字解析是 DNS、Location 重定向是特定服务器软件、代理转发给内部是反向代理、地址转换和第四层交换是 NAT、半中心是扩展的;监视三类数据,短期趋势和内存泄漏选常规性能数据、长期缓慢变化选比较基准、给决策者看的是服务水平报告;监视三方式加 Tivoli 和 Sitescope。
明
阿明
这一整章我最容易栽的就是「阿姆达尔取决于什么」和「内存泄漏归哪类数据」,现在都有抓手了。
雅
小雅
那就趁热去把这章 12 道题刷一遍,错的对回原文再听一遍对应段落。下一章我们讲软件开发方法——瀑布、原型、螺旋、敏捷这一堆模型的适用场景和优缺点,那章不考公式,考的全是「这个场景该用哪种」的判断题,套路和这章完全不同,准备好换脑子。