unix文件系统被塞满的清理策略

2023-11-12 01:30

本文主要是介绍unix文件系统被塞满的清理策略,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

unix 文件系统被塞满的清理策略
作者:田逸( [email]sery@163.com[/email] )from:[url]http://os.51cto.com/art/200705/47120.htm[/url]
 
尽管现在的磁盘容量越来越大,但它终究有被塞满的可能,如果遇上粗枝大叶的系统管理员,磁盘被塞满的时间将变得更短。一个unix/linux运行环境,一旦遇到某个分区(也称文件系统)被塞满,后果也许会十分糟糕我曾有过在凌晨2点起来干活的经历分区/tmp满了,导致某个守护进程不能写入磁盘而异常终止。想必其他人也有类似的情况,怎样处理和避免这样的麻烦呢?这里有些意见供大家参考。
先谈非技术方面的因素,简单的讲就是规章制度。Linux/unix大多是公共服务器,应该禁止上传与工作无关的私人数据。某君买了一个NAS(网络附属存储)设备,473G的硬盘,本来打算做web的后台数据存储,但是,但是….后来据我所知,这个大容量磁盘不到2个月所剩空间不到20G,私下浏览,嘿!大部分数据是他私人的,他本来就有收藏废品的嗜好,难怪呢。因此在这个方面,制度应该严厉一些,避免同事放垃圾数据在公共空间。
磁盘上的数据可能随时增长,任何人不可能24小时盯着它,因此实现自动化监控手段是十分必要的,对于更大规模的网络环境,这也许是唯一的途径。下面是一个用perl写的监控磁盘容量的脚本(大宇对此有贡献):
#!/usr/bin/perl -w
# this program will check disk capacity $full and send the warning message
# to $email_address
# (set the threshold to 90 and check it in the daytime so no paging
#  is needed)
my $email_address = '[email]sa@yourcom.com[/email]';
my $hostname = `/sbin/ifconfig -a|grep inet|head -1|cut -f2 -d":"|cut -f1 -d" "`;
my $dmesg = `dmesg`;
chomp(my $now = `date +"%x %X"`);
my $full = 90; # the threshold to send the warning
my $warn = 95;
my $count = 0;
my ($dev,$total,$used);
my @df_messages = `df|grep -v proc`;
print @df_messages;
shift(@df_messages);
foreach $message (@df_messages) {
chomp($message);
($dev, $total, $used, $available, $capacity, $mount) = split(/\s+/, $message);
$capacity =~ s/(\d+)\%/$1/;
if ($capacity > $full) {
$available[$count] = $available;
$capacity[$count] = $capacity;
$mount[$count] = $mount;
++$count;
$email_address = '[email]sa@yourcom.com[/email]' if ($capacity > $warn);
}
}
if ($count > 0) {
open(MAIL, "|/usr/sbin/sendmail -t");
print MAIL "To: $email_address \n";
print MAIL "Subject: Disk almost full on $hostname ($now)\n";
print MAIL "\n";
for ($i = 0; $i < $count; ++$i) {
print MAIL "There are only $available[$i] KB ($capacity[$i]\% full) left on $mount[$i] \n";
}
}
if ( $dmesg =~ m/ERROR/ )
{
open(EMAIL, "|/usr/sbin/sendmail -t") or die "Can't fork for sendmail: $!\n";
print EMAIL  <<_EOF_ ;
To: $email_address
subject: HARDWARE error on $hostname!!!
$hostname needs to be checked right now!
.
_EOF_
close("EMAIL");
}
把这个脚本放在定时任务crontab里即可实现自动监控,只要某个分区的容量达到脚本中阀值,系统就会发送报警邮件到管理员信箱,更进一步还可设定发送手机短信报警。
知道某个分区快要被塞满的情况后,接下来的事情就是清理它了。登陆系统,然后使用命令df –h察看具体的磁盘使用情况(老一点版本的solaris不支持选项-h,请用-k这个选项),
磁盘的利用率是以百分比的方式显示的,非常直观。找到快要被塞满的分区之后,应该先着手查找占用空间大的最大的文件,然后处理这个占用空间最大的文件。这里我用一个实例(根分区/root)来演示这个过程。
1、   进入目录/root,执行命令 du –h | sort –n 就把当前目录下目录以及文件所占的大小按顺序排列出来了,一屏显示不完的话再用加一个管道 du –h | sort –n | more 就好了。
-bash-3.00# du -h | sort -n| more
1K   ./.dt/appmanager
1K   ./.dt/help
1K   ./.dt/icons
1K   ./.dt/tmp
……….( 省略若干行 )
914K   ./mysql-5.0.37/zlib
933K   ./mysql-5.0.37/ndb/src/kernel/blocks/dblqh
938K   ./mysql-5.0.37/scripts
 945M   .    // 这个东西占太大的空间
