最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,我在排查过程中基本都是通过使用 tcpdump 在出现问题的各个环节上进行抓包、分析在那个环节出现问题、针对性去排查解决问题,对症下药,最后终究能够解决问题。但是这种情况大多是因为服务本身的问题,如果是环境问题、操作系统、甚至硬件的问题,可能从服务本身出发不能解决问题,但是这篇文章另辟蹊径,从外部环境分析可能丢包的原因,看完之后,很受用,部分章节对原文有所修改,下面分享出来供更多人参考。
最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。
熊军(老熊) 云和恩墨西区总经理 Oracle ACED,ACOUG核心会员 PC Server发展到今天,在性能方面有着长足的进步。64位的CPU在数年前都已经进入到寻常的家用PC之中,更别说是更高端的PC Server;在Intel和AMD两大处理器巨头的努力下,x86 CPU在处理能力上不断提升;同时随着制造工艺的发展,在PC Server上能够安装的内存容量也越来越大,现在随处可见数十G内存的PC Server。正是硬件的发展,使得PC Server的处理能力越来越强大,性能越来越高。而在稳定性
今天巡检发现,mc1的K8S服务器集群有些异常,负载不太均衡。其中10.2.75.32-34,49的load average值都在40以上,虽然机器的cpu核数都是40或48核不算严重,但也值得重视。
系统负载:在Linux系统中表示,一段时间内正在执行进程数和CPU运行队列中就绪等待进程数,以及非常重要的休眠但不可中断的进程数的平均值(具体load值的计算方式,有兴趣可以自行深究,这里不深究)。说白了就是,系统负载与R(Linux系统之进程状态)和D(Linux系统之进程状态)状态的进程有关,这两个状态的进程越多,负载越高。
在日常工作中,发现 MySQL 的状态不太对劲的时候,一般都会看看监控指标,很多时候会看到熟悉的一幕:CPU 使用率又爆了。本文会简单介绍一下 MySQL 和 CPU 之间的关系,对此有一些了解之后可以更准确的判断出问题的原因,也能够提前发现一些引发 CPU 问题的隐患。
Linux中,%iowait 过高可能是个问题,严重的时候,它能使服务停止, 但问题是,多高才算高? 什么时候应该担心呢?
我们经常遇到iowait这个名词,在top命令中,vmstat中,sar命令中,都有它的身影。很多同学按照经验,当看到iowait非常高的时候,一般判定为磁盘I/O有瓶颈,但这并不完全正确。 io并不是一个可靠值。
--vm-bytes B 指定 malloc() 时内存的字节数,默认256MB --vm-hang N 指定执行 free() 前等待的秒数 -d N、 --hdd N
us(user):表示 CPU 在用户运行的时间百分比,通常用户 CPU 高表示有应用程序比较繁忙。典型的用户程序有:数据库、Web 服务器等。
通常情况下,我们一台宿主机上会同时启动多个Docker容器,而在默认情况下,Docker是没有限制其运行的容器所使用的硬件资源,比如CPU,内存,IO等。而在实际环境中,往往一个容器的负载过高,会占用宿主机的大部分资源,会导致其他容器的访问资源被抢占,而出现响应超时或无法响应等情况。
查看CPU使用 在 Linux 系统下,使用 top 命令查看 CPU 使用情况。
CPU 过高、Full GC次数过多、内存使用过多、硬盘空间不足等问题,都会带来系统突然运行缓慢的问题,也是面试特别容易被问到的,下面针对系统运行缓慢等问题进行展开。
udp 数据包的理论长度是多少,合适的 udp 数据包应该是多少呢?
只要业务逻辑代码写正确,处理好业务状态在多线程的并发问题,很少会有调优方面的需求。最多就是在性能监控平台发现某些接口的调用耗时偏高,然后再发现某一SQL或第三方接口执行超时之类的。如果你是负责中间件或IM通讯相关项目开发,或许就需要偏向CPU、磁盘、网络及内存方面的问题排查及调优技能
cgroup还有其他一些限制特性,如io,pid,hugetlb等,这些用处不多,参见Cgroupv1。下面介绍下与系统性能相关的io和hugepage,cgroup的io介绍参考Cgroup - Linux的IO资源隔离
nodejs 提供了os.platform()和os.type(),可以用来识别操作系统平台。推荐使用: os.platform()
a. on-CPU:执行中,执行中的时间通常又分为用户态时间user和系统态时间sys。
原文链接:https://rumenz.com/rumenbiji/linux-iostat.html
案发现场的日志: 缓存集群redis重启错误报错: 29808:M 07 Jun 09:46:32.209 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 29808:M 07 Jun 09:46:32.209 # Server started, Redis version 3.0.4 2
一个基于 Linux 操作系统的服务器运行的同时,也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感,但是这些参数对于开发者来说也十分重要,尤其当你的程序非正常工作的时候,这些蛛丝马迹往往会帮助快速定位跟踪问题。 这里只是一些简单的工具查看系统的相关参数,当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的,而那些更加细致、专业的性能监测和调优,可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成哦。毕竟来说,系统性能监控本身就是个大学
这是查看平均负载的快速方法,该平均负载指示要运行的任务(进程)的数量。在Linux系统上,这些数字包括要在CPU上运行的进程以及在不可中断I / O(通常是磁盘I / O)中阻塞的进程。这给出了资源负载(或需求)的高级概念,然后可以使用其他工具进一步探索。
线上问题不同于开发期间的 bug,与运行时环境、压力、并发情况、具体的业务相关。对于线上的问题利用线上环境可用的工具,收集必要信息 对定位问题十分重要。
一个基于 Linux 操作系统的服务器运行的同时,也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感,但是这些参数对于开发者来说也十分重要,尤其当你的程序非正常工作的时候,这些蛛丝马迹往往会帮助快速定位跟踪问题。
有时候会遇到一些疑难杂症,并且监控插件并不能一眼立马发现问题的根源。这时候就需要登录服务器进一步深入分析问题的根源。那么分析问题需要有一定的技术经验积累,并且有些问题涉及到的领域非常广,才能定位到问题。所以,分析问题和踩坑是非常锻炼一个人的成长和提升自我能力。如果我们有一套好的分析工具,那将是事半功倍,能够帮助大家快速定位问题,节省大家很多时间做更深入的事情。
在现代计算机系统中,了解系统的内部运行情况对于诊断问题、优化性能以及进行安全监控至关重要。bpftrace作为一款强大的跟踪工具,为开发人员和系统管理员提供了一种独特的方式来监视和分析Linux系统的内部运行。本文描述bpftrace的原理和使用。
上篇文章写完后,性能调优|成都核酸系统篇 收到了一些夸赞,让我有继续写下去的动力;
4、查看有多少个php-fpm执行 ps -fe |grep "php-fpm"|grep "pool"|wc -l
一个基于 Linux 操作系统的服务器运行的同时,也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感,但是这些参数对于开发者来说也十分重要,尤其当你的程序非正常工作的时候,这些蛛丝马迹往往会帮助快速定位跟踪问题。 这里只是一些简单的工具查看系统的相关参数,当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的,而那些更加细致、专业的性能监测和调优,可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成哦。 毕竟来说,系统性能监控本身就是个
oracle数据库,需要对kernel.shmmax shmmni shmall sem fs.file-max优化 web应用服务器,需要net.ipv4.ip_local_port_range tcp_tw_reuse somaxconn
在Linux 操作系统中,当应用程序需要读取文件中的数据时,操作系统会先分配一些内存,将数据从磁盘读入到这些内存中,然后再将数据发给应用程序;当需要往文件中写数据时,操作系统先分配内存接收用户数据,然后再将数据从内存写到磁盘上。然而,如果有大量数据需要从磁盘读取到内存或者由内存写入磁盘时,系统的读写性能就变得低下。因为无论是从磁盘读数据,还是写数据到磁盘,都是一个很消耗时间和系统资源的过程。
CPU诊断主要关注平均负载(Load Average), CPU使用率,上下文切换(Context Switch), 常用的top命令查看cpu使用率以及服务器负载情况。
我们日常接触性能诊断问题,一般分为两种情况,一是线上应用真的出现性能问题;二是我们需要对准备上线的系统进行性能预估;后者需要压力测试辅助进行,此处不表。
在 2018 年底,vivo AI 研究院为了解决统一的高性能训练环境、大规模的分布式训练、计算资源的高效利用调度等痛点,着手建设 AI 计算平台。白驹过隙,将近两年时间过去了,平台的建设和落地取得了很大的进展,成为了 vivo AI 领域的核心基础平台。平台现在已经有超过 500 多个用户,来自人工智能、影像、互联网等多个部门。平台的容器集群有 1000 多台服务器,拥有 50000 多 CPU 核,1000 多张 GPU 卡,GPU 算力将近 100 PFLOPS。每天运行 1000 多个的算法训练任务,部署了 100 多个的模型推理服务和 AI 应用。这些训练任务和应用都是以容器的方式运行。平台从当初服务深度学习训练为主,到现在演进成包含 VTraining、VServing、VContainer 三大模块,对外提供模型训练、模型推理和容器化的能力。
计算机的文件系统是一种存储和组织计算机数据的方法,它使得对其访问和查找变得容易,文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念,用户使用文件系统来保存数据不必关心数据实际保存在硬盘(或者光盘)的地址为多少的数据块上,只需要记住这个文件的所属目录和文件名。在写入新数据之前,用户不必关心硬盘上的那个块地址没有被使用,硬盘上的存储空间管理(分配和释放)功能由文件系统自动完成,用户只需要记住数据被写入到了哪个文件中。
文章目录 遇到的问题 使用SQLServer Profiler监控数据库 SQL1:查找最新的30条告警事件 SQL2:获取当前的总报警记录数 有哪些SQL语句会导致CPU过高? 查看SQL的查询计划
某机器上网络出现时断时续的问题,网络的同事发现ovs进程的CPU消耗很高,硬件offload的规则下发卡住的问题。即通过netlink向内核发送消息卡住。
一个基于 Linux 操作系统的服务器运行的同时,也会表征出各种各样参数信息。通常来说运维人员、系统管理员会对这些数据会极为敏感,但是这些参数对于开发者来说也十分重要,尤其当程序非正常工作的时候,这些蛛丝马迹往往会帮助快速定位跟踪问题。
这里只是一些简单的工具查看系统的相关参数,当然很多工具也是通过分析加工 /proc、/sys 下的数据来工作的,而那些更加细致、专业的性能监测和调优,可能还需要更加专业的工具(perf、systemtap 等)和技术才能完成哦。毕竟来说,系统性能监控本身就是个大学问。
这些参数主要是用来调整virtual memory子系统的行为以及数据的写出(从RAM到ROM)。 这些节点(参数)的默认值和初始化的过程大部分都可以在mm/swap.c中找到。 目前,/proc/sys/vm目录下有下面这些节点:
在实际的性能测试中,会遇到各种各样的问题,比如 TPS 压不上去等,导致这种现象的原因有很多,测试人员应配合开发人员进行分析,尽快找出瓶颈所在。
用于实时显示当前系统的性能统计信息。该命令主要用来观察整个系统当前的状态,比如可以通过查看该命令的输出来查看当前系统最耗时的内核函数或某个用户进程
操作系统作为所有程序的载体,对应用的性能影响是非常重要的。然而计算机各个组件之间的速度,是非常不均衡的。拿CPU和硬盘的速度来说,比兔子和乌龟的速度差别还要大。
领取专属 10元无门槛券
手把手带您无忧上云