记一次服务器内存报警的解决

以你之姓@ 2024-04-18 14:44 95阅读 0赞

### 服务器内存报警 ###

*   *  事件背景
     *  查找报警内存
     *  分析报警原因
     *  问题解决
     *   *  补充：
         *   *  1. Linux定时任务相关指令
             *  2. 服务器定时语法

## 事件背景 ##

周六的早晨收到服务器内存告警邮件，吓一大跳，赶紧爬起来，不然很严重的好吗

--------------------

## 查找报警内存 ##

1、 查出报警的内存目录  
`命令：df -h`  
查询结果： /app 目录 use 是 98%,都187G了，总分配大小才197G，快要爆了好不好 ，极度危险！

2、继续深入查询  
`进入/app目录，查看各文件或文件夹大小：ls -lh`  
发现是/app/logs\_back 目录文件非常大，而且还在飞速增长！

--------------------

## 分析报警原因 ##

此文件夹/app/logs\_back 是服务器对系统应用的日志文件做备份的。  
进一步查看该文件夹发现，里边的备份文件每分钟都会生成新的。点开每个备份的文件夹发现都是一样的日志，都是近一个礼拜的日志文件。

这样原因就很清晰了，是服务器的备份策略出现了问题。本应每隔七天备份这七天的日志，现在是每分钟都在备份这七天的日志。很明显是备份的定时任务cron语法使用错误。

查看服务器备份定时脚本： crontab -e

SHELL=/bin/bash
    PATH=/sbin:/bin:/usr/sbin:/usr/bin
    MAILTO=root
    * * */6 * * /bin/sh  /app/logs_back.sh

问题很明显了，定时语法有误，前面两位是 \* ， 意味着每隔6天后的每时每分都会执行，严重的语法错误，不知道是哪位小哥。问了下项目组是一位年长的小哥搞错了。

--------------------

## 问题解决 ##

1 赶快删除这个文件夹 /app/logs\_back,不让文件继续暴涨  
2 修改定时语法，重新执行定时任务

0 0 * * 6 /bin/sh  /app/logs_back.sh

每礼拜六的00:00执行。

--------------------

### 补充： ###

#### 1. Linux定时任务相关指令 ####

*  crontab -l `查看定时程序脚本执行列表`
 *  crontab -e `编辑定时程序脚本执行列表 进入VI编辑模式`
 *  crontab -u `设定某个用户的cron服务，一般root用户在执行这个命令的时候需要此参数`
 *  crontab -r `删除某个用户的cron服务`

#### 2. 服务器定时语法 ####

它和我们在spring使用的cron语法是一样的，spring比这个还更好一点：多了个秒。

其实在定时的文件也有语法介绍【有的系统可能没有，比如我的阿里云】，这里搬来大家共勉：

# For details see man 4 crontabs
    
    # Example of job definition:
    # .---------------- minute (0 - 59)
    # |  .------------- hour (0 - 23)
    # |  |  .---------- day of month (1 - 31)
    # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
    # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
    # |  |  |  |  |
    # *  *  *  *  * user-name  command to be executed

另:

*  “\*” ：代表取值范围内的数字,
 *  “/” ：代表”每”,
 *  “-” ：代表从某个数字到某个数字,
 *  “,” ：分开几个离散的数字