[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/system/system-graceful-shutdown.html

脚本

1
2
3
4
5
6
7
8
9
10
11

#!/bin/bash
echo "请输入进程ID："
read pid
echo "正在尝试使用kill -15终止进程$pid ..."
kill -15 $pid
sleep 5 # 等待5秒，给进程清理和资源回收的时间
if ps -p $pid > /dev/null; then # 如果进程仍然存在，则使用kill -9进行强制终止
  echo "进程$pid 仍在运行，正在尝试使用kill -9强制终止 ..."
  kill -9 $pid
fi
echo "进程$pid 已终止"

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/JVM/jvm-gc.html

总揽

吞吐量和最短停顿时间本来就互相矛盾
Parallel Old追求的是吞吐量，CMS追求的是STW的最短
而G1通过把堆分成多个相对独立的Region块，并行的进行选择性的回收，实现一个两者兼顾的回收器

Parallel GC：

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/JVM/report-jvm-optimize.html

忘记记录了。。凭记忆记录下😂，下面是大概流程

背景

之前上线的一个新报表项目，我们的报表服务主要通过定时任务异步生成报表，报表比较大，每次运行时长长，实时性要求较低。
但在生产环境普罗米修斯监控中，发现服务频繁进行GC，且GC前后释放的内存不多，GC期间CPU占用略高。但是GC时长看着很短，为了解决这个问题，我进行了一次针对报表服务的JVM调优

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/database-skew.html

其实改动不是很大，这里简单记录下

背景

• OMS订单系统，日数据量较大平均近3kw/日,高峰达8kw+/日的订单需要存到数据库中（之前64库，现在扩到了128库）；
• 运维后台监控看到，各个库的压力不一，江浙沪，京津冀，深圳755等地区对应的数据库压力很高，而其他地区的数据库压力很低；

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/database/careful-when-use-mycat.html

忙死，简单贴个笔记截图吧
主要就是注意一下mycat分发sql给到对应1~n个数据库,其数据库都会执行这一条sql,然后再去mycat那里聚合结果,所以要注意一下sql的写法

一些笔记

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/database/sub_library_and_sub_table.html

学习自：单KEY业务，数据库水平切分架构实践 | 架构师之路

一些笔记

图中水平分库的基因法虽然好用，但是只支持2个字段的分库，如果要支持2个字段以上，那么就得使用索引表法了，缺点是需要多查一次表。

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/database-scale.html

背景

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/snappy-compress-redis.html

Snappy压缩方案

研发环境(redis单节点，两个哨兵)

1. 压缩率

压缩前的redis内存：

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/Redis-compress-design.html

1、 CPU性能对比（通过对比CPU时间）

对比论证：

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/ES-Query-Optimization.html

除此，还有一个比较好的优化，见： ES文档结构优化

背景

难得有数据留存,写一篇^_^

原逻辑