个人项目经历

一般从简历上就大概能知道你的项目经历,但也有人简历上没写的(比如项目太多了,只写了一部分)。 暴露问题:亮点、难点不够突出 表述方式:项目内容,负责模块,关键难点,我的亮点,最终结果数据、与其他人对比)

项目选择:

  • 突出技术难点
  • 突出业务亮点

技术问题

线上问题排查工具-heapdump

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

top 命令

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

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

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

hbase

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

使用 aop 实现日志采集

AOP 代码修改的两个时机: 1.在编译 java 源代码的时候 ----编译时增强 2.在运行时动态地修改类 ----运行时增强(动态代理)

实现: 1、定义切面@interface LogServiceAspect注解 切入点表达式 标识拦截哪些方法 2、定义拦截器 判断是否有注解,加入切面业务逻辑:拦截器 TestInterceptor 统一切面日志 参数校验、统一异常处理、日志打印 @Pointcut(value = "@annotation(logServiceAspect)")

如何定位问题到代码 - 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。原来是堆内存的新生代和老年代的空间不够了,需要进行 fullGCminorGC,但是每次 fullGCmonorGC 只能释放一点点空间,然后很快又达到了需要 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 包里面的,再联想到两周前才做过 viewcacheforest 的迁移,这两周开始出现的 cpu 利用率飙高的谜题终于真相大白了。

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

系统设计

运维系统设计

设计时包含哪些子系统/模块,之间如何交互 我的回答:采集、接收、存储; 报警;扩容;安全

后记

如果是被面试问到以上这些内容,你会如何回答呢?

难么?