线上的Redis服务经经常有业务反馈响应慢的问题,针对这类问题,最好的分析方法是确定一个Redis的基准性能,然后去分析究竟什么原因导致的Redis变慢。
使用df或者ls命令查看Linux系统的磁盘设备,下图的sdb1就是我接入Ubuntu的一个SD卡,sda是系统硬盘(虚拟机的虚拟磁盘)。
在Linux下,进程退出就表示进程即将结束了(为什么是即将,这是因为Linux设计的是父进程给子进程收尸)。正常退出包括3种情形。
在我们日常工作中,可能会发现free的值(空闲)越来越低,我们会直观的认为内存耗尽,到达瓶颈了,其实,这只是Linux的为了提高文件读取的性能的内存使用机制罢了。不同于Windows,windows程序执行完后,会马上释放掉内存,把Memory降下来。而对于Linux,如果你的服务器内存还有足够多的空间的话,Linux会把程序运行的数据缓存起来,加入到Cache中,所以内存会不断增加,直到一定的限度为止.当超过这限度后,内核必须将脏页写回磁盘,以便释放内存。也就是说,当空闲内存低于一个特定的阈值时,内核的守护进程就会进行内存块回收,那我们如何判断内存达到瓶颈呢?
在上周,我们对 KVM 和 Xen 近几年里在性能上的改进进行了一些有趣的探讨后,我打算自己做一些这方面的小研究。我能找到的最新的资料,是来自2013年 Phoronix Haswell 性能评测上的基准测试。当然,还有其它一些2011年的评测,不过由于 Xen 被收录进 Kernel 3.0,它们都已被热烈地讨论过。 2011年的测试提供了许多很好的基准报表,在三年后的现在,我尽最大努力把它们列出的属性重新测试一遍。但我删减了其中两三个基准测试,原因是它们在未经特定优化的配置后跑出来的数据不是很好,
在讲解进程之前,要先知道什么是冯诺伊曼体系结构。冯诺依曼体系结构是如今最主流的体系结构,所有的硬件可以分为5大单元,单元之间存在交互。
本来是4~8个小时就可以跑完的,在Windows的内置ubuntu子系统运行了30个小时还看不到希望,果断杀掉进程!
Redis 通常是我们业务系统中一个重要的组件,比如:缓存、账号登录信息、排行榜等。
在当今的高科技环境下,生产环境服务器的性能问题可能是一个复杂且棘手的问题。当服务器变慢时,可能会对企业的运营产生重大影响,包括客户满意度下降,工作效率降低,甚至可能导致整个系统崩溃。为了解决这些问题,我们需要深入了解生产环境服务器变慢的原因,并掌握有效的诊断和处理方法。
背景 德国Erlangen大学研究人员找到了一种获取Android手机加密数据的新方法,利用“冷启动攻击”方式可以能从被锁定的Android手机中提取出信息。这项研究测试揭示Android系统所存在的系统漏洞。目前他们仅在Android手机上进行了实验,并认为在iOS设备上实现这样的操作将较困难。 利用这种攻击方式,可以提出手机中的数据,即使手机正处于PIN码保护以及磁盘加密状态。他们将这种方法称之为“FROST”(Forensic Recovery of Scrambled Telephones),通过将
我们经常遇到iowait这个名词,在top命令中,vmstat中,sar命令中,都有它的身影。很多同学按照经验,当看到iowait非常高的时候,一般判定为磁盘I/O有瓶颈,但这并不完全正确。 io并不是一个可靠值。
大家好,我是飞哥!前几天看到一个有意思的问题,我前几天在朋友圈分享了,今天再在公众号里给大家发一下。
几年前,用Proxmox Virtual Environment(一个VMWare Vsphere的开源替代,以后简称PVE)搭建了一个测试云平台,使用了PVE自带的分布式存储Ceph。加上PVE自带的KVM虚拟机和LXC容器,再配置了虚拟交换机Open vSwitch,勉强算是一个所谓的超融合构架。
Redis 作为优秀的内存数据库,其拥有非常高的性能,单个实例的 OPS 能够达到 10W 左右。但也正因此如此,当我们在使用 Redis 时,如果发现操作延迟变大的情况,就会与我们的预期不符。
最近在做文本统计,用 Python 实现,遇到了一个比较有意思的难题——如何保存统计结果。
我们都知道,半同步复制中,如果 slave 比较慢,会拖慢 master 的提交性能。
想观察 IO 相关的行为,需启用 performance_schema 的 instrument(生产者)和 consumer(消费者)。
前面已经讲过了雪花算法,里面使用了System.currentTimeMillis()获取时间,有一种说法是认为System.currentTimeMillis()慢,是因为每次调用都会去跟系统打一次交道,在高并发情况下,大量并发的系统调用容易会影响性能(对它的调用甚至比new一个普通对象都要耗时,毕竟new产生的对象只是在Java内存中的堆中)。我们可以看到它调用的是native 方法:
本文意在对计算机的软硬件体系结构进行梳理,包括计算机体系结构,什么是操作系统,为什么存在操作系统,操作系统如何进行管理,以及建立在这些软硬件基础上的各种提供给用户进行操作的接口。
摘要:分布式数据库市场发展迅速,TDSQL、GuassDB、OceanBase、GoldenDB、TiDB 等各类分布式数据库产品纷纷涌现,尤其在金融行业的落地越来越多。提高分布式数据库的可观测性,提升用户对产品稳定性、可靠性的信心,是金融核心业务云原生化的重要保障。DeepFlow 通过 eBPF 技术零侵扰实现的全景图、分布式追踪和持续剖析等能力为分布式数据库的可观测性建设提供了开创性的新思路。本篇文章以某国有银行分布式核心交易系统为例,介绍 DeepFlow 如何实现 TDSQL 的全链路可观测性,分享如何在客户实践中通过应用、网络、数据库的全栈、全链路统一观测,真实做到 2 至 3 步操作、5 分钟以内的业务异常定界定位。
二、Software,hardware RAID: . 为何磁盘阵列又分为硬件与软件呢? 所谓的硬件磁盘阵列(hardware RAID)是通过磁盘阵列卡来达成阵列的目的。磁盘阵列卡上面有一块专门的芯片在处理 RAID 的任务,因此在性能方面会比较好。在很多任务(例如 RAID 5 的同位检查码计算)磁盘阵列并不会重复消耗原本系统的 I/O 总线,理论上性能会较佳。此外目前一般的中高阶磁盘阵列卡都支持热拔插,亦即在不关机的情况下抽换损坏的磁盘,对于系统的复原与数据的可靠性方面非常的好用。
上一章我们讲解了标准分区的使用过程,可以看到,标准分区的配置比较简单,但是标准分区也有很显著的缺点,如:分区创建后不可扩容、分区的空间必须连续,不允许跨越多块空间或磁盘。但是这些缺点,却是我们在生产环境中比较常见的需求,如:存放某个软件相关数据的分区,经常会被软件的数据所占满,需要空间扩容,而且一块磁盘存满了,还需要再加一块新的磁盘。为了满足这种需求,Linux中就需要使用LVM技术来实现。
到底是什么在消耗CPU? 我开始考虑在同一台机器上运行的其他Wolfram云服务了,但看起来它们不像是会导致我们所看到的缓慢运行问题。但是想要简化系统的想法使我想把这些都删除。一开始,我隔离了生产集群上的一个节点,然后我建立了一个自己的Wolfram Private Cloud。但是缓慢运行的问题仍然存在,但令人疑惑的是,在不同时段和不同机器上,它们表现出了一些不同的特点。 在我的Private Cloud上,我可以登录Linux系统查看数据。我做的第一件事就是将 top 和 ps axl 的结果导入到Wo
前面已经讲过了雪花算法 ,里面使用了System.currentTimeMillis()获取时间,有一种说法是认为System.currentTimeMillis()慢,是因为每次调用都会去跟系统打一次交道,在高并发情况下,大量并发的系统调用容易会影响性能(对它的调用甚至比new一个普通对象都要耗时,毕竟new产生的对象只是在Java内存中的堆中)。我们可以看到它调用的是native 方法:
生产服务器变慢了,一般都是从这几点去分析:服务器整体情况, CPU 使用情况,内存,磁盘,磁盘 IO ,网络 IO
我们使用的计算机的全称叫电子计算机,前面有电子两个字,这说的是整个计算机中的核心元器件基本上都是电子单元组成的。但机械硬盘却是一个特殊的例外,它更多是用机械技术做出来的一个产品。当把带有机械技术基因的磁盘搭到计算机,尤其是再应用到服务器领域的时候,暴露出了机械技术的两个严重问题:
从库严重严重落后于主库,读写分离业务失真,基于从库做的报表数据出不来以及基于从库做的数据探查失效。
之前做 MySQL 参数优化的时候,为了寻找瓶颈,我通常是观察 MySQL 的 status ,看哪些计数器有问题,以便确认问题的大致范围和应该调整的参数。虽然这一套屡试不爽,但是玩久了也想换一个新的视角。既然 MySQL 是运行在操作系统之上的,那我们观测操作系统的内核事件,应该也能发现性能问题。
概述 什么是性能? 性能最通俗的衡量指标就是“时间”,CPU的使用率指的是CPU用于计算的时间占比,磁盘使用率指的是磁盘操作的时间占比,当CPU使用率100%时,意味着有部分请求来不及计算,响应时间
导言:运维工作中除了要维持平台的稳定运行以外,还得对服务器的性能进行优化,让服务器发挥出良好的工作性能是稳定运行的基础。腾讯互娱DBA团队的汪伟(simon)在这一领域里整理出了一套性能优化的资料为大家在性能优化提供充足的方向。
解决这个问题的关键是要找到Java代码的位置。下面分享一下排查思路,以CentOS为例,总结为4步。
什么是计算机系统?计算机系统是由硬件和系统软件组成的,它们共同工作来运行应用程序。如下一个hello程序:
该漏洞存在于英特尔的 x86 硬件之中,无法通过微码升级来解决,必须在系统层面通过安装软件、或者购买没有设计缺陷的新处理器来解决——所以包括苹果 64 位 macOS 等在内的其他系统也需要进行类似的更新和调整。 目前,英特尔芯片漏洞的具体细节尚未披露,预计会在下周二的微软补丁发布日公布。虽然 Linux 内核的修补程序可供所有人查看,但源代码中的注释已被改动以混淆该问题。 漏洞可能造成的影响 该 bug 存在于过去十年中所生产的现代英特尔处理器中,它能在一定程度上允许普通的用户程序识别受保护区域的内核布
如果本省用的VirtualBox,参照本文进行安装即可,如果本省用的VMware Player,就先不要安装本软件了
买了一台数据库,最大连接数的参数是 4000,看起来很棒!但是 cpu 和内存并不咋好!是 2c4g的超低配制。
2用户名密码验证(通过授权表做的验证数据库一启动,会把授权表加载到内存中 mysql.user mysql.db mysql.table_priv mysql.column_priv)
前面的几篇文章里讨论过了进程上下文切换和系统调用对系统性能的影响,我们今天再来看另外一个CPU吃货,那就是软中断。
在前文《read文件一个字节实际会发生多大的磁盘IO?》写完之后,本来想着偷个懒,只通过读操作来让大家了解下Linux IO栈的各个模块就行了。但很多同学表示再让我写一篇关于写操作的。既然不少同学都有这个需求,那我就写一下吧。
Consumer Group :Kafka提供的可扩展且具有容错性的消息者机制。 1、重要特征: A:组内可以有多个消费者实例(Consumer Instance)。 B:消费者组的唯一标识被称为Group ID,组内的消费者共享这个公共的ID。 C:消费者组订阅主题,主题的每个分区只能被组内的一个消费者消费 D:消费者组机制,同时实现了消息队列模型和发布/订阅模型。 2、重要问题: A:消费组中的实例与分区的关系: 消费者组中的实例个数,最好与订阅主题的分区数相同,否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。 B:消费者组的位移管理方式: (1)对于Consumer Group而言,位移是一组KV对,Key是分区,V对应Consumer消费该分区的最新位移。 (2)Kafka的老版本消费者组的位移保存在Zookeeper中,好处是Kafka减少了Kafka Broker端状态保存开销。但ZK是一个分布式的协调框架,不适合进行频繁的写更新,这种大吞吐量的写操作极大的拖慢了Zookeeper集群的性能。 (3)Kafka的新版本采用了将位移保存在Kafka内部主题的方法。 C:消费者组的重平衡: (1)重平衡:本质上是一种协议,规定了消费者组下的每个消费者如何达成一致,来分配订阅topic下的每个分区。 (2)触发条件: a,组成员数发生变更 b,订阅主题数发生变更 c,定阅主题分区数发生变更 (3)影响: Rebalance 的设计是要求所有consumer实例共同参与,全部重新分配所有用分区。并且Rebalance的过程比较缓慢,这个过程消息消费会中止。
不知道大家有没有感觉每天写代码的时间过得很快啊,有时候一天过去了一个功能还没完成,但是时间就这么没了!
2)有时候出去面试,明明感觉和面试官聊的很好,但面试完成后就没有后续,是否有过疑惑,这是why?
我是CPU, 他们都叫我阿甘, 因为我和《阿甘正传》里的阿甘一样, 有点傻里傻气的。
领取专属 10元无门槛券
手把手带您无忧上云