X应用在生产环境部署了两套集群服务，一个叫A集群，一个是B集群，两个集群分别处理不通的数据，互不干扰。 在11月17号晚上20点发版之后，两个服务集群一切正常。 第二天11月18号上午，服务的数据监控发现A集群不处理数据了，监控数据直接下降到0，但是B集群是运行没问题的，数据也正常。这时我们将A服务重启后一切正常，但是两个小时候又降为0。 11月18号下午16点怀疑是新增的判断逻辑代码有问题，去掉了添加的某判断逻辑代码后发版上线，A集群在发版后的两个小时处理数据量又突然降为0.  A 和 B 的部署代码是一模一样的的，只是处理的数据类别不一样，理论上要出问题应该是两个服务集群都会有这个问题才对。 登录A集群的机器上去看了下运行日志，出现很多如下所示：  ``` ispatcher-26] a.c.Cluster(akka://FeedSync) - Cluster Node [ak...

偶然工作中需要获取视频信息，java本身要获取视频信息比较麻烦，但是可以使用ffmpeg来做到，在机器上安装好ffmpeg，安装好后，输入 `ffmpeg -version` 可以查看自己安装的ffmpeg版本。 官网： http://www.ffmpeg.org/ ffmpeg非常强大，简单的获取一个视频信息就是 `ffmpeg -i 20211201.mp4` 也可以用ffmpeg自带的`ffprobe`命令来查看视频信息 ``` ffprobe -show_streams 20211201.mp4 ``` 看了下ffmpeg是使用c开发的一个多媒体处理工具（不仅仅可以处理视频，也可以处理音频），使用c++去调用和使用java调用的性能损耗应该是差不多的，所以为了简单点，可以直接使用java的cmd调用得到结果。 ``` import org.apache.commons.io.IOUtils; private static String ffprobeProcess(String filePath) { List<String> commend = new A...

> 因为怕踩高压线的缘故很多内容不敢发，这篇文章记录的事件实际是在2020年10月发生的. 这是工作以来见到的第N+起sql未做限制导致的内存溢出，依稀还记得上一次看到这类问题时写的文章： [双十一期间查询服务某节点 OOM 原因分析](https://yuxianghe.net/blog/66) 晚上19点40，同事报了测试环境某服务挂了，当时第一想法是重启，但是重启之后又出现了类似的问题，应用启动后所有的接口不通。 看了下应用日志，没有明显的报错日志刷新，但是ssh到机器上明显感到卡顿，top命令一看，cpu占用非常高。  `top -H -p pid` 看了下进程对应的线程：   将线程id转换为16进制之后在jstack查了下，对应的全是gc线程占用cpu80%以上。 `...

> 好久没有写文章了，主要是很担心触碰公司高压线，其次是真的很忙。。。 现象：应用的内存在高并发下内存持续增加，具体体现在早上7点，每秒处理2W，内存增长趋势很快，分配给应用的内存最大值为4G，但是实际上容器节点的内存使用率早已超过这个值， 通过top命令看到的内存使用并不高，略高于4G，初步怀疑是容器统计有问题，看了下内存的状态信息 cat /sys/fs/cgroup/memory/memory.stat ``` 因为安全保密缘故，以下数据为例子数据，不是真实数据 cache 148365312 rss 5496782848 rss_huge 0 mapped_file 1605632 swap 0 pgpgin 3524638 pgpgout 2146428 pgfault 9691132 pgmajfault 44 inactive_anon 1142784 active_anon 5496709120 inactive_file 104824832 active_file 42397696 unevictable 0 hierarchical_memory_limit 852393...

9.11号在f公司最后一天，9.14号入职了t公司，截止到现在从f离开已经过去半个月，想写一些自己的心情和感受。 实话对f是很不舍，综合来说，f是一个很不错的公司，幸运的是在那里我也遇到了一个很好的领导，很感谢一直以来的照顾和关怀。 18年5月7号入职的fc，我还记得那时候自己拿了好几个offer，最后折中选择了f，进入f的第一件事就是做一个多线程拉取生产环境所有的图片给数据平台做分析某硬件故障问题。 接着和同事一起投入了活动项目的开发，做了差不多半年多的活动，产品经理做走了两个，那时候一直觉得产品经理不理解业务需求是一个很难受的问题，因为铁打的营盘，流水的员工，人来人往都走了。 后来到了18年10月份开始重点涉及派件这一块的需求开发，也慢慢的了解到了公司核心业务的流程。 18年的双十一，那应该是我第一次接触这种高并发高流量的直接面向用户的核心场景问题，18年11月12号下午5点21分左右，redis集群崩溃，哨兵的选举耗时远超预期，导致生产环境几乎所有业务系统雪崩，最后只能靠着重启解决，那一晚我记得整个组加班了一个通宵，将redis哨兵模式版本升级到redis4.0的集群模式，划分多个red...