平常的工作中，在衡量服务器的性能时，经常会涉及到几个指标，load、cpu、mem、qps、rt，其中load、cpu、mem来衡量机器性能，qps、rt来衡量应用性能。
CPU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading很高。
线程的使用目的是提高运行速度，提高运行的速度是要充分提用CPU和I/O 的利用率。
本文总结接口性能测试中,常见的性能指标概念,查看及通用通过标准 注: 本文只考虑B/S架构
在当今的高科技环境下，生产环境服务器的性能问题可能是一个复杂且棘手的问题。当服务器变慢时，可能会对企业的运营产生重大影响，包括客户满意度下降，工作效率降低，甚至可能导致整个系统崩溃。为了解决这些问题，我们需要深入了解生产环境服务器变慢的原因，并掌握有效的诊断和处理方法。
从网上去搜数据库优化基本都是从SQL层次进行优化的，很少有提及到数据库本身的实例优化。就算有也都是基于某个特定数据库的实例优化，本文涵盖目前市面上所有主流数据库的实例优化（Oralce、MySQL、POSTGRES、达梦）,按照文章的配置能够将你数据库性能用到80%或以上。
首先需要尽可能的了解优化问题，收集问题期间系统信息并做好存档。根据当前系统问题表现制定优化目标并与客户沟通目标达成一致；通过一系列工具分析系统问题，制定优化方案，方案评审完成后由各负责人员进行实施。若达到优化目标则编写优化报告，否则需要重新制定优化方案。
我们开发的软件服务需要在服务器上运行，所以服务器性能代表了软件的性能上限，因此服务器性能调优是个十分重要的环节，然而大部分同学对服务器性能调优关注的较少，今天从3个部分对服务器性能调优进行介绍，分别是：服务器配置选择，服务器负载分析，服务器内核参数调优。
伴随着突发流量、系统变更或代码腐化等因素，性能退化随时会发生。如在周年庆大促期间由于访问量暴涨导致请求超时无法下单；应用发布变更后，页面频繁卡顿导致客诉上升；线上系统运行一段时间后，突然发生OOM或连接打满拒绝访问。
为什么你的 ERP/MES/CRM/HR/OA 系统访问首页都很慢，明明你确定打开页面时没有大量的写入操作！
文章旨在通过对 MongoDB 监控指标的梳理和架构的分解，帮助广大的腾讯云 MongoDB 用户更好的通过监控告警及时发现业务异常，实时监控数据趋势。内容将会包括三个部分：
在我们项目部署上线的时候，我们是不是会经常去Linux服务器上查查服务器的CPU使用率，或者是运维经常会盯Linux的CPU使用率，发现监控报了60%的一般就会报警了，到了100%那就惨啦，做我开发的我们如果自己程序运行时CPU使用率一直是100%的话，那么，我们加班肯定逃不掉了，更打击我们自己的强大的自尊心。今天我就将我们线上之前有个100%的CPU给大家讲解下，然后教大家怎么去定位然后发现到具体的函数，然后去修改它就行了
通过逐步加压的方法，达到既定的性能阈值的目标。阈值的设定应该是小于等于某个值，比如CPU使用率小于等于80%。
HPA似乎很简单。我通过遵循所有的文档来启用它。但它对我不起作用! 这是真的，HPA(水平Pod自动定标器)不工作的某些应用或者是应用程序所有者做了什么错误的事情，破坏了HPA?继续往下读吧。 在继续
当我们使用top命令查看系统的资源使用情况时会看到load average，如下图所示，它表示系统在1,5,15分钟的平均工作负载。 那么什么是负载(load)呢？它和CPU的利用率又有什么关系呢
一台运行了好久的服务器CPU使用率达到100%，脑海中第一个想法就是中病毒了，于是开始了我的杀毒之旅。
笔者几天前重启了轻量服务器，在查看服务器CPU使用率时发现一点异常：0点使用率会突然增加并持续。因为仅安装了宝塔面板，猜测是宝塔导致的，为了排除其它软件的影响，就拿出闲置的轻量服务器（1核2G）做了本实验。
CPU性能指标可以从两方面来看：静态、动态 静态指标主要包括： CPU的型号、主频、核数、cache等 动态指标主要包括： CPU的平均负载状况、CPU的使用率、最耗CPU的进程有哪些 查
原文来自互联网，由长沙DotNET技术社区编译。如译文侵犯您的署名权或版权，请联系小编，小编将在24小时内删除。限于译者的能力有限，个别语句翻译略显生硬，还请见谅。
画架构图是为了知道请求是从哪里到哪里，做性能分析一定先画个图，脑子里就会有路径的概念了。
在企业业务信息化之后，企业业务依赖于各种应用系统，应用系统又依赖于各种IT资源。当IT资源出现故障或性能下降时，会导致应用宕机或性能下降，进而影响企业业务产出。资源监控就是对那些可能影响IT资源服务能力的各种技术性能参数进行全面监控，以便提前发现问题隐患并预警，帮助企业将故障消灭于萌芽状态之中。
在linux的系统维护中，可能需要经常查看cpu使用率，分析系统整体的运行情况,以便性能分析优化。而监控CPU的性能一般包括以下3点：运行队列、CPU使用率和上下文切换。
从技术上讲，容器化应用能该帮助组织更具有成本的优势，但Kubernetes到处布满了成本陷阱，可能会使你超出预算。幸运的是，有一些策略可以控制云成本，自动伸缩就是其中之一。Kubernetes带有三个内置的自动伸缩机制来帮助你做到这一点。它们配合得越好，运行应用程序的成本就越低。
登录告警的服务器，这是一台openshift容器平台的计算机节点； top查看到 load average 达到了100左右； 最高的进程占用400%
上节我们讲了如何安装paramiko，这节我们讲如何使用paramiko连接服务器
由于项目的需要，需要做一个简单监控服务器的CPU利用率、CPU负载、硬盘使用率、内存利用率和服务器的各个端口的开启情况的程序，并把结果通知到监控平台，如果出现异常，监控平台打电话或者发短信通知给具体的运维人员
服务器性能监控是监控系统资源的过程，例如 CPU 使用率、内存消耗、存储容量、I/O 性能、网络正常运行时间等。
某公司新开发了一款大IP手游。上线之后不久，发现几十个人上线之后服务器就崩溃了。一开始还能用大量预算来购买服务器用以支撑，但几天之后由于宣传火爆，随着用户的增多，这才发现单纯增加服务器的成本实在太高了。玩家开始逐渐骂服务器垃圾，各种掉线、卡顿、crash。本想领先竞品抢先进入市场，结果收获的却是满怀期待玩家们的流失。为什么！因为没有做压力测试！
Kubernetes 凭借其强大的功能，已成为部署和管理容器化工作负载的“容器编排平台”。然而，其架构的复杂性和动态特性给监控已部署工作负载和平台本身带来了重大挑战。
在本系列的第 1 部分中，我们讨论了如何使用专用游戏服务器，将其与 Docker 打包，然后在Kubernetes 上托管和管理它，这是一个很好的开始。然而，由于我们的 Kubernetes 集群通常是固定大小的，我们可能会耗尽所有可用容量来运行我们需要的所有游戏服务器容器，以匹配所有想玩我们的游戏的玩家——这将是一件非常糟糕的事情。
前面介绍了如何运用Python获取Oracle数据库的信息以及将数据存入MySQL数据库中
sysfs把连接在系统上的设备和总线组织成为一个分级的文件，它们可以由用户空间存取，向用户空间导出内核的数据结构Q以及它们的属性。sysfs的一个目的就是展示设备驱动模型中各组件的层次关系。
OpenTSDB 是一种基于 HBase 编写的分布式、可扩展的时间序列数据库。官方文档这样描述：OpenTSDB is a distributed, scalable Time Series Database (TSDB) written on top of HBase； 翻译过来就是，基于Hbase的分布式的，可伸缩的时间序列数据库，和上面的意思基本相同。 主要用途，就是做监控系统；譬如收集大规模集群（包括网络设备、操作系统、应用程序）的监控数据并进行存储，查询。 存储到OpenTSDB的数据，是以me
监测内存回收情况；同时监控各涉及系统的处理能力, 判断tomcat8的性能是否优于tomcat7，是否满足现网实际业务需求.
前不久，看到了明哥写的如何用Python发送警告通知到企业微信，想起来之前写过用Pytho发送指定格式数据到钉钉的服务，本文将之前的代码重构下，变成一个：利用Python监控服务器数据，然后有异常就通过钉钉发送给用户。
glances是一个基于python语言开发，可以为linux或者UNIX性能提供监视和分析性能数据的功能。glances在用户的终端上显示重要的系统信息，并动态的进行更新，让管理员实时掌握系统资源的使用情况，而动态监控并不会消耗大量的系统资源，比如CPU资源，通常消耗小于2%，glances默认每两秒更新一次数据。同时glances还可以将相同的数据捕获到一个文件，便于以后对报告进行分析和图形绘制，支持的文件格式有.csv电子表格格式和和html格式。
并发 100 个请求测试 VM1 的 Nginx 性能，总共测试 1000 个请求
vmstat命令是最常见的Linux/Unix监控工具，可以展现给定时间间隔的服务器的状态值,包括服务器的CPU使用率，内存使用，虚拟内存交换情况,IO读写情况。这个命令是我查看Linux/Unix最喜爱的命令，一个是Linux/Unix都支持，二是相比top，我可以看到整个机器的CPU,内存,IO的使用情况，而不是单单看到各个进程的CPU使用率和内存使用率(使用场景不一样)。 选项 -a：显示活动内页； -f：显示启动后创建的进程总数； -m：显示slab信息； -n：头信息仅显示一次； -s：以表格方式显示事件计数器和内存状态； -d：报告磁盘状态； -p：显示指定的硬盘分区状态； -S：输出信息的单位。 vmstat 3 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 320 42188 167332 1534368 0 0 4 7 1 0 0 0 99 0 0 0 0 320 42188 167332 1534392 0 0 0 0 1002 39 0 0 100 0 0 0 0 320 42188 167336 1534392 0 0 0 19 1002 44 0 0 100 0 0 0 0 320 42188 167336 1534392 0 0 0 0 1002 41 0 0 100 0 0 0 0 320 42188 167336 1534392 0 0 0 0 1002 41 0 0 100 0 0 一般vmstat工具的使用是通过两个数字参数来完成的，第一个参数是采样的时间间隔数，单位是秒，第二个参数是采样的次数 r 表示运行队列(就是说多少个进程真的分配到CPU)，我测试的服务器目前CPU比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。 b 表示阻塞的进程,这个不多说，进程阻塞，大家懂的。 swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。 free 空闲的物理内存的大小，我的机器内存总共8G，剩余3415M。 buff Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存，我本机大概占用300多M cache cache直接用来记忆我们打开的文件,给文件做缓冲，我本机大概占用300多M(这里是Linux/Unix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高 程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。) si 每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。我的机器内存充裕，一切正常。 so 每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。 bi 块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒 bo 块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。 in 每秒CPU的中断次数，包括时间中断 cs 每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源
性能测试为保证软件质量起到重要作用，对于交易量较大的应用系统，性能测试更是一个必不可少的环节。
没有多少系统的告警是设计得当的。良好的告警设计是一项非常困难的工作。如何知道你收到的告警是糟糕的？多少次你收到了告警之后，立即就关掉了的？是不是成天被这些然而并没有什么卵用的东西给淹没？最常见的告警设置：cpu使用率超过90%，然后告警。这种设置在大部分场合下是没有办法提供高质量的告警的。
对服务器来说主要的角色就是应用服务器或数据库服务器，CPU作为关键资源经常成为性能瓶颈的根源。CPU使用率高并不总是意味着CPU工作繁忙，它有可能是正在等待其他子系统。在进行性能分析时，将所有子系统当做一个整体来看是非常重要的，因为在子系统中可能会出现瀑布效应。 注释：有种常见的错误观念认为CPU是服务器中最重要的。情况不总是这样，服务器经常是CPU的配置高，硬盘、内存和网络子系统是低配置。只有一些特定对CPU要求高的应用程序才能真正充分利用当今的高端处理器。 3.2.1 发现CPU瓶颈 有多种方法可以来确
当你登陆到一台可能有性能问题的服务器上，你会/应该做什么？又该如何去进行初步的性能分析？
本文档是完成***压力测试的指导性文件。本文档给出了对测试需求、测试环境、测试过程及测试结果的总体要求, 这也是本测试项目中其他文档编写及结果评价的基础。
CPU密集型，也叫计算密集型，一般是指服务器的硬盘、内存硬件性能相对CPU好很多，或者使用率低很多。系统运行CPU读写I/O(硬盘/内存)时可以在很短的时间内完成，几乎没有阻塞（等待I/O的实时间）时间，而CPU一直有大量运算要处理，因此CPU负载长期过高。
市面上有很多开源的监控告警工具,提供了丰富的、可视化的监控指标,以及告警能力,而对于服务器维度,抛开业务指标外,我们关注的无外乎cpu使用率、内存使用率和磁盘使用率等是否超过了我们既定的安全阈值,如果超过了则推送告警通知,来引起研发人员的关注,从而采取相应的应对措施。
到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。
今天是星期一，也是双十一，问了一圈周边的人，好像没有买东西的居多，大家都是不知道该买啥好，看来像我一样的老年人变多了，工作了一天，累了，写完早点休息了。。。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
