今天遇到的场景很常见, 所以收藏一下.

场景是这样的, 我们维护了一个 redis 数据, 用户反馈数据错误 , 我们观察的确存在问题. 需要去读代码. 但是 代码非常久远了.
找了很多地方 并没有进行更新操作. 所以采用如下方案找到代码.

1. redis monitor

# redis-cli -h 127.0.0.1  monitor |grep -i redis:test:hash |grep  SET > test.log

2. 去重检索 IP:端口

$ cat test.log  |grep SET  |awk  '{print $3 }' |awk -F "\]" '{print $1}' |awk -F ':' '{print $1 " "$2}' |sort -rn |uniq  


10.0.0.1 31945
10.0.0.1 31813
10.0.0.1 31801
10.0.0.1 31757
10.0.0.1 31723
10.0.0.1 31703
10.0.0.1 31669
10.0.0.1 31647
10.0.0.1 31623
10.0.0.1 31611
10.0.0.1 31609
10.0.0.1 31607
10.0.0.1 31605
10.0.0.1 31587
10.0.0.1 31551
10.0.0.1 31549
10.0.0.1 31535
10.0.0.1 31533
10.0.0.1 31521
10.0.0.2 38693

montor 中输出的 客户端ip 及 客户端连接时使用端口.

3.通过客户端连接和端口找到具体的进程.

从上面的日志能看出 10.0.0.2 这台机器只有一个单端口 访问. 查看服务器IP 是其他服务的机器.

$ sudo lsof -i :38693

COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
php     10963 root   71u  IPv4 84827196      0t0  TCP test-service-1.internal:38693->172.0.0.1:6379 (ESTABLISHED)

上面已经给到了进程名称 和 进程ID

$ ps -ef |grep -i 10963

root     10963 10939  0 Apr28 ?        00:01:09 test-swoole-worker-18
root     14254 14111  0 09:43 pts/1    00:00:00 grep --color=auto -i 10963

systemd-journald 是一个收集并存储各类日志数据的系统服务。 它创建并维护一个带有索引的、结构化的日志数据库， 并可以收集来自各种不同渠道的日志：

在现代的 Linux 系统中，系统日志记录是关键的运维任务之一。为了满足系统管理员对高效、可靠和灵活日志管理的需求，systemd 项目引入了 systemd journal。本篇博客将介绍 systemd journal 的基本概念、工作原理以及如何使用它来管理系统日志。

什么是 systemd journal？

systemd journal 是 systemd 提供的一种高性能日志记录系统。它以二进制格式存储系统日志数据，并提供了强大的查询和分析功能。journal 文件是用来存储这些日志数据的文件。journal 文件的命名通常遵循以下格式：system@<unique-id>.journal。其中，<unique-id> 是一个唯一标识符，用于区分不同的 journal 实例。

systemd journal 的优势

相比传统的文本日志文件，systemd journal 提供了几个重要的优势：

1. 高性能和效率：journal 以二进制格式存储日志数据，使得写入和读取操作更加高效。它使用索引和数据结构来加速日志查询，提供快速的日志访问速度。
2. 结构化日志：journal 支持结构化日志记录，允许开发人员在日志消息中添加键值对的元数据。这样可以更容易地解析和分析日志数据，提取有用的信息。
3. 日志持久化：journal 文件可以持久化存储系统日志，即使在系统重启后仍然可用。这对于故障排除和历史数据分析非常有价值。
4. 可靠性和完整性：journal 使用写入确认机制，确保日志数据的完整性和可靠性。即使在系统崩溃或断电的情况下，也能保证日志数据的安全。

如何使用 systemd journal

使用 systemd journal 来管理系统日志非常简单。以下是一些常用的命令和操作：

• 查看实时日志：journalctl -f
• 根据关键词过滤日志：journalctl -u service-name
• 按时间范围查询日志：journalctl --since "2022-01-01" --until "2022-01-31"
• 导出日志到文件：journalctl > logs.txt

通过这些命令，你可以轻松地查看、过滤和导出 systemd journal 中的日志数据。

总结
systemd journal 是一个强大的日志记录系统，为系统管理员和开发人员提供了高效、可靠和灵活的日志管理工具。它以二进制格式存储日志数据，支持结构化日志和持久化存储，具有出色的性能和可靠性。

希望本篇博客能够帮助你了解 systemd journal，并在实际的日志管理中发挥作用。如果你对更深入的系统日志管理和查询技术感兴趣，建议进一步学习和探索 systemd journal 的高级功能和用法。

参考链接：

• systemd-journald.service 中文手册
• systemd journal 官方文档
• systemd journalctl 官方文档

