关键业务的考核指标，重点关注业务价值评价的标准指标，电商类的下单量、支付量等，股票交易类关注买入、卖出以及账户中资金和持有股票的资金的关系等指标。这部分最好是和团队内BA一起确定，建立一套基于业务价值的监控指标。
半导体技术的出现和普及，让存储介质与存储模式发生了翻天覆地的变化，使用二进制记录和存储数据成为整体存储模式的主流。
CPU使用率：CPU的使用率 平均负载：单位时间内的活跃线程数 用户时间：CPU在用户进程上的实际百分比 系统时间：CPU在内核上花费的实际百分比 空闲时间：系统处于在等待IO操作上的时间总和 等待：CPU花费在等待IO操作上的时间总和 Nice时间：CPU优先执行的时间百分比
http://tapd.oa.com/Greenplum/markdown_wikis/view/#1010134541008425443
登入服务器后，我们的目的是首先要确认当前到底是哪些进程引起的负载高，以及这些进程卡在什么地方，瓶颈是什么。
| 作者 王文安，腾讯CSIG数据库专项的数据库工程师，主要负责腾讯云数据库 MySQL 的相关的工作，热爱技术，欢迎留言进行交流。 ---- 在日常工作中，有时候会发现 MySQL 的状态不太对劲，这时候就会看看监控指标，可能会发现：写入 QPS 开始出现毛刺，或者 IO 的指标很高。这时候该怎么办呢？ 本文会从 Linux 层面入手，根据不同的 IO 特点来分析 MySQL 数据库可能遇到的问题，并给出一些可参考的优化/缓解思路。 一、怎么看懂 IO 指标？ 检查 IO 的问题会使用iostat这
在日常工作中，有时候会发现 MySQL 的状态不太对劲，这时候就会看看监控指标，可能会发现：写入 QPS 开始出现毛刺，或者 IO 的指标很高。本文会从 Linux 层面入手，根据不同的 IO 特点来分析 MySQL 数据库可能遇到的问题，并给出一些可参考的优化/缓解思路。
Raid0 ：最少需要两块盘， 没用冗余数据，不做备份，任何一块磁盘损坏都无法运行。n块磁盘（同类型）的阵列理论上读写速度是单块磁盘的n倍（实际达不到），风险性也是单一n倍（实际更高），是磁盘阵列中存储性能最好的。适用于安全性不高，要求比较高性能的图形工作站或者个人站。
随着业务量越来越大，单台数据库服务器性能已无法满足业务需求，该考虑增加服务器扩展架构了。主要思想是分解单台数据库负载，突破磁盘I/O性能，热数据存放缓存中，降低磁盘I/O访问频率。
线上某集群峰值TPS超过100万/秒左右(主要为写流量，读流量很低)，峰值tps几乎已经到达集群上限，同时平均时延也超过100ms，随着读写流量的进一步增加，时延抖动严重影响业务可用性。该集群采用mongodb天然的分片模式架构，数据均衡的分布于各个分片中，添加片键启用分片功能后实现完美的负载均衡。集群每个节点流量监控如下图所示:
在实际的性能测试中，会遇到各种各样的问题，比如 TPS 压不上去等，导致这种现象的原因有很多，测试人员应配合开发人员进行分析，尽快找出瓶颈所在。
最近在维护公司线上的服务器，排查了一些问题，所以做一个总结。有一段时间，线上环境变得很卡，客户端请求很多都报超时，因为线上没有良好的apm监控，所以只能通过流量高峰期和日志去排查问题。通过排查，发现数据库的慢查询日志在比之间的暴涨了十倍，然后发现，memcache服务器（8核）负载很高，cpu一直在50%的左右，原因就是memcache服务器内存用完，导致内存的淘汰十分频繁，这样就导致很多请求落到数据库。下面说下主要的排查思路和用到的工具
第九章 操作系统和硬件优化 Mysql服务器性能受制于系统最薄弱的环节，磁盘大小，可用内存，cpu资源网络以及连接他们的组件，都会限制住Mysql的性能。 mysql中一方面的缺陷常常会将压力施加在另一个系统之上。例如没有内存的时候，可能会刷出缓存来腾出空间，这时候会导致io过高，所以再发现问题的时候，要尽量注意深沉次的问题。 低延时收益于更快的cpu，高吞吐收益于更多的cpu。 mysql还有很多后台工作，那些工作也能受益于多cpu。 备库更多需要io而不是cpu，因为主库备份到备库会使串行任务。 cpu
当你接手一个老项目，可能发现程序在服务器上运行性能低得可怕，与此同时现网流量还在逐渐增长。也许运用最新框架、微服务容器化、异步协程等方法来次彻底的重构，能够挽狂澜于既倒。可惜时不我待，运维已经在要求加机器了，而坏消息是，原有框架还不支持水平扩展，没法通过堆机器解决。有没有办法在不进行大改的情况下，度过难关呢？
如果Linux服务器突然访问卡顿变慢，负载暴增，如何在最短时间内找出Linux性能问题所在？
什么是CPU时间片？我们现在所使用的Windows、Linux、Mac OS都是“多任务操作系统”，就是说他们可以“同时”运行多个程序，比如一边打开Chrome浏览器浏览网页还能一边听音乐。
Vmstat是一个很全面的性能分析工具，可以观察到系统的进程状态、内存使用、虚拟内存使用、磁盘的IO、中断、上下文切换、CPU使用等。系统性能分析工具中，使用最多的是这个，除了sysstat工具包外，这个工具能查看的系统资源最多。
RAID（Redundant Array of independent Disks，独立磁盘冗余阵列）是将多块硬盘设备组成一个容量更大，更安全的磁盘组，它可以将数据切分为多个片段后，分别存储在各个不同的物理硬盘设备上。然后利用分散读写需求来提升硬盘组整体的性能，同时将重要数据同步保存多份到不同的物理硬盘设备上，可以有非常好的数据备份效果。
导读：作为快手内部数据规模和机器规模最大的分布式文件存储系统，HDFS一直伴随着快手业务的飞速发展而快速成长。
分片分配 (shard allocation)，是指在索引创建、副本增减、节点增减、分片重平衡等过程将索引分片落实到实际的物理节点的操作，包括但不限于：
系统负载：在Linux系统中表示，一段时间内正在执行进程数和CPU运行队列中就绪等待进程数，以及非常重要的休眠但不可中断的进程数的平均值（具体load值的计算方式，有兴趣可以自行深究，这里不深究）。说白了就是，系统负载与R(Linux系统之进程状态)和D(Linux系统之进程状态)状态的进程有关，这两个状态的进程越多，负载越高。
在说这个事前希望大家都能对 CPU 、 内存 、 硬盘的速度都有了解了，这样可能理解得更深刻一点，不了解的朋友点：CPU到底比内存跟硬盘快多少
kafka作为一个老的基础组件，很多读者都已经对其设计和原理十分熟悉，面向Pulsar的冲击下，很多人或许会犹豫究竟要选择哪个技术？
CPU中的控制单元，控制指令执行的顺序，并不是按照先后顺序执行，而是按照优先级顺序
许多互联网公司，每天都会产生大量的日志数据，包括用户行为记录、运营指标、系统运行状况的监控数据等。为了分析用户的行为或者监控系统的状态，需要对这些数据进行周期性的分析和统计。
官方又称其具有高性能、高吞吐、低延时的特点，其吞吐量动辄几十上百万。小伙伴们是不是有点困惑了，一般认为在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间。那
CPU密集型，也叫计算密集型，一般是指服务器的硬盘、内存硬件性能相对CPU好很多，或者使用率低很多。系统运行CPU读写I/O(硬盘/内存)时可以在很短的时间内完成，几乎没有阻塞（等待I/O的实时间）时间，而CPU一直有大量运算要处理，因此CPU负载长期过高。
一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的，它是随着用户量的增加，基础架构才逐渐完善。这篇文章主要谈谈MySQL数据库在发展周期中所面临的问题及优化方案，暂且抛开前端应用不说，大致分为以下五个阶段：
用户反馈insert待入库的队列堆积，当前还有1000W+的insert在消息队列中等待入口，请求堆积严重，怀疑数据库性能有问题
在Linux系统中，这些数据表示等待CPU资源的进程和阻塞在不可中断IO进程（进程状态为D）的数量。
本篇给大家总结了20道Kafka知识点或者说面试题，持续更新中... 1.kafka的3个关键功能？ 发布和订阅记录流，类似于消息队列或企业消息传递系统。 以容错的持久方式存储记录流。 处理记录流。
只要业务逻辑代码写正确，处理好业务状态在多线程的并发问题，很少会有调优方面的需求。最多就是在性能监控平台发现某些接口的调用耗时偏高，然后再发现某一SQL或第三方接口执行超时之类的。如果你是负责中间件或IM通讯相关项目开发，或许就需要偏向CPU、磁盘、网络及内存方面的问题排查及调优技能
TDMQ 是腾讯云基于 Apache Pulsar 开源项目开发的消息队列产品，主打金融等行业应用，适用于对消息通讯要求高可靠、强一致的场景。TDMQ 在保障高可靠性的同时，还能保障消息读写的高吞吐量，而且提供丰富的消息类型，确保不同的业务场景都能有效覆盖。
消息队列(message queue)模型是基于队列提供消息传输服务的，多用于进程间的通信以及线程间的通信。该模式定义了消息队列queue，发送者sender，接收者receiver，提供了一种点对点的消息传递方式，即发送者发送每条消息到队列制定位置，接收者从指定位置获取消息，一旦消息被消费，会从队列移除，发送者和消费者都是点对点一一对应，不会被其他消费者处理。
架构鹅结合TencentOS团队在混部方面的落地实战经验，重点推送了TencentOS Server大规模容器集群混部服务器QoS产品“如意”相关内容。
某月黑风高之夜，某打车平台上线了一大波（G+）优惠活动，众人纷纷下单。于是乎，该打车平台使用的智能提示服务扛不住直接趴窝了（如下图）。事后，负责智能提示服务开发和运维的有关部门开会后决定：必须对智能提示服务进行一次全面深入的性能摸底，立刻！现在！马上！ 那么一大坨问题就迎面而来：对于智能提示这样的后台服务，性能测试过程中应该关心那些指标？这些指标代表什么含义？这些指标的通过标准是什么？下面将为您一一解答。 概述 不同人群关注的性能指标各有侧重。后台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。
响应时间 并发数目 吞吐量。常用的吞吐量指标： ①TPS(每秒事务数)、
负载均衡：在动态负载均衡器上设置动态分发负载的机制后，如果发现某个应用服务器上的硬件资源已经达到极限，动态负载均衡器会将后续请求发送到其他负载较轻的应用服务器上。此时若发现动态负载均衡器没有起到作用，则可以认为是网络瓶颈；
文档中涉及到的所有 DSL 命令，都可以通过 kibana 的 dev tools 执行
问题现象：emr控制台“集群监控”-->“集群事件”里会出现“ 单盘IO设备利用率持续高于阈值”的告警事件
提到CPU利用率，就必须理解时间片。什么是CPU时间片？我们现在所使用的Windows、Linux、Mac OS都是“多任务操作系统”，就是说他们可以“同时”运行多个程序，比如一边打开Chrome浏览器浏览网页还能一边听音乐。
消息代理其实指的就是消息队列，但是我认为作者这里的代理，是给予系统架构位置考量的，因为消息中间件的本质就是作为不同服务之间交流的一种媒介。
Kafka 在大数据领域有极为广泛的运用，配置良好的 Kafka 集群甚至可以做到每秒几十万、上百万的超高并发写入。通常磁盘写入是一种非常缓慢的操作，Kafka 的高并发写入主要是依靠页缓存和零拷贝两种技术实现的。
1）找出系统性能瓶颈（包括硬件瓶颈和软件瓶颈）； 2）提供性能优化的方案（升级硬件？改进系统系统结构？）； 3）达到合理的硬件和软件配置； 4）使系统资源使用达到最大的平衡。（一般情况下系统良好运行的时候恰恰各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加）
每次发现系统变慢时，通常做的第一件事，就是执行 top 或者 uptime 命令，来了解系统的负载情况
从大方面说基本上就是两类，一类是链路出了问题，包括网络抖动，链路环中的某一节点抖动等。另一类是服务本身的问题，包括服务器自身问题如磁盘老化等，还有代码bug造成的服务等待或服务器负载问题。
备份恢复是 DBA 必备的技能，开源数据库 MySQL 在社区中有不少常用的备份恢复方案，xtrabackup，mypump，mydumper，mysqldump，mysql enterprise backup 等等。但是这些方法多数都是从外部利用各类数据库的机制来完成备份与回复，因此多多少少会存在操作步骤多，备份恢复比较慢等问题。于是 Oracle 在 19 年 7 月下旬发布的 MySQL 的 8.0.17 版本中，加入了一个全新的功能性插件：Clone。这个插件只需要几行 client 命令就可以完成数据库的备份恢复，且花费的时间远也低于常规的备份恢复手段。
存储，是我们码农每天都要打交道的事情，而当我们面对RAID，SAN，对象存储，分布式数据库等技术的时候，又往往似是而非，存储成了我们熟悉的陌生人。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
