线上预估服务节前升级到线上,元旦假期出现了P99耗时超过检测阈值。因为正值节假日应用商店流量都有增长,便直观想简单扩容进行解决。但是简单看了下观察了cpu和内存,都是不忙。然后再细看内存里的各种统计指标。有两项指标MEM实际使用率和MEM CACHED这两项几乎涨到了物理内存的上限。实际使用率使用到了90%。观察到上涨的时机正是预估模型每天更新时间点,而且涨了之后并不会跟随pv变化而明显变化。
结合我工作中碰到的运维问题,总结一下linux下server常见的运维问题以及定位方式。这里的server主要指自主开发的逻辑server,web srv因为通常采用通用的架构所以问题比较少。
最新将生产环境的服务器版本统一升级了一下,其中有一台(4H/8G)近两天天天CPU使用率报警(阀值>95%,探测周期60s,触发频率6次),而且load acerage也居高不下,检查了各个系统应用软件的资源使用都没有问题,也将一些可能导致CPU使用率高的软件stop掉,报警依旧。
线上服务的性能分析,一直以来都是比较难的点,主要是难在无法在性能出现异常的当时捕捉到现场信息。有人可能会说,这有什么难的,直接用 Go 工具集里的 pprof 访问一下,进行采样拿下来分析就行了。话虽不假,不过抛开现实场景谈解决方案一般都会非常打脸,真的不行。
zabbix server服务器的agent监控报错:get value from agent faild:bind() faild:[99] cannot assign requested address。数据一直在正常采集,zabbix_get 能获取到数据,页面测试也能获取到数据。
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。
WordPress 的功能不断的增多,WordPress 运行所需的内存也不断增多,如果内存不够,你在 WordPress 操作的时候,就会碰到像这样的问题"Allowed memory size of xxxxxx bytes exhausted"(允许的内存 xxxx 字节已经用光了),这时候你需要给 WordPress 分配更多的内存。
S:进程的状态,S表示休眠,R表示正在运行,Z表示僵死状态,N表示该进程优先值为负
欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos 本篇概览 本文是《prometheus实战》系列的第二篇,在《prometheus实战之一:用ansible部署》一文咱们部署了prometheus服务,并且在应用服务器部署了node_exporter,整体情况如下图 📷 目前,prometheus已经可以通过node_exporter从应用服务器取得监控数据,本篇就来学习如何使用这些监控数据来展现应用
晚上我登陆网站时发现后台输入账号密码后一直现在在登陆中,我以为是账号密码不对,重新输入后还是同样的问题,网站可以正常的浏览,可后台就是无法登陆,一直显示登陆中,我以为是插件问题造成的,登陆服务器进行查看发现网站负载率一直是在80-100%之间,网站卡的很,至此问题找出来了,具体什么是负载率,咱接着往下看。
Server GC / Workstation GC
某公司新开发了一款大IP手游。上线之后不久,发现几十个人上线之后服务器就崩溃了。一开始还能用大量预算来购买服务器用以支撑,但几天之后由于宣传火爆,随着用户的增多,这才发现单纯增加服务器的成本实在太高了。玩家开始逐渐骂服务器垃圾,各种掉线、卡顿、crash。本想领先竞品抢先进入市场,结果收获的却是满怀期待玩家们的流失。为什么!因为没有做压力测试!
1.文档编写目的 首先说明什么场景下适合使用CGroup,为什么会在集群YARN 中对CPU 进行Vcore数超配的情况下同样一个作业,同样的资源参数,有时候处理很快,有时候处理很慢,出现作业的运行效率无法预估情况? 当我们期望通过合理分配CPU的使用率,使应用预期性能的运行,排除其他因素的影响下,如应用中每分配一个Vcore,预估它能处理多少数据,就需要启用CGroup对CPU进行严格的使用率限制来实现。 在混合工作负载的示例是运行 MapReduce 和 Storm-on-YARN 的集群。MapRed
CPU密集型,也叫计算密集型,一般是指服务器的硬盘、内存硬件性能相对CPU好很多,或者使用率低很多。系统运行CPU读写I/O(硬盘/内存)时可以在很短的时间内完成,几乎没有阻塞(等待I/O的实时间)时间,而CPU一直有大量运算要处理,因此CPU负载长期过高。
发现请求验证码的接口状态一直在pending,想到验证码是要往数据库中写入存储,使用navicat连接数据库发现,正常连接,XShell连接服务器,由于数据库使用docker运行 查看在运行容器及大小
最近,烦心事有点多,博客也像是进入了便秘期。虽然还远远不到说放弃的地步,但总有一种挤不出牙膏的郁闷感。很怀念前几个月的冲劲和激情,一天都能存好几篇优质草稿。 看来,张戈博客是首次进入瓶颈阶段了!没办法
OpenTSDB 是一种基于 HBase 编写的分布式、可扩展的时间序列数据库。官方文档这样描述:OpenTSDB is a distributed, scalable Time Series Database (TSDB) written on top of HBase; 翻译过来就是,基于Hbase的分布式的,可伸缩的时间序列数据库,和上面的意思基本相同。 主要用途,就是做监控系统;譬如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储,查询。 存储到OpenTSDB的数据,是以me
今天是星期一,也是双十一,问了一圈周边的人,好像没有买东西的居多,大家都是不知道该买啥好,看来像我一样的老年人变多了,工作了一天,累了,写完早点休息了。。。
vmstat 命令是最常见的Linux/Unix监控工具,可以展现给定时间间隔的服务器的状态值,包括服务器的CPU使用率,MEM内存使用,VMSwap虚拟内存交换情况,IO读写情况。
在 Raygun,追求极致性能已然成为公司文化的一部分。在此前的博客文章中,我们介绍了如何通过将Raygun 的 API 迁移到.NET Core 3.1,性能提高 12%的方法。
在linux的系统维护中,可能需要经常查看cpu使用率,分析系统整体的运行情况,以便性能分析优化。而监控CPU的性能一般包括以下3点:运行队列、CPU使用率和上下文切换。
今天在测试环境有过代码升级。升级后,在群里有人反映系统访问很慢。运维人员反映服务器cpu使用率很高。
在本系列的第 1 部分中,我们讨论了如何使用专用游戏服务器,将其与 Docker 打包,然后在Kubernetes 上托管和管理它,这是一个很好的开始。然而,由于我们的 Kubernetes 集群通常是固定大小的,我们可能会耗尽所有可用容量来运行我们需要的所有游戏服务器容器,以匹配所有想玩我们的游戏的玩家——这将是一件非常糟糕的事情。
CPU使用率(%processor time),在80%±5%范围内波动为宜。过低,则服务器CPU利用率不高;过高,则CPU可能成为系统的处理瓶颈。
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到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源
为什么你的 ERP/MES/CRM/HR/OA 系统访问首页都很慢,明明你确定打开页面时没有大量的写入操作!
任何多线程程序都有死锁的风险,最简单的情形是两个线程AB,A持有锁1,请求锁2,B持有锁2,请求锁1。(这种情况在mysql的排他锁也会出现,不会数据库会直接报错提示)。线程池中还有另一种死锁:假设线程池中的所有工作线程都在执行各自任务时被阻塞,它们在等待某个任务A的执行结果。而任务A却处于队列中,由于没有空闲线程,一直无法得以执行。这样线程池的所有资源将一直阻塞下去,死锁也就产生了。
线上的一个Redis实例频繁进行aof重写,进入redis的数据目录,可以看到下面的场景:
发现46b1对应的线程为Parallel GC Threads,这个就是JVM下的GC线程,它在频繁的进行垃圾回收。
Nuxt.js 是一个基于 Vue.js 的通用应用框架,一个用于Vue.js 开发SSR应用的一站式解决方案。它的优点是将原来几个配置文件要完成的内容,都整合在了一个nuxt.config.js,封装与扩展性完美的契合。
并发 100 个请求测试 VM1 的 Nginx 性能,总共测试 1000 个请求
接着使用 du -h --max-depth=1 命令 查看目录下所有一级子目录文件夹大小
我们开发的软件服务需要在服务器上运行,所以服务器性能代表了软件的性能上限,因此服务器性能调优是个十分重要的环节,然而大部分同学对服务器性能调优关注的较少,今天从3个部分对服务器性能调优进行介绍,分别是:服务器配置选择,服务器负载分析,服务器内核参数调优。
前端时间把公司的一个分布式定时调度的系统弄上了容器云,部署在kubernetes,在容器运行的动不动就出现问题,特别容易jvm溢出,导致程序不可用,终端无法进入,日志一直在刷错误,kubernetes也没有将该容器自动重启。业务方基本每天都在反馈task不稳定,后续就协助接手看了下,先主要讲下该程序的架构吧。
这次分享是腾讯后端面经,面试接近 1 小时,问了非常多的问题,涵盖Linux、数据库、C++、操作系统、计算机网络。
CPU中的控制单元,控制指令执行的顺序,并不是按照先后顺序执行,而是按照优先级顺序
在实际开发过程中,有些 Java 程序在本地或者在服务器上都可以运行的较正常,但是运行较长一段时间后,可能会出现资源占用率较高的情况,例如 CPU 或 内存占用率较高等情况,以至于发生内存溢出,进程假死等的情况。这些问题发生的原因,往往是那些易忽略的编程规范导致的。下面描述一个定位开发环境上资源占用率较高问题的流程。
最近经常在线上排查一些问题,在大多数情况下,都是代码写的业务逻辑有问题;还有一些情况是内存上导致的问题,如 OOM 或者由于数据量大导致的一些问题;但是很少会关注,但常常又会瞟一眼的,这个关注点就是 CPU。
下面是 Linux 下 4 个日常使用率非常高的监控工具,可以帮助我们准确快速的诊断系统问题。
欢迎关注“ 计算机视觉研究院 ” 计算机视觉研究院专栏 作者:Edison_G 扫描二维码 关注我们 微信公众号 : 计算机视觉研究院 机器之心报道 编辑:蛋酱 在2021年的各大顶会中,使用PyTorch的论文数量已经是使用TensorFlow的至少3倍以上,而这一差距还在持续扩大。 从早期的学术框架 Caffe、Theano,到后来的PyTorch、TensorFlow,自 2012 年深度学习再度成为焦点以来,很多机器学习框架成为研究者和业界工作者的新宠。 2018 年底,谷歌推出了全新的J
%us:表示用户空间程序的cpu使用率(没有通过nice调度) %sy:表示系统空间的cpu使用率,主要是内核程序。 %ni:表示用户空间且通过nice调度过的程序的cpu使用率。 %id:空闲cpu %wa:cpu运行时在等待io的时间 %hi:cpu处理硬中断的数量 %si:cpu处理软中断的数量 %st:被虚拟机偷走的cpu 注:99.0 id,表示空闲CPU,即CPU未使用率,100%-99.0%=1%,即系统的cpu使用率为1%。
r 表示运行队列(就是说多少个进程真的分配到CPU),我测试的服务器目前CPU比较空闲,没什么程序在跑,当这个值超过了CPU数目,就会出现CPU瓶颈了。这个也和top的负载有关系,一般负载超过了3就比较高,超过了5就高,超过了10就不正常了,服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大,表示你的CPU很繁忙,一般会造成CPU使用率很高。
问题说明:IDC里的一台服务器的/分区使用率爆满了!已达到100%!经查看发现有个文件过大(80G),于是在跟有关同事确认后rm -f果断删除该文件。但是发现删除该文件后,/分区的磁盘空间压根没有释放出来,使用率还是100%!这是为什么呢?? [root@linux-node1 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00
一台运行了好久的服务器CPU使用率达到100%,脑海中第一个想法就是中病毒了,于是开始了我的杀毒之旅。
在本篇文章中,笔者结合 GCeasy 工具将从以下 5 种 Java GC 图像形态简要为大家分享一些有趣的垃圾收集模式行为,以方便对 Java 虚拟机活动相关基础知识有所了解,为后续的性能调优做好理论准备。
在日常的 Java 虚拟机进行监控的时候,我们往往会观测到各种各样的图形,无论是基于 JDK 自带的 Jconsole、Jvisualvm、JMC 还是第三方工具或插件,例如,Jprofiler 、GCeasy 等。基于对垃圾收集模式的监测,我们可以实时观摩应用程序的健康状态和性能特征,以方便为后续的性能调优提供数据参考。
这篇是「分布式系统理论」系列的第22篇,也是最后一篇。我们来聊聊分布式系统中的最后一道保障——监控。
甲骨文公司表示低暂停G1垃圾回收机制将在取代Parallel GC提高系统执行效率。 目前甲骨文正计划将G1服务器垃圾回收机制作为32位与64位Java服务器配置方案中的默认回收选项,但这种处理方式可
Rust 已经悄然成为了最受欢迎的编程语言之一。作为一门新兴底层语言,Rust 拥有着内存安全性机制、不亚于 C 语言的性能优势、出色的开发者社区等等。本文还介绍了那些正在使用 Rust 的著名公司以及这些公司选择 Rust 的原因。
领取专属 10元无门槛券
手把手带您无忧上云