《Linux系列》Linux日常运维

Linux日常运维

一、Linux根据时间批量删除文件

  当遇到很多日志文件时，想要清理部分日志，但是一个一个清理太过麻烦。所以希望通过从文件时间上做逻辑判断，实现把某一时间之前的文件删除。

1 查看日志总数

ll查看所有的日志信息

wc -l统计数量

[root@zxy_master logs]# ll | wc -l
53

2 查看指定类型的日志

find查找文件命令

-name指定查找文件的名称

[root@zxy_master logs]# find ./ -name 'nifi-app*.log'
./nifi-app_2022-11-16_11.0.log
./nifi-app_2022-09-29_23.0.log
./nifi-app_2022-11-14_04.0.log
......

3 查看指定日期之前的日志

-mtime +n, 查找n天前的文件

[root@zxy_master logs]# find ./ -mtime +50 -name 'nifi-app*.log'
./nifi-app_2022-09-29_23.0.log
./nifi-app_2022-09-30_09.0.log
./nifi-app_2022-10-10_09.0.log
./nifi-app_2022-10-10_10.0.log
./nifi-app_2022-09-30_11.0.log
./nifi-app_2022-09-30_10.0.log
./nifi-app_2022-10-10_11.0.log

4 删除指定日期之前的日志

-exec 执行脚本固定写法

rm -f 删除文件(如果有目录也需要递归删除的话，可以使用rm -rf)

{} \ 固定写法

[root@zxy_master logs]# find ./ -mtime +50 -name 'nifi-app*.log' -exec rm -f {} \;
[root@zxy_master logs]# find ./ -mtime +50 -name 'nifi-app*.log'
[root@zxy_master logs]#

二、buff/cache占用太多内存，如何释放内存？

1.查看free内存

  根据free -h命令，可以看到内存共有7.6G，用了623M，但是free只有2.7G。通过观察可以发现buff/cache占用了4.3G。 buff/cache是由于系统读写导致的文件缓存，没有及时释放。

