- 博客(34)
- 收藏
- 关注
RSS订阅原创 jvm内存区域
jvm在执行程序过程中将内存分为若干个不同的数据区域。这些区域有各自的用途，以及创建和销毁时间，有的区域随着虚拟机进程的启动而一直存在，有的区域则是依赖用户线程的启动和结束而建立和销毁。程序计数器。程序计数器是一块较小的内存空间，它可以看做是当前线程所执行的字节码的行号指示器。java虚拟机栈。同程序计数器一样java虚拟机栈也是线程私有的，其生命周期与线程相同。栈用于存储局部变量表、操作数栈、动态连接、方法出口等。方法被调用直到执行完毕，就对应着一个栈帧从入栈到出栈。如果线程请求的栈深度大于虚拟机所
2021-02-06 18:54:30
159
1
原创 redis内存优化必知必会
redis为了平衡性能与空间开销，每种数据类型至少提供了两种编码实现，有节省内存空间的实现，也有提高性能的实现。满足一定条件时类型的编码实现会自动转换，不过redis并不支持编码实现的回退，因为频繁的增删操作，数据项压缩编码实现转换非常消耗CPU。redis的内存优化一般从以下几个方面着手过期键删除#查看当前对象使用的数据类型type#查看类型的内部编码encoding高并发写入场景中，在条件允许的情况下字符串长度控制在39字节以内，可减少创建redisObject内存分配次数，从而提高性能
2021-01-31 23:12:39
219
原创 redis的内存回收策略
redis的内存回收主要做了两件事情，一件是删除到达过期时间的键对象，另一件是内存到达配置的上限时触发的内存溢出控制。过期键删除如果redis严格按照过期时间来删除过期键会导致消耗大量的CPU，这对于单线程的redis来说成本过高，因此redis使用惰性删除和定时删除机制来回收过期键的内存惰性删除客户端查询带有过期属性的key时，先判断如果超过过期时间就执行删除并返回空，这样可以节省CPU开销，但是单独使用这种过期键删除方式存在内存泄露问题。如果过期键一直没被访问，那内存将无法得到释放。因此redi
2021-01-31 19:56:11
225
原创 redis的api
redis提供了Stringj、hash、list、set、zset五中数据结构，由于mysql的单线程模型使用合适的数据结构和api可以避免猜到性能上的坑。ziplist可以作为多种外部数据结构的内部实现，ziplist比较节省内存，但数据量越多性能越差。在数据量比较多的情况下redis会根据配置选项将列表类型的内部实现转换为linkedlist。redis常用命令设置值set命令的选项：ex seconds:为键设置秒级过期时间px milliseconds：为键设置毫秒级过期时间n
2021-01-30 18:45:37
111
原创 redis aof的刷盘策略
redis aof是redis缓存持久化的一种方式。持久化就要将内存中的数据写入到磁盘文件中。那么，redis什么时候写磁盘呢？redis通过appendfsync配置提供了三种写盘的方式：appendfsync=always，每次修改事件都会同步aof buffer到aof文件，这种同步策略的安全性最高，效率最低，发生系统奔溃时最多丢失一个事件循环的数据。appendfsync=everysec，每秒同步一次aof buffer到aof文件，这种同步策略与每次修改都同步的策略相比，安全性差一些，但
2021-01-26 21:32:31
3160
1
原创 redo log的刷盘策略
redo log包含日志缓冲（redo log buffer）和磁盘上的日志文件（redo logfile）两部分。mysql每执行新一条dml语句都会先将日志记录在redo log buffer，后续在某个时间点再将多条操作记录写到redo log file，这种先写日志再写磁盘的技术就是mysql中WAL技术（writing-ahead logging）。在计算机的操作系统中用户空间缓冲区的数据是无法直接写入磁盘的，中间必需经过操作系统缓冲区（OS Buffer）。因此，redo log buffe
2021-01-26 16:21:40
2301
1
原创 binlog的刷盘策略
mysql只有在事务提交的时候才会记录binlog日志，此时日志还在内存中，那binlog是什么时候被刷到磁盘中的呢？mysql通过sync_binlog控制刷盘，取值范围0~n0：不强制要求刷盘，由系统自行判断什么时候将binlog写入磁盘；1：每次提交事务就将binlog写入磁盘；n：每提交n个事务将binlog写入磁盘；显然，sync_binlog为1是最安全的，每次提交事务就将binlog写入磁盘，数据一致性最好。但实际情况中，往往为了提高数据库的性能，会将sync_binlog适当设大，
2021-01-25 19:20:25
2253
3
原创 mysql日志@2
mysql的更新会使用到redo log（重做日志）和binlog（归档日志）。redo log的记录是在存储引擎InnoDB中进行；只有InnoDB有redo log;redo log记录物理日志，更新的sql语句；redo log在事务执行的时候不断地被写入（包括事务提交前），日志不随事务提交时间顺序写入，因此每个事务对应多条redo log日志；binlog文件时固定大小，是循环使用的，达到一定大小，会清除日志腾出空间；由于redo log的特性，其可用于数据库宕机后进行数据恢复来保证数据完整性；
2021-01-25 14:39:56
86
原创 mysql查询语句的执行步骤@1
第一步，建立连接。连接、获取权限、管理连接。第二步，查询缓存。对写频繁的库，查询缓存的失效会很频繁，因此不建议开启查询缓存。第三步，分析器。若没命中缓存，则进入分析器分析语句，此步骤包含此法分析、语法分析。第四步，优化器。选择索引，决定表关联顺序等第五步，执行器。校验执行权限（有查询缓存是在走查询缓存阶段进也进行权限校验），查询语句也会在优化器步骤前验证权限我们经常碰到的 ”不存在这个列字段“ 的语法错误，显然实在语句执行的分析器处理步骤抛出的。...
2021-01-25 09:33:37
127
原创 oracle数据库备份
export ORACLE_SID=实例名dt=’date+%Y%M%D%H%S’expdp user_name/user_pwd@instance directory=dump_dir dumpfile=file_namedt.DMPachemas=instancelogfile=dt.DMP achemas=instance logfile=dt.DMPachemas=instancelogfile=dt.log
2021-01-24 19:13:58
116
原创 oracle表数据闪回
1、查询历史事件的数据量select count(1) from table_name as of timestamp to_timestamp(‘2020-07-03 17:10:10’,‘yyyy-mm-dd hh24:mi:ss’);2、执行flashbackflashback table table_name to timestamp to_timestamp(‘2020-07-03 17:10:10’,‘yyyy-mm-dd hh24:mi:ss’)...
2021-01-24 16:59:04
165
原创 awr报告导出步骤
1、登陆服务器;2、切换到oracle用户，su - oracle;3、导出oracle实例ps -ef | grep smonexport ORACLE_SID=实例名sqlplus / as sysdba4、导出awr命令@/oracle/product/11.2.0/rdbms/admin/awrrpt.sql指定type为html5、表分析DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>‘用户名’), tabname=>‘table_n
2021-01-24 16:55:21
1621
原创 Eureka与zk的比较
ek与zk都为微服务集群提供了集群节点信息管理、统一命名服务，两者都通过集群实现了分布式CAP定理中的P——分区容错性。zk集群是主从设计，为保证数据的一致性所有的操作都由leader节点来完成，只有Leader才有写权限其它节点没有写权限，leader节点会将数据同步给其它节点，但zk并不确保所有节点都同步完成，只要过半节点同步完成即可，若zk的leader节点宕掉，zk就会触发选举，在剩余的非leader节点中选举出新的leader节点，zk的选举除了在leader节点宕机的情况下进行，在zk集群初始化
2021-01-23 23:36:54
871
原创 分布式之Eureka
在进行微服务技术选型时不得不提CAP理论。CAP包含的内容是Consistency（一致性）、Availavility（可用性）、Partition Tolerance（分区容错性）。CAP理论证明分布式架构的服务不可能同时满足一致性、可用性和分区容错性。因为是分布在不同机器节点上的服务共同组成集群以提供完整的服务，所以必须保证某个或几个节点故障或者网络分区故障而不影响整个服务的使用，这就是满足分区容错性。采用分布式架构的系统服务节点众多、部署分散，因此，节点故障，网络故障（延迟、丢包)是系统必须要实现的
2021-01-23 23:34:52
296
原创 设计原则之里氏替换原则
只看概念比较抽象，先上实例。一个违反里氏替换原则的例子、一个遵守里氏替换原则的例子。// 绘制图形void drawShape(Shape shape) { if (shape.type == Shape.Circle) { drawCircle((Circle) shape); } else if (shape.type == Shape.Square) { drawSquare((Square) shape); } else { ...... } // 新增图像必需要修改dra
2021-01-23 00:21:33
339
原创 带宽占满导致系统可用性下降
背景：异地通过专线访问应用服务C故障：客户端出现某些业务业务场景无法操作或处理很慢，如：登陆排查步骤：通过专线流量图，查看专线流量使用情况，发现故障时间段内专线流量占满原因分析：有响应内容大或者请求内容大的业务请求将专线的带宽占满，可能是服务接口返回数据的原因、或者是请求接口的数据原因、也可能是静态资源下载的问题。通过网络抓包并结合请求处理业务定位具体的问题原因。最终，通过上述步骤定位为静态资源下载导致的带宽占满问题。首次登陆，客户端需要从服务端下载大量的静态资源。在系统使用高峰期就引爆了这个问题。
2020-12-11 16:27:37
842
原创 一个实际项目中完整的性能调优的故事
项目的实施过程中要求性能测试。系统优化涉及到了一下内容：关于oracle表空间优化，索引空间优化、表索引优化（涉及到表收集操作）关于jemeter服务端及客户端的配置参数优化（jemeter启动内存分配）关于windows客户端机器（扩大机器的tcp通信端口范围）关于服务器关于网关关于redis...
2020-12-11 15:34:24
154
原创 记一次实际生产中服务不可用故障
（1）现象：在某段时间内无法请求到微服务A，连接服务超时，20分钟左右服务又恢复可用（2）服务请求链路：客户端——nginx——微服务网关——微服务A排查过程：查看故障时间段经过nginx和微服务网关对微服务A的请求，在微服务A中没有请求日志，也就是说故障时间段请求并没有到达微服务。（3）故障原因分析：这种现象的原因一般有两种可能，一种是是微服务处理请求时间超过服务熔断时间，导致服务被熔断，在熔断时间内微服务是不可用的。另外一种，微服处理请求时间超过服务的负载均衡配置的请求读取超时时间，然后请求被负载
2020-12-11 15:17:21
425
原创 在spirngboot启动进程中对自定义系统配置文件中重复配置sql问题的优化
(1)问题：如果在sql模板配置文件中配置同名的sql脚本，会导致程序无法正确读取到相应sql配置脚本(2)优化方法：开发重复脚本配置检查组件SftlSourceChecker，在应用启动时调用其进行检查。检查不通过则打印重复项提醒日志并调用System.out(0)退出启动(3)涉及的服务：bath、basic、report(4)在使用检查组件启动服务时，目前batch服务、report服务正常、basic服务存在3项重复配置（需要配置的定义者判断删留）1、ActionEntity.FindAct
2020-12-01 11:22:42
144
原创 利用性能测试排查服务线上内存占用过高的问题续篇
内存占用率高原因排查（1）问题：服务器内存占用率居高不下（2）线索：TreeMap、ReentrantLock实例数高（excel导入组件用到）（3）原因：1、线程池线程中ThreadLocal存放的数据内存泄露。由于线程池中线程的生命很长，在线程池的线程中使用ThreadLocal必需要调用其clear方法清空TreadLocal中的数据释放内存；2、POI组件中的OPCPackage用完需调用close方法释放读写锁锁定的数据修复后压测效果：对相应功能压测10分钟后，抓取堆内存信息分析，无e
2020-12-01 11:19:02
565
4
原创 利用性能测试排查服务线上内存占用过高的问题
问题场景：生产1机，report服务进程内存占用率高，影响到下催记功能的可用性原因：实时导出excel文件的组件所用到的poi对象在jvm永久代内存中没有销毁，导致永久代内存无法回收解决方法：及时调用workbook的cose方法释放相关poi导出相关对象的引用关系排查工具：jmeter/jmap复现场景：首先，构造10万条数据。在电催任务详情压测环境模拟生产混合交易业务操作，同时登陆系统到电催任务详情页发起100笔电催任务详情报表导出。此时，通过jmeter观察服务器cup占用率与内存占用率的走势
2020-12-01 11:15:21
744
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人