CPU密集型，也叫计算密集型，一般是指服务器的硬盘、内存硬件性能相对CPU好很多，或者使用率低很多。系统运行CPU读写I/O(硬盘/内存)时可以在很短的时间内完成，几乎没有阻塞（等待I/O的实时间）时间，而CPU一直有大量运算要处理，因此CPU负载长期过高。
关键业务的考核指标，重点关注业务价值评价的标准指标，电商类的下单量、支付量等，股票交易类关注买入、卖出以及账户中资金和持有股票的资金的关系等指标。这部分最好是和团队内BA一起确定，建立一套基于业务价值的监控指标。
当你登陆到一台可能有性能问题的服务器上，你会/应该做什么？又该如何去进行初步的性能分析？
系统负载：在Linux系统中表示，一段时间内正在执行进程数和CPU运行队列中就绪等待进程数，以及非常重要的休眠但不可中断的进程数的平均值（具体load值的计算方式，有兴趣可以自行深究，这里不深究）。说白了就是，系统负载与R(Linux系统之进程状态)和D(Linux系统之进程状态)状态的进程有关，这两个状态的进程越多，负载越高。
晚上我登陆网站时发现后台输入账号密码后一直现在在登陆中，我以为是账号密码不对，重新输入后还是同样的问题，网站可以正常的浏览，可后台就是无法登陆，一直显示登陆中，我以为是插件问题造成的，登陆服务器进行查看发现网站负载率一直是在80-100%之间，网站卡的很，至此问题找出来了，具体什么是负载率，咱接着往下看。
对服务器来说主要的角色就是应用服务器或数据库服务器，CPU作为关键资源经常成为性能瓶颈的根源。CPU使用率高并不总是意味着CPU工作繁忙，它有可能是正在等待其他子系统。在进行性能分析时，将所有子系统当做一个整体来看是非常重要的，因为在子系统中可能会出现瀑布效应。 注释：有种常见的错误观念认为CPU是服务器中最重要的。情况不总是这样，服务器经常是CPU的配置高，硬盘、内存和网络子系统是低配置。只有一些特定对CPU要求高的应用程序才能真正充分利用当今的高端处理器。 3.2.1 发现CPU瓶颈 有多种方法可以来确
当我们使用top命令查看系统的资源使用情况时会看到load average，如下图所示，它表示系统在1,5,15分钟的平均工作负载。 那么什么是负载(load)呢？它和CPU的利用率又有什么关系呢
平常的工作中，在衡量服务器的性能时，经常会涉及到几个指标，load、cpu、mem、qps、rt，其中load、cpu、mem来衡量机器性能，qps、rt来衡量应用性能。
通过揉和众多设计良好的 Nginx 模块，OpenResty 有效地把 Nginx 服务器转变为一个强大的 Web 应用服务器，基于它开发人员可以使用 Lua 编程语言对 Nginx 核心以及现有的各种 Nginx C 模块进行脚本编程，构建出可以处理一万以上并发请求的极端高性能的 Web 应用。
Linux内核是一个令人难以置信的马戏团的表演者，可以很小心的玩弄许多进程和它们的资源需求，来保证你的服务器一直嗡嗡作响。内核也是关于公平的一切：当有资源竞争时，内核试图公平的分发这些资源。 然而，如果你有一个需要优先级的重要进程怎么办？一个低优先级的进程呢？或者，限制一组进程的资源呢？ 这需要你的帮助，因为没有你的帮助，内核是无法知道哪些是CPU的关键进程。 所有进程最开始都拥有相同的优先级，Linux内核会为每个任务分配均匀的CPU调度时间。总不能让一个CPU密集型的进程只运行在低优先级吧？所以，你需要
什么是CPU时间片？我们现在所使用的Windows、Linux、Mac OS都是“多任务操作系统”，就是说他们可以“同时”运行多个程序，比如一边打开Chrome浏览器浏览网页还能一边听音乐。
在性能测试中最重要有两个指标，一个是资源指标，是指应用服务对服务器系统资源占用，包括服务器资源的cpu、内存、IO、宽带。系统指标是指应用服务或者应用系统具体的表现，如并发用户数、响应时间、事物成功率、超时时间。
画架构图是为了知道请求是从哪里到哪里，做性能分析一定先画个图，脑子里就会有路径的概念了。
简介 云数据库 Redis（TencentDB for Redis）是由腾讯云提供的兼容 Redis 协议的缓存数据库，具备高可用、高可靠、高弹性等特征。云数据库 Redis 服务兼容 Redis 2.8、Redis 4.0、Redis 5.0 版本协议，提供标准和集群两大架构版本。最大支持 4TB 的存储容量，千万级的并发请求，可满足业务在缓存、存储、计算等不同场景中的需求。 云数据库 Redis 的优势： 主从热备：提供主从热备，宕机自动监测，自动容灾。 数据备份：标准和集群架构数据持久化存储，可提供
CPU使用率（%processor time）,在80%±5%范围内波动为宜。过低，则服务器CPU利用率不高；过高，则CPU可能成为系统的处理瓶颈。
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感，但是这些参数对于开发者来说也十分重要，尤其当你的程序非正常工作的时候，这些蛛丝马迹往往会帮助快速定位跟踪问题。
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感，但是这些参数对于开发者来说也十分重要，尤其当程序非正常工作的时候，这些蛛丝马迹往往会帮助快速定位跟踪问题。
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感，但是这些参数对于开发者来说也十分重要，尤其当你的程序非正常工作的时候，这些蛛丝马迹往往会帮助快速定位跟踪问题。 这里只是一些简单的工具查看系统的相关参数，当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的，而那些更加细致、专业的性能监测和调优，可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成哦。毕竟来说，系统性能监控本身就是个大学
这里只是一些简单的工具查看系统的相关参数，当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的，而那些更加细致、专业的性能监测和调优，可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成哦。毕竟来说，系统性能监控本身就是个大学问。
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感，但是这些参数对于开发者来说也十分重要，尤其当你的程序非正常工作的时候，这些蛛丝马迹往往会帮助快速定位跟踪问题。 这里只是一些简单的工具查看系统的相关参数，当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的，而那些更加细致、专业的性能监测和调优，可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成哦。 毕竟来说，系统性能监控本身就是个
性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。 性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。
性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。
Part1Linux性能优化 1性能优化 性能指标 高并发和响应快对应着性能优化的两个核心指标：吞吐和延时
USE方法可以概括为：针对每个资源，检查使用率、饱和度和错误。该方法对于监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的
在平时的运维工作中，当一台服务器的性能出现问题时，通常会去看当前的CPU使用情况，尤其是看下CPU的负载情况(load average)。对一般的系统来说，根据cpu数量去判断。比如有2颗cup的机器。如果平均负载始终在1.2以下，那么基本不会出现cpu不够用的情况。也就是Load平均要小于Cpu的数量。 对于cpu负载的理解，首先需要搞清楚下面几个问题： 1）系统load高不一定是性能有问题。 因为Load高也许是因为在进行cpu密集型的计算 2）系统Load高不一定是CPU能力问题或数量不够。
sysfs把连接在系统上的设备和总线组织成为一个分级的文件，它们可以由用户空间存取，向用户空间导出内核的数据结构Q以及它们的属性。sysfs的一个目的就是展示设备驱动模型中各组件的层次关系。
在linux的系统维护中，可能需要经常查看cpu使用率，分析系统整体的运行情况,以便性能分析优化。而监控CPU的性能一般包括以下3点：运行队列、CPU使用率和上下文切换。
欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos 本篇概览 本文是《prometheus实战》系列的第二篇，在《prometheus实战之一：用ansible部署》一文咱们部署了prometheus服务，并且在应用服务器部署了node_exporter，整体情况如下图 目前，prometheus已经可以通过node_exporter从应用服务器取得监控数据，本篇就来学习如何使用这些监控数据来展现应用
最新将生产环境的服务器版本统一升级了一下，其中有一台（4H/8G）近两天天天CPU使用率报警（阀值>95%，探测周期60s，触发频率6次），而且load acerage也居高不下，检查了各个系统应用软件的资源使用都没有问题，也将一些可能导致CPU使用率高的软件stop掉，报警依旧。
表示在需要处理更多负载时通过提高单个系统处理能力的方法来解决问题。最简单的情况就是为应用系统提供更为强大的硬件。 例如：如果数据库所在的服务器实列只有8G内存、低配cpu、小容量硬盘，进而导致了数据库不能高效地运行，那么就可以通过将该服务器的内存扩展到16G、更换大容量硬盘或者更换高性能服务来解决这个问题。
携程自2013年开始使用Redis，旧时期为Memcached和Redis混用状态。由于Redis在处理性能，可储存key的多样化上有着显著的优势，2017年开始，Memcached全部下线，全公司开始大规模使用Redis。Redis实例数量也由刚开始的几十个增长到几万个，数据量达到百TB规模。作为Redis的运维方，为保证Redis的高可用性，DBA的压力也随Redis使用规模的增大而增大，集群的扩容，上下线，实例扩容都面临着不小的挑战。
平常处理服务器的问题遇到的最多的是负载高了，内存高了，io高了等问题，这里最明显的表现就是相关的监控指标了，对于诊断这种问题起到事半功倍的效果。
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到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源
李盖，容器产品中心后台开发，负责腾讯云 TKE 的对内自研上云业务，主要负责集群调度、资源效率提升、集群稳定性等方向。 引言 在 K8s 集群运营过程中，常常会被节点 CPU 和内存的高使用率所困扰，既影响了节点上 Pod 的稳定运行，也会增加节点故障的几率。为了应对集群节点高负载的问题，平衡各个节点之间的资源使用率，应该基于节点的实际资源利用率监控信息，从以下两个策略入手： 在 Pod 调度阶段，应当优先将 Pod 调度到资源利用率低的节点上运行，不调度到资源利用率已经很高的节点上 在监控到节点资源率较
之前做的压测性能标准、产品说明书的性能需求部分、运营人员提出的性能指标、通过生产环境换算出的性能指标等
最近经常在线上排查一些问题，在大多数情况下，都是代码写的业务逻辑有问题；还有一些情况是内存上导致的问题，如 OOM 或者由于数据量大导致的一些问题；但是很少会关注，但常常又会瞟一眼的，这个关注点就是 CPU。
从CPU发明到现在，有非常多种架构，从我们熟悉的X86，ARM，到不太熟悉的MIPS，IA64等
近年来，公有云、混合云等技术在全球迅速发展，云的普及度越来越高，Docker、Kubernetes、DevOps、Service Mesh 等云原生技术蓬勃发展。但在“上云”之后，企业却往往发现“用云”并没有那么容易。
通过前两节对平均负载和 CPU 上下文切换的学习，我相信你对 CPU 的性能已经有了初步了解。不过我还是想问一下，在学这个专栏前，你最常用什么指标来描述系统的 CPU 性能呢？我想你的答案，可能不是平均负载，也不是 CPU 上下文切换，而是另一个更直观的指标—— CPU 使用率。
提到CPU利用率，就必须理解时间片。什么是CPU时间片？我们现在所使用的Windows、Linux、Mac OS都是“多任务操作系统”，就是说他们可以“同时”运行多个程序，比如一边打开Chrome浏览器浏览网页还能一边听音乐。
4.域名--->CDN--->负载均衡--->云服务器ECS+数据库RDS(主从)+缓存Redis
现代互联网数据中心的规模随着应用服务需求的快速增长而不断扩大，但服务器资源利用率却一直很低，导致企业基础设施成本不断上涨。随着云原生技术的发展，混合部署成为了降低成本的一大手段。本文结合华为云云原生团队在混合部署方面的研究和实战，介绍了混合部署的背景、概念、混部技术的设计方案和实际落地情况，以及对未来的计划和展望。
原文:https://blog.csdn.net/u010521062/article/details/115908166
我们开发的软件服务需要在服务器上运行，所以服务器性能代表了软件的性能上限，因此服务器性能调优是个十分重要的环节，然而大部分同学对服务器性能调优关注的较少，今天从3个部分对服务器性能调优进行介绍，分别是：服务器配置选择，服务器负载分析，服务器内核参数调优。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