[root@zxy_master ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           7.6G        623M        2.7G         15M        4.3G        6.7G
Swap:            0B          0B          0B

2.buff/cache

buff是Buffer Cache，即缓冲区缓存。主要是针对块设备的缓存。

cache是Page Cache，即页面缓存。主要用来作为文件系统上的文件数据的缓存来用，尤其是针对当进程对文件read/write操作的时候。

Linux缓存回收机制是，Linux内核会在内存将要耗尽的时候，触发内存回收的工作，以便释放出内存给进程是哟个。一般情况下，释放的这部分内存都是来自于buff/cache部分。

3.手动释放buff/cache

# 清除页面缓存
[root@zxy_master ~]# echo 1 > /proc/sys/vm/drop_caches
# 清除回收slab分配中的对象(包括目录项和inode缓存)
[root@zxy_master ~]# echo 2 > /proc/sys/vm/drop_caches
# 清除页面缓存和slab分配中
[root@zxy_master ~]# echo 3 > /proc/sys/vm/drop_caches
# 释放后内存,可以看到现在可用内存有6.9G
[root@zxy_master ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           7.6G        627M        6.9G         15M        121M        6.8G
Swap:            0B          0B          0B

三、修改Linux系统时间

  在修改Linux系统时间的时候，最好修改系统时间和CMOS时间。系统时间是由Linux操作系统维护的；CMOS时间是CMOS芯片保存的时间；系统启动时，会从CMOS读取时间记录为当前系统时间，同时操作系统也会每隔一段时间将操作系统写入CMOS中。如果使用date命令修改系统事件后，进行了系统重启操作，那么修改后的时间还没同步到CMOS中。重启的时候，系统会从CMOS中读取修改前的时间。所以最好是在修改系统时间后，同时更新一下CMOS时间。

1.修改系统时间

1.1 修改日期和时间

日期和时间之间需要使用空格分开

[root@zxy_master ~]# date
Sat Nov 26 21:01:57 CST 2022
[root@zxy_master ~]# date -s "2022-11-25 21:01:57"
Fri Nov 25 21:01:57 CST 2022
[root@zxy_master ~]# date
Fri Nov 25 21:01:58 CST 2022

1.2 修改日期不修改时间

[root@zxy_master ~]# date
Sat Nov 25 21:02:52 CST 2022
[root@zxy_master ~]# date -s "2022-11-26"
Sat Nov 26 21:03:13 CST 2022
[root@zxy_master ~]# date
Sat Nov 26 21:03:30 CST 2022

1.3 修改时间不修改日期

[root@zxy_master ~]# date
Sat Nov 26 21:03:52 CST 2022
[root@zxy_master ~]# date -s "21:06:00"
Sat Nov 26 21:06:00 CST 2022
[root@zxy_master ~]# date
Sat Nov 26 21:06:02 CST 2022

2.写入CMOS

  通过上面的date -s命令，只是修改了Linux的系统时间，但是CMOS中的时间可能还没改变，所以需要使用clock -w命令把当前系统时间写入到CMOS中。

[root@zxy_master ~]# clock --show
Sun 26 Nov 2022 21:03:29 PM CST  -0.894806 seconds
[root@zxy_master ~]# clock -w
[root@zxy_master ~]#
Sat Nov 26 21:06:30 CST 2022

四、Linux进程显示 – process information unavailable

1.linux服务器JPS查看进程

– process information unavailable

2.原因

在一个用户下启动的进程，使用另一个用户kill这个进程导致的

3.解决

cd /tmp
hsperfdata_用户名

打开后发现有个16501文件，刚好跟jps查看进程的进程ID一样

rm -rf 16501
再查看进程后，已经正常
所以下次尽量用哪个用户启动的进程，在不使用的时候使用该用户关闭该进程

五、linux系统之您在 /var/spool/mail/root 中有新邮件

问题名称：

您在 /var/spool/mail/root 中有新邮件

[root@hadoop vhost]# cd /
您在 /var/spool/mail/root 中有新邮件

解决方案：

## 打开系统配置文件
[root@hadoop /]# vim /etc/profile
## 在文件末尾添加这条语句
unset MAILCHECK
## 更新配置文件
[root@hadoop /]# source /etc/profile

六、Linux中的网络工具nc和telnet

1.安装

[root@hadoop ~]# yum -y install nc
[root@hadoop ~]# yum -y install telnet

2.连接方式

[root@hadoop ~]# nc -lk ***.***.**.** 9999

[root@hadoop ~]# telnet ***.***.**.** 9999

3.作用

可用于模拟生产端生产数据，通过ip 和 端口进行通信
这两种不同点在于，nc是把数据推过去，telnet是生产好数据等对方来拉取
所以在代码端使用nc比较合适
例如这样的代码，在代码的接收数据

//结构流
val ds: Dataset[String] = spark.readStream.format("socket")
            .option("host", "***.***.**.**")
            .option("port", "9999")
            .load()
            .as[String]

案例：结构流WordCount

行为数据发送到kafka之后，使用Spark Strctured Streaming消费数据落地到hudi。因为Strctured Streaming是基于spark sql的流。因为它底层直接操作的DataFrame/DataSet。这个流在使用其实和spark sql差不多。
Strctured Streaming相较于spark streaming的进步，就好比是RDD到DataFrame的进步。

package hudi

import org.apache.spark.sql.streaming.OutputMode
import org.apache.spark.sql.{Dataset, SparkSession}

object StructedStreaming {
    def main(args: Array[String]): Unit = {
        
        System.setProperty("HADOOP_USER_NAME","root")
        val spark: SparkSession = SparkSession.builder()
            .appName("StructedStreaming")
            .master("local[*]")
            .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
            .getOrCreate()
        spark.sparkContext.setLogLevel("ERROR")
        import spark.implicits._
    
        val ds: Dataset[String] = spark.readStream.format("socket")
            .option("host", "****.****.***.***")
            .option("port", "9999")
            .load()
            .as[String]
        val WcDs: Dataset[(String, Long)] = ds.flatMap(_.split("\\s+")).map((_,1)).groupByKey(_._1).count()
        
        WcDs.writeStream.outputMode(OutputMode.Complete())
            .format("console")
            .start()
            .awaitTermination()
    }
}