高并发、服务性能排查
文章平均质量分 84
高并发设计、服务器问题排查
懒鸟一枚
算是总结、沉淀吧……
展开
-
OOM 问题排查思路以及处理工具
OOM问题排查思路以及实践原创 2022-10-27 23:31:37 · 442 阅读 · 0 评论 -
JVM的STW(stop the world)机制及调优案例
1、stop the world指的是GC事件发生过程中,会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停,没有任何响应, 有点像卡死的感觉,这个停顿称为STW。Java中一种全局暂停现象,全局停顿,所有Java代码停止,native代码可以执行,但不能与JVM交互;这些现象多半是由于gc引起。(1)可达性分析算法中枚举根节点(GC Roots)会导致所有Java执行线程停顿。① 分析工作必须在一个能确保一 致性的快照中进行② 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上。转载 2024-06-05 17:24:18 · 284 阅读 · 0 评论 -
分布式相关概念
在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。XA 是由 X/Open 组织提出的分布式事务规范,XA 规范主要定义了事务协调者(Transaction Manager)和资源管理器(Resource Manager)之间的接口。事务协调者(Transaction Manager),因为 XA 事务是基于两阶段提交协议的,所以需要有一个协调者,来保证所有的事务参与者都完成了准备工作,也就是 2PC 的第一阶段。转载 2023-12-15 01:06:52 · 148 阅读 · 0 评论 -
JVM 性能调优及监控诊断工具 jps、jstack、jmap、jhat、jstat、hprof 使用详解
关于 Java 中的内存泄露,广义并通俗的说,就是:不再会被使用的对象的内存不能被回收,就是内存泄露。对象都是有生命周期的,有的长,有的短,如果长生命周期的对象持有短生命周期的引用,就很可能会出现内存泄露。它相对于 CPU Usage Sampling Profile 能够获得更加细粒度的 CPU 消耗信息,能够细到每个方法调用的开始和结束,它的实现使用了字节码注入技术(BCI)。TIME 列就是各个 Java 线程耗费的 CPU 时间,CPU 时间最长的是线程 ID 为21742的线程,用。转载 2023-12-15 00:37:20 · 563 阅读 · 0 评论 -
mysql 性能排查
mysql 下常见遇到的问题有,mysql连接池耗尽,死锁、慢查、未提交的事务。等等我们可能需要看;我们想要查看的可能有1.当前连接池连接了哪些客户端,进行了哪些操作2.当前造成死锁的语句有哪些,是哪个客户端上的,我们如何杀掉结束掉这些连接?3.我们当前的慢查询有哪些?执行了多少次?这些语句有没有记录下来?4.如何查看是不是因为屋里内存、磁盘等原因导致mysql性能下降等?原创 2023-11-28 23:49:36 · 967 阅读 · 0 评论 -
Arthas使用说明
arthas 使用原创 2023-01-09 14:38:29 · 804 阅读 · 0 评论 -
Arthas 使用
Arthas是阿里巴巴开源的Java诊断工具,采用命令行交互的形式进行问题的定位与诊断。它能够帮助你.解决以下问题:这个类从哪个 jar 包加载的?为什么会报各种类相关的 Exception?我改的代码为什么没有执行到?难道是我没 commit?分支搞错了?遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗?线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现!是否有一个全局视角来查看系统的运行状况?有什么办法可以监控到JVM的实时运行状态?怎么快速定位应原创 2023-11-27 11:50:24 · 271 阅读 · 0 评论 -
mysql 性能参数调优详解
综合来看,concurrent_insert=2是绝对推荐的,至于max_write_lock_count=1和low-priority- updates=1,则视情况而定,如果可以降低写操作的优先级,则使用low-priority-updates=1,否则使用 max_write_lock_count=1。这样的好处就是,当又有一个新的请求的时候,mysql不会立即去创建连接 线程,而是先去 Thread_Cache 中去查找空闲的连接线程,如果存在则直接使用,不存在才创建新的连接线程。原创 2023-11-25 00:21:13 · 658 阅读 · 0 评论 -
mysql 变量和配置详解
MySQL 中还有一些特殊的全局变量,如 log_bin、tmpdir、version、datadir,在 MySQL 服务实例运行期间它们的值不能动态修改,也就是不能使用 SET 命令进行重新设置,这种变量称为静态变量。数据库管理员可以使用前面提到的修改源代码或更改配置文件来重新设置静态变量的值。原创 2023-11-24 23:41:06 · 1394 阅读 · 0 评论 -
hikariCP 数据库连接池配置
输出指标说明打印指标的格式为{连接池名称}.pool.{指标}指标解释在运维时的作用活跃连接数此数据长期保持最大连接数值的时候可以尝试扩大连接数空闲连接数此数据过高的时候可以尝试减少配置中的最小连接数配置的最大连接数配置的最小连接数排队等待连接的线程数如果此数据持续飙高,表示连接池中已经没有空闲线程了当前总连接数创建新连接的耗时此数据主要反应当前服务到数据服务的网络延迟创建新连接的超时如果经常创建连接超时这个时候需要排查数据服务或者网络通讯是否异常Usage。原创 2023-11-24 18:35:41 · 1570 阅读 · 0 评论 -
Mysql系列-Mysql优化方案
关于数据库优化,网上有不少资料和方法,但是不少质量参差不齐,有些总结的不够到位,内容冗杂,偶尔发现了这篇文章,总结得很经典,文章流量也很大,所以拿到自己的总结文集中,积累优质文章,提升个人能力,希望对大家今后开发中也有帮助。原创 2023-11-01 17:26:45 · 345 阅读 · 0 评论 -
Kafka保证百万级数据写入和重发问题
Kafka作为当下流行的高并发消息中间件,大量用于数据采集,实时处理等场景,那么它如何做到百万级写入速度呢?我们在享受它带来的高并发,高可靠等便利时,同时不得不面对可能存在的问题,项目中最常见的就是丢包,重发问题,这些问题在项目中又如何解决呢?下面让我们一点点揭开。原创 2023-11-01 16:33:17 · 465 阅读 · 0 评论 -
Mysql系列-性能优化
许多不同的硬件都可能会影响都MySQL的性能,例如操作系统,磁盘大小,可用内存,CPU,网络以及各种计算机组件,最常见的瓶颈就是CPU/IO资源。当数据可以放在内存中或者可以从磁盘中以足够快的速度读取时,CPU可能出现瓶颈;另外,IO瓶颈,一般发生在工作所需的数据远远超过有效内存容量的时候。转载 2023-11-01 00:17:50 · 75 阅读 · 0 评论 -
为什么磁盘满可能导致cpu使用率飙升
CPU 很高不一定是 CPU 的核数不够,有可能是磁盘或者内存的问题导致的 CPU 飙升,所以要透过问题看本质,才能真正的解决性能问题。因为当文件在安装和卸载的时候,会使硬盘中的数据排列非常分散或者断断续续的,让电脑在查找时速度变慢,就造成大量的使用CPU资源。然而删除大文件后发现磁盘空间并未释放,是因为文件删除了但是对应的进程没杀掉,但是磁盘空间还未释放。公司监控系统事件报警某个应用的磁盘满了。通过图上的标红的几个指标可以看到:1)CPU 使用率很高 2)CPUload 都三位数了。原创 2023-09-02 12:25:15 · 1444 阅读 · 0 评论 -
系统中出现大量不可中断进程和僵尸进程(理论)
当 iowait 升高时,进程很可能因为得不到硬件的响应,而长时间处于不可中断状态。从 ps 或者 top 命令的输出中,你可以发现它们都处于 D 状态,也就是不可中断状态(Uninterruptible Sleep)。R 是 Running 或 Runnable 的缩写,表示进程在 CPU 的就绪队列中,正在运行或者正在等待运行。原创 2023-09-02 12:13:51 · 401 阅读 · 0 评论 -
浅谈为什么磁盘慢会导致Linux负载飙升
在Linux系统上,load average这个指标基本失去了作用,因为你不知道它代表什么意思,当看到load average很高的时候,你不知道是runnable进程太多还是uninterruptible sleep进程太多,也就无法判断是CPU不够用还是IO设备有瓶颈。从另一个方面来解释为什么磁盘慢时(大量磁盘使用时),CPU负载会飙高了。原创 2023-09-02 12:01:02 · 541 阅读 · 0 评论 -
怎样来实现流量削峰方案
1.对于秒杀这样的高并发场景业务,最基本的原则就是将请求拦截在系统上游,降低下游压力。如果不在前端拦截很可能造成数据库(mysql、oracle等)读写锁冲突,甚至导致死锁,最终还有可能出现雪崩等场景。2.划分好动静资源,静态资源使用CDN进行服务分发。3.充分利用缓存(redis等):增加QPS,从而加大整个集群的吞吐量。4.高峰值流量是压垮系统很重要的原因,所以需要Kafka等消息队列在一端承接瞬时的流量洪峰,在另一端平滑地将消息推送出去。原创 2023-09-02 11:24:23 · 1056 阅读 · 0 评论