写点什么

面试:某云面试题目整理

发布于: 2021 年 04 月 30 日

1、项目经历

暴露问题:亮点、难点不够突出

表述方式:项目内容,负责模块,关键难点,我的亮点,最终结果数据、与其他人对比)

项目选择:

1)突出技术难点

2)突出业务亮点

2、技术问题

2-1 线上问题排查工具-heapdump

在故障定位和性能分析的时候,经常会用到一些文件辅助排除代码问题。heap dump 记录了内存信息,可以用于内存溢出等问题的排查。具体的使用方式,可参考JVM heap dump分析

2-2 top 命令

top 命令查看 cpu 最高的进程,然后怎么查看各线程情况

top 命令,交互命令 - H,查看每个线程的性能信息 top -Hp pid

其他操作: P-按照 CPU 排序,M-按照内存排序

2-3 hbase

在项目中怎样使用的,hbase 的最大特点,hive 怎么使用的,包含哪些统计指标

2-4 使用 aop 实现日志采集

AOP 代码修改的两个时机:

1.在编译 java 源代码的时候 ----编译时增强

2.在运行时动态地修改类 ----运行时增强(动态代理)

实现:

1、定义切面 @interface LogServiceAspect 注解

切入点表达式 标识拦截哪些方法

2、定义拦截器

判断是否有注解,加入切面业务逻辑:拦截器 TestInterceptor 统一切面日志 参数校验、统一异常处理、日志打印 @Pointcut(value = "@annotation(logServiceAspect)")

2-5 如何定位问题到代码 - cpu 和 内存

1、通过 top 命令查看占用 cpu 比较高的进程 id。 ps 查看进程信息

2、top -Hp pid,查看进程下哪些线程有问题

3、线程 id(数字,类似 164069) 转成 16 进制。转换之后分别是 280e5,280e6,280e7,280e8

4、转成 16 进制以后,再通过 jstack threadId 查看具体的线程信息,nid 匹配, 例如定位到时 gc 线程(GC task thread#0 标记)

5、jmap -heap 164065 看一下堆内存吧。新生代的空间已经用了 100%,老年代的空间的使用也达到了 99.87%。看到这里,估计大家都明白了。为啥 GC 线程会不停的占用 cpu。原来是堆内存的新生代和老年代的空间不够了,需要进行 fullGC 和 minorGC,但是每次 fullGC 和 monorGC 只能释放一点点空间,然后很快又达到了需要 GC 的程度。再进行 GC,如此循环导致 GC 的线程疯狂调用。必须要强调的是,这里正好达到了即将发生 OOM,但是还没有发生 OOM,立马进行 GC 这么一个平衡。所以 GC 线程才能如此嚣张的占用 CPU.

capacity 总容量, used 已用

6、jstat -GC pid,查看一下 GC 的频率

7、继续分析,为什么堆内存会不够用呢:

分析 dump。通过 jmap -dump:format=b,file=taskDump.bin 生产 dump 文件,然后通过 jhat/zprofiler 对堆内存进行分析

这个 dump 文件里面有三个对象非常大,加在一起基本上有 300M。而我们这个进程的 jvm 堆内存配置的最大才 512M。这三个大对象都是 forest 包里面的,再联想到两周前才做过 viewcache 到 forest 的迁移,这两周开始出现的 cpu 利用率飙高的谜题终于真相大白了。

解决办法很简单,加大 JVM 的堆内存配置大小。同时通知一下 forest 那边的团队,你们的常驻堆内存的对象太大了,要不要进行优化一下。

3、系统设计

3-1 运维系统设计

设计时包含哪些子系统/模块,之间如何交互

我的回答:采集、接收、存储; 报警;扩容;安全

发布于: 2021 年 04 月 30 日阅读数: 21
用户头像

磨炼中成长,痛苦中前行 2017.10.22 加入

微信公众号【程序员架构进阶】。多年项目实践,架构设计经验。曲折中向前,分享经验和教训

评论

发布
暂无评论
面试:某云面试题目整理