957K   ./mysql-5.0.37/extra/yassl/taocrypt
959K   ./vsftpd-2.0.5
1002K   ./mysql-5.0.37/ndb/src/common
-bash-3.00#         
有上面的输出,我们可以知道在当前目录里有大文件,但是看不出是哪个文件。
2、   再执行命令 ls –al | grep ^- |more 就可以看见每个文件的大小。
-bash-3.00#         ls -al | grep ^-|more
-rw-------   1 root     root         810 Apr 29 09:59 .ICEauthority
-rw-------   1 root     root          98 Apr 29 09:59 .Xauthority
-rw-------   1 root     root         730 Apr 30 07:52 .bash_history
-rwxr-xr-x   1 root     root        5111 Apr 29 08:30 .dtprofile
-rw-r--r--   1 root     root          81 Apr 29 08:30 .gtkrc-1.2-gnome2
-rw-------   1 root     root           0 Apr 29 08:30 .recently-used
-rw-r--r--   1 root     root     681090961 Feb 28 12:29 10202_database_solx
86.zip
………. (省略若干)
-rw-r--r--   1 root     root     3069440 Apr 29 11:31 tar-1.16-sol10-x86-lo
cal
-rw-r--r--   1 root     root     10895360 Oct 22  2006 tar-1.16.tar
-rw-r--r--   1 root     root      155985 Jul  3  2006 vsftpd-2.0.5.tar.gz
-bash-3.00#  
字体为红色的哪行就是最大文件的信息,它的文件名是10202_database_solx86.zip,再用命令du –h 10202_database_solx86.zip可直接显示它的大小为650M
-bash-3.00#   du -h 10202_database_solx86.zip
650M   10202_database_solx86.zip
3、移走或删除占用空间的大文件。
大家看一看,找大文件是不是很简单?!当然如果使用awk这样的工具写shell脚本更是方便的法门,还有一个方法是用find加选项 –size,请大家自己去试验。

















本文转自sery51CTO博客,原文链接:http://blog.51cto.com/sery/26141 ,如需转载请自行联系原作者

这篇关于unix文件系统被塞满的清理策略的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/394169

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

列举你能想到的UNIX信号,并说明信号用途

信号是一种软中断,是一种处理异步事件的方法。一般来说,操作系统都支持许多信号。尤其是UNIX,比较重要应用程序一般都会处理信号。 UNIX定义了许多信号,比如SIGINT表示中断字符信号,也就是Ctrl+C的信号,SIGBUS表示硬件故障的信号;SIGCHLD表示子进程状态改变信号;SIGKILL表示终止程序运行的信号,等等。信号量编程是UNIX下非常重要的一种技术。 Unix信号量也可以

缓存策略使用总结

缓存是提高系统性能的最简单方法之一。相对而言,数据库(or NoSQL数据库)的速度比较慢,而速度却又是致胜的关键。 如果使用得当,缓存可以减少相应时间、减少数据库负载以及节省成本。本文罗列了几种缓存策略,选择正确的一种会有很大的不同。缓存策略取决于数据和数据访问模式。换句话说,数据是如何写和读的。例如: 系统是写多读少的吗?(例如基于时间的日志)数据是否是只写入一次并被读取多次?(例如用户配

Flink任务重启策略

概述 Flink支持不同的重启策略,以在故障发生时控制作业如何重启集群在启动时会伴随一个默认的重启策略,在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略,该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。常用的重启策略: 固定间隔 (Fixe

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

未雨绸缪:环保专包二级资质续期工程师招聘时间策略

对于环保企业而言,在二级资质续期前启动工程师招聘的时间规划至关重要。考虑到招聘流程的复杂性、企业内部需求的变化以及政策标准的更新,建议环保企业在二级资质续期前至少提前6至12个月启动工程师招聘工作。这个时间规划可以细化为以下几个阶段: 一、前期准备阶段(提前6-12个月) 政策与标准研究: 深入研究国家和地方关于环保二级资质续期的最新政策、法规和标准,了解对工程师的具体要求。评估政策变化可

面对Redis数据量庞大时的应对策略

面对Redis数据量庞大时的应对策略,我们可以从多个维度出发,包括数据分片、内存优化、持久化策略、使用集群、硬件升级、数据淘汰策略、以及数据结构选择等。以下是对这些策略的详细探讨: 一、数据分片(Sharding) 当Redis数据量持续增长,单个实例的处理能力可能达到瓶颈。此时,可以通过数据分片将数据分散存储到多个Redis实例中,以实现水平扩展。分片的主要策略包括: 一致性哈希:使用一

使用jetty和mongodb做个简易文件系统

使用jetty和mongodb做个简易文件系统 - ciaos 时间 2014-03-09 21:21:00   博客园-所有随笔区 原文   http://www.cnblogs.com/ciaos/p/3590662.html 主题  MongoDB  Jetty  文件系统 依赖库: 1,jetty(提供http方式接口) 2,mongodb的java驱动(访问mo

集群环境下为雪花算法生成全局唯一机器ID策略

雪花算法是生成数据id非常好的一种方式,机器id是雪花算法不可分割的一部分。但是对于集群应用,让不同的机器自动产生不同的机器id传统做法就是针对每一个机器进行单独配置,但这样做不利于集群水平扩展,且操作过程非常复杂,所以每一个机器在集群环境下是一个头疼的问题。现在借助spring+redis,给出一种策略,支持随意水平扩展,肥肠好用。 大致策略分为4步: 1.对机器ip进行hash,对某一个(大于

数据库归档策略

数据库迁移策略 为备战双11,需要将数据库中的相关表(历史订单)进行归档,以便腾出更多的空间迎接订单的暴增。作者经过尝试,得出自认为最优的解决方案。下面给出数据库归档策略及示例代码。 现有条件: 1.现有两个数据库:db-A 以及 db-B; 2.两个库中有字段相同的表:tba(表中只有字段订单id–rx_id(long型) 有索引); 3.归档库的tba中还有17年整年的归档数据。 4.由于单