在 Git 版本控制系统中，cherry-pick 是一个强大的命令，用于选择和提取指定范围内的提交并应用到当前分支上。本文将介绍如何使用 git cherry-pick 命令提取一系列提交，并解释其用法和注意事项。

1. 提取一系列提交

git cherry-pick 命令允许我们选择一系列连续的提交，并将它们应用到当前分支上。下面是一个使用 git cherry-pick 命令的示例：

git cherry-pick c6d4031^..e4b5fc3

在上述示例中，c6d4031 和 e4b5fc3 是两个提交的哈希值，^ 表示排除第一个提交。这个命令会提取从 c6d4031（不包括）到 e4b5fc3（包括）之间的所有提交，并将它们应用到当前分支上。

2. 注意事项

在使用 git cherry-pick 命令时，有一些注意事项需要考虑：

• 冲突解决: 如果在应用提交时发生冲突，需要手动解决冲突，并使用 git cherry-pick --continue 命令继续应用剩余的提交。
• 提交顺序: 提取的提交会按照它们在原始分支上的顺序应用到当前分支上。如果有必要，可以使用 git cherry-pick --reverse 命令按照相反的顺序应用提交。
• 提交依赖: 如果一系列提交之间存在依赖关系，需要确保依赖的提交已经在当前分支上存在。

3. 引用多个提交

除了使用提交的哈希值范围，还可以使用多个提交的哈希值来引用要提取的提交。下面是一个示例：

git cherry-pick c6d4031 e4b5fc3 731f1a8

在上述示例中，c6d4031、e4b5fc3 和 731f1a8 是三个具体的提交哈希值，通过列出这些提交的哈希值，我们可以提取并应用它们到当前分支上。

结论

本文介绍了使用 git cherry-pick 命令提取一系列提交的方法，并提供了一些注意事项。通过合理使用 git cherry-pick 命令，我们可以轻松地选择和应用我们感兴趣的提交，从而更好地管理版本控制。

参考文献

• Git Documentation - git cherry-pick

今天生产突然遇到一个问题. 一个内部的http 接口服务.

master 进程内存溢出, 快速增长内存 问题.

想了很多 也看了很多日志. 发现服务器 php_error.log 在提示内存溢出写入日志内存失败.

[05-Apr-2024 20:56:09 Asia/Shanghai] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20382400 bytes) in FileLog.php on line 217

通过调试发现和 大佬们说的一样:

主进程内存占用过高一般是有大量数据未发送保存在内存缓存区中，请开启心跳检测功能，剔除坏连接。

诶 我们这个问题还是 日志写的太大了. 导致 worker进程直接 Fatal 死掉了. Master 不主动释放, 日积月累服务器内存写满.

在使用 Git 进行版本控制时，我们经常需要撤销一些提交，回到之前的状态。Git 提供了 reset 命令来实现这个功能。本文将介绍 Git reset 命令的三种模式：--soft、--mixed 和 --hard，并解释它们之间的区别和用途。

正文

1. --soft 模式

git reset --soft 模式用于撤销提交，但保留暂存区和工作区的修改。下面是一个示例：

git reset --soft HEAD~1

在上述示例中，HEAD~1 表示回退到上一个提交，使用 --soft 模式后，Git 会将当前分支的 HEAD 移动到指定的提交位置，并且保留之前的修改。这样做的好处是可以重新提交之前的修改，方便对代码进行调整和优化。

2. --mixed 模式

git reset --mixed 模式是默认的模式，用于撤销提交并重置暂存区，但保留工作区的修改。下面是一个示例：

git reset --mixed HEAD~1

在上述示例中，HEAD~1 表示回退到上一个提交，使用 --mixed 模式后，Git 会将当前分支的 HEAD 移动到指定的提交位置，并且重置暂存区，但保留工作区的修改。这样做的好处是可以重新选择要提交的内容，排除一些不需要的修改。

3. --hard 模式

git reset --hard 模式是最彻底的模式，用于撤销提交并重置暂存区和工作区，将它们恢复到指定提交的状态。下面是一个示例：

git reset --hard HEAD~1

在上述示例中，HEAD~1 表示回退到上一个提交，使用 --hard 模式后，Git 会将当前分支的 HEAD 移动到指定的提交位置，并且重置暂存区和工作区，将它们恢复到指定提交的状态。这样做的好处是可以完全撤销之前的修改，回到指定提交的状态。

结论

本文介绍了 Git reset 命令的三种模式：--soft、--mixed 和 --hard。通过合理使用这些模式，我们可以根据需要撤销提交并恢复代码的不同状态，从而更好地管理版本控制。