运维规范难题,二回服务器磁盘空间不足导致的一名目多数主题素材

  继前几天服务器上选择 CPU占用过高 前边该利用宕掉了后来       java
二回CPU占用过高难点的排查及缓和

作为一名合格的
Linux
运转技术员,一定要有1套清晰、分明的解决故障思路,当难点出现时,才能极快定位、消除难点,这里给出1个拍卖难点的相似思路:

用作一名合格的 Linux
运行程序员,一定要有1套清晰、明确的解决故障思路,当难点应际而生时,技艺便捷定位、消除难点,这里给出贰个拍卖难题的形似思路:

 网赌十大信誉的平台 1

  • 讲究报错提示音讯:每一种错误的出现,都以提交错误提醒新闻,一般情况下这么些提醒基本固定了问题的六街3陌,因而一定要侧重这一个报错音信,如若对那个错误音信少见多怪,难点永恒得不到化解。

  • 查阅日记文件:有时候报错音信只是给出了难点的表面现象,要想更深远的询问难题,必须查占卜应的日志文件,而日志文件又分为系统日志文件(/var/log)和平运动用的日志文件,结合这多个日志文件,一般就能够定位难题所在。

  • 剖析、定位难题:这么些历程是相比较复杂的,依照报错消息,结合日志文件,同时还要思索任何有关情状,最后找到引起难点的来头。

  • 消除难点:找到了难点现身的原故,化解难点正是很轻松的业务了。

 

明日又冒出了更要紧的难点     前几日缓和完标题  前几天早些时候
出现了系统不能登入  查询日志定位应该数数据库的主题材料

从这些流程能够看到,化解难题的经过尽管分析、查找难题的历程,一旦鲜明难点时有发生的案由,故障也就随即减轻了。

  • 尊重报错提醒消息:每种错误的出现,都以交由错误提示音讯,一般景色下这些提示基本定位了难题的所在,由此一定要尊重这几个报错音信,若是对那些错误音讯习感觉常,难题恒久得不到化解。

  • 翻看日记文件:有时候报错音讯只是给出了难题的表面现象,要想越来越深刻的问询难点,必须查六柱预测应的日记文件,而日志文件又分为系统日志文件(/var/log)和使用的日志文件,结合那四个日志文件,一般就能定位难题所在。

  • 浅析、定位难点:这一个进度是比较复杂的,依据报错音讯,结合日志文件,同时还要思考别的相关处境,最后找到引起难题的原由。

  • 不留余地难题:找到了难题应运而生的来头,解决难题正是很简短的职业了。

末端开采是磁盘满了    其实如故今天的产出难题的诱致, 
死循环刷了专门多的日记,,导致磁盘空间不足 
导致数据库读写出题目了,继而形成应用不可用

整合方面介绍的
Linux 运转难点的减轻思路后,上边大家挑选了伍个相比较优良的 Linux
运转难点,来看望是何许剖析和缓和的:

 

使用cd /  后 du -sh *  列出各文件夹的占用大小

标题1:文件系统破坏导致系统不能运维

从那些流程能够看出,消除难题的进度正是分析、查找难点的进度,1旦鲜明难题时有爆发的缘故,故障也就随即缓和了。

Checking root filesystem

/dev/sda6
contains a file system with errors, check forced

An
error occurred during the file system check

其1似是而非能够看到,操作系统
/ dev/sda伍分区文件系统现身了问题,这一个主题材料发出的机率相当高,平时引起那几个标题的来头根本是系统突然断电,引起文件系统结构差异,一般情状下,化解此难题的法子是应用
fsck 命令,举办强制修复。

#
umount /dev/sda6

#
fsck.ext3 -y /dev/sda6

难点二:“Argument list too long” 错误与减轻方式

#
crontab -e

网赌十大信誉的平台,编辑完后保存退出后,报错
no space left on device

根据上面包车型客车报错掌握到是磁盘空间满了,那么首先是反省磁盘空间,

#
df -h

查看到是
/ var 磁盘分区空间已经落成 百分百,至此定位了难题所在。是 / var
磁盘空间饱满导致,因为 crontab 会在保留时将文件音信写到 / var
目录上面,不过那么些磁盘没有空间了,所以报错。

随之通过命令
du –sh * 命令检查 / var 目录上面包车型地铁兼具文件只怕目录的高低,开掘 /
var/spool/clientmqueue 目录占用了 / var 整个分区大小的 十分九,那么 /
var/spool/clientmqueue
目录下的文书都是怎么产生的,能还是不可能删除,基本上都以邮件消息,能够去除

#
rm *

/bin/rm
:argument list too long

当在
linux 系统中筹算传递太多参数给3个指令时,就能够现出 “argument list too
long” 错误,那是 linux 系统直接以来都有个别限制,查看那个界定可以由此命令
“getconf ARubiconG_MAX” 来实现,

#
getconf ARG_MAX

#
more /etc/issue 查看版本

减轻方式:1、

#
rm [a-n]* -rf

#
rm [o-z]* -rf

二、使用
find 命令来删除

#
find /var/spool/clientmqueue –type f –print –exec rm –f {} ;

3、通过
shell 脚本

#/bin/bash

RM_DIR=’/var/spool/clientmqueue’

cd
$RM_DIR

for
I in `ls`

do

rm
–f $i

done

肆、重新编写翻译内核

亟需手动扩张基础中抽成给命令行参数的页数,展开kernel source 上边包车型客车 include/linux/binfmts.h 文件,找到如下行:

#denfine
MAX_ARG_PAGES 32


32 改为越来越大的值,举个例子 64 也许 128,然后再度编写翻译内核

 

能够见到首假使usr/   进入 usr  继续看磁盘占用

主题材料3:inode 耗尽导致应用故障

结合地点介绍的 Linux 运转难题的消除思路后,上面大家选拔了五个相比优秀的
Linux 运营难点,来看看是如何剖析和消除的:

网赌十大信誉的平台 2

客户的1台
Oracle 数据库如枪炮在关机重启后,Oracle 监听不可能起动,提醒报错 Linux
error : No space left on device

从输出音讯看出来是因为磁盘耗尽导致监听不能运转,因为
Oracle
在运转监听时要求创立监听日志文件,于是首先查看磁盘空间使用意况

#
df -h

从磁盘输出音讯可见,全体的分区磁盘空间都还有剩余不少,而
Oracle 监听写日记的路径在 / var 分区下,/var 下分区空间丰硕。

消除思路:

既然错误提醒语磁盘空间有关,那就深深研讨有关磁盘空间的标题,在
linux 系统中对磁盘空间的据有分为四个部分:第五个是情理磁盘空间,第一个是
inode 节点所攻下的磁盘空间,第多少个是 linux
用来存放在时域信号量的空中,而平日触及较多的是情理磁盘空间。既然不是情理磁盘空间的主题材料,接着就反省是不是是
inode 节点耗尽的标题,通过执行命令 “df -i” 查看可用的 inode
节点。由输出结果来看确实是因为 inode 耗尽导致无法写入文件。

能够通过上边包车型地铁通令查看有些磁盘分区
inode 的总的数量

#
dumpe2fs -h /dev/sda3 |grep ‘Inode count’

各样inode 都有二个数码,操作系统用 inode 号码来分歧不一样的文本,通过‘ls
-i’命令能够查阅文件名对应的 inode 号

要是要翻开那几个文件更详细的
inode 音信,能够由此 stat 命令来完成

#
stat install.log

焚林而猎难点

#
find /var/spool/clientmqueue/ -name “*” -exec rm -rf {} ;

 

/usr/local文件夹还是依旧最大的

难题四:文件已经删除,不过空间未有自由的缘由

 

难点 一:文件系统破坏导致系统无法起动

传承进入/usr/local

运转监察和控制种类发来打招呼,报告1台服务器空间满了,登录服务器查看,根分区确实满了,这里先说一下服务器的一部分去除战略,由于
linux 未有回收站功用,所以线上服务器上具备要刨除的公文都会先移到系统 /
tmp 目录下,然后定时清除 / tmp
目录下的数额。那么些政策本身并未有怎么难点,可是经过检查开采那台服务器的系统一分配区中并从未单身划分
/ tmp 分区,那样 / tmp
下的数量实际上占用根分区的半空中,既然找到了难点,那么删除 / tmp
目录下有个别攻下空间不小的数据文件就可以。

#
du -sh /tmp/* | sort -nr |head -3

因而命令开掘在
/ tmp 目录下有个 6陆G 大小的文件 access_log,那么些文件应当是 apache
爆发的拜会日志文件,从日记大小来看,应该是很久没有清理的 apache
日志文件了,基本论断是其一文件导致的根空间爆满,在确定此文件能够去除后,实践如下删除命令,

#
rm /tmp/access_Iog

#
df -h

从出口来看,根分区空间照旧未有自由,这是怎么回事

一般的话不会油然则生删除文件后空中不自由的图景,可是也存在差别,举例文件进度锁定,只怕有经过一直在向那些文件写多少,要领悟那个主题素材,就须求精晓linux 下文件的囤积机制和存款和储蓄结构。

2个文本在文件系统中存放分为多个部分:数据部分和指针部分,指针位于文件系统的
meta-data 中,在将数据删除后,那个指针就从 meta-data
中革除了,而数据部分存款和储蓄在磁盘中。在将数据对应的指针从 meta-data
中消除后,文件数量部分占用的半空中就足以被掩盖并写入新的内容,之所以出现删除
access_log 文件后,空间还未有自由,正是因为 httpd
进度还在平昔向那些文件写入内容,导致即使删除了 access_Ilog
文件,不过出于经过锁定,文件对应的指针部分未有从 meta-data
中清除,而鉴于指针并未有删除,系统基本就感到文件未有被去除,因而通过 df
命令查询空间未有释放。

主题材料排查:

既然有了化解思路,那么接下去看看是否有经过一向在向
access_log 文件中写入数据,这里要求用到 linux 下的 losf
命令,通过那几个命令能够得到一个照旧被应用程序占用的已去除文件列表

#
lsof | grep delete

从输出能够看来,/tmp/access_log
文件被进度 httpd 锁定,而 httpd
进度还直接向那么些文件写入日志数据,最终一列的‘deleted’状态表达这些日志文件已经被删除,但是出于经过还在一贯向此文件写入数据,由此空间未有释放。

杀鸡取卵难题:

到此处难题就宗旨排查清楚了,消除这一类标题的法门有广大,最简易的章程正是关门恐怕重启
httpd
进程,当然重启操作系统也能够。但是这一个并不是最佳的艺术,对待那种进程不停对文件写日记的操作,要释放文件占用的磁盘空间,最棒的方式是在线清空那些文件,具体能够透过如下命令实现:

#
echo “”>/tmp/access_log

因此那种方法,磁盘空间不但能够即时释放,也得以保证进城继续向文件写入日志,那种艺术平日用来在线清理
apache /tomcat/nginx 等 web 服务发生的日记文件。


题目5:”too many open files” 错误与化解措施


难点现象:这是三个依据java 的 web 应用连串,在后台增多数据时提醒不可能增加,于是登入服务器查看
tomcat 日志,开采如下卓殊音信,java.io.IOException: Too many open
files

透过那一个报错音讯,基本论断是系统能够用的公文讲述符不够了,由于
tomcat 服务室系统 www 用户运转的,于是以 www 用户登录系统,通过 ulimit
–n 命令查看系统能够展开最大文件讲述符的数码,输出如下:

$
ulimit -n

65535

能够见见这台服务器设置的最大能够张开的文书讲述符已经是
65535 了,这么大的值应该丰盛了,可是为啥提示那样的荒唐啊

杀鸡取蛋思路,那么些案例涉及
ulimit 命令的行使

在应用
ulimit 时,有以下三种选用格局:

1、 在用户遭受变量中参预

若果用户使用的是 bash,那么能够在用户目录的意况变量文件. bashrc 恐怕.
bash_profile 中进入 “ulimit –u12捌” 来界定用户最多能够选取 128 个经过

2、 在应用程序的运行脚本中进入

即使应用程序是 tomcat,那么能够再 tomcat 的运行脚本 startup.sh
中投入‘ulimit -n 6553伍’来界定用户最多能够接纳 65535 个文件讲述符

③、 直接在 shell 命令终端施行 ulimit 命令

那种艺术的财富限制只是在实践命令的极端生效,在退出只怕和停业终端后,设置失效,并且那个设置不影响其它shell 终端

缓和难题:

在打听
ulimit 知识后,接着上边的案例,既然 ulimit
设置未有失常态,那么必然是安装未有收效导致的,接下去检查下运行 tomcat 的
www 用户境况变量是不是增多 ulimit 限制,检查后意识,www 用户并无 ulimit
限制。于是接二连三检查 tomcat 运行脚本 startup.sh 文件是不是增加了 ulimit
限制,检查后开掘也未尝加多。最终考略是不是将范围加到了 limits.conf
文件中,于是检查 limits.conf 文件,操作如下

#
cat /etc/security/limits.conf | grep www

www
soft nofile 65535

www
hard nofile 65535

从输出可见,ulimit
限制加在 limits.conf
文件中,既然限制已经增加了,配置也绝非什么样错,为什么还会报错,经过思索,判定唯有壹种或许,那就是tomcat 的运行时间早于 ulimit 能源限制的丰硕时间,于是首先查看下 tomcat
运维时间,操作如下

#
uptime

Up
283 days

#
pgrep -f tomcat

4667

#
ps -eo pid,lstart,etime|grep 4667

4667
Sat Jul 6 09;33:39 2013 77-05:26:02

从出口能够见见,那台服务器已经有
2八三 未有重启了,而 tomcat 是在 20壹三 年 七 月 6 日 九 点运行的,运行了濒临
7柒 天,接着继续看看 limits.conf 文件的修改时间,

#
stat /etc/security/limits.conf

经过
stat 命令清除的收看,limits.conf 文件最终的修改时间是 201三 年 七 月
12,晚于 tomcat 运行时间,清楚难题后,消除难题的主意很简短,重启一下
tomcat 就足以了。

Checking root filesystem

/dev/sda6 contains a file system with errors, check forced

An error occurred during the file system check

 

以此荒唐能够看到,操作系统 / dev/sda陆分区文件系统出现了难点,这几个主题材料发生的机率非常高,平常引起这么些标题的原故根本是系统突然断电,引起文件系统结构不一样样,一般景观下,消除此难点的主意是使用
fsck 命令,进行强制修复。

 

# umount /dev/sda6

# fsck.ext3 -y /dev/sda6

 

标题 二:“Argument list too long” 错误与解决方法

 

# crontab -e

编写完后保存退出后,报错 no space left on device

依赖地点的报错精晓到是磁盘空间满了,那么首先是检查磁盘空间,

 

# df -h

查看到是 / var 磁盘分区空间已经高达 百分百,至此定位了难题所在。是 / var
磁盘空间饱满导致,因为 crontab 会在保存时将文件新闻写到 / var
目录上边,可是那一个磁盘未有空间了,所以报错。

紧接着通过命令 du –sh * 命令检查 / var
目录上面的富有文件可能目录的大小,开掘 / var/spool/clientmqueue
目录占用了 / var 整个分区大小的 9/10,那么 / var/spool/clientmqueue
目录下的公文都以怎么产生的,能还是不能够删除,基本上都是邮件音讯,能够去除

 

# rm *

/bin/rm :argument list too long

当在 linux 系统中间试验图传递太多参数给多少个下令时,就能出现 “argument list
too long” 错误,那是 linux
系统平昔以来都有个别限制,查看那些范围能够经过命令 “getconf ACR-VG_MAX”
来实现,

 

# getconf ARG_MAX

# more /etc/issue 查看版本

 

斩草除根办法:1、

# rm [a-n]* -rf

# rm [o-z]* -rf

二、使用 find 命令来删除

# find /var/spool/clientmqueue –type f –print –exec rm –f {} \;

3、通过 shell 脚本

#/bin/bash

RM_DIR=’/var/spool/clientmqueue’

cd $RM_DIR

for I in `ls`

do

rm –f $i

done

4、重新编写翻译内核

亟待手动扩张水源中分红给命令行参数的页数,张开 kernel source 下边包车型地铁include/linux/binfmts.h 文件,找到如下行:

#denfine MAX_ARG_PAGES 32

将 3贰 改为越来越大的值,举例 6肆 只怕 12八,然后再次编写翻译内核

网赌十大信誉的平台 3

**

难点陆:Read-only file system 错误与化解方法

浅析:出现那一个题材的原故有广大种,大概是文件系统数据块出现不等同导致的,也说不定是磁盘故障变成的,主流
ext3/ext四文件系统都有很强的自笔者修复机制,对于简易的谬误,文件系统一般都足以自行修复,当碰着致命错误无法修复的时候,文件系统为了保险数据一致性和平安,会一时屏蔽文件系统的写操作,讲文件系统
变为只读,今儿现身了上面包车型大巴 “read-only file system” 现象。

手工业修复文件系统错误的命令式
fsck,在修补文件系统前,最佳卸载文件系统所在的磁盘分区

#
umount /www/data

Umount
: /www/data: device is busy

唤醒不或然卸载,恐怕是这几个磁盘中还有文件对应的经过在运维,检查如下:

#
fuser -m /dev/sdb1

/dev/sdb1:
8800

随即检查一下
8800 端口对应的什么样进程,

#
ps -ef |grep 8800

反省后意识时
apache 未有关闭,停止 apache

#
/usr/local/apache2/bin/apachectl stop

#
umount /www/data

#
fsck -V -a /dev/sdb1

#
mount /dev/sdb1 /www/data

 

标题 三:inode 耗尽导致应用故障

大旨得以明确是日记文件太多了

 

客户的1台 Oracle 数据库如枪炮在关机重启后,Oracle
监听无法起动,提醒报错 Linux error : No space left on device

从输出新闻看出来是因为磁盘耗尽导致监听不也许运转,因为 Oracle
在运维监听时要求创制监听日志文件,于是首先查看磁盘空间使用情况

 

# df -h

从磁盘输出新闻可见,全数的分区磁盘空间都还有剩余不少,而 Oracle
监听写日记的门径在 / var 分区下,/var 下分区空间丰硕。

 

斩草除根思路:

既然错误提示语磁盘空间有关,那就深入钻研关于磁盘空间的难点,在 linux
系统中对磁盘空间的攻克分为八个部分:第四个是情理磁盘空间,第叁个是 inode
节点所吞没的磁盘空间,第五个是 linux
用来存放复信号量的空中,而常常触及较多的是情理磁盘空间。既然不是情理磁盘空间的标题,接着就反省是或不是是
inode 节点耗尽的标题,通过试行命令 “df -i” 查看可用的 inode
节点。由输出结果来看确实是因为 inode 耗尽导致力不从心写入文件。

 

能够经过上面包车型客车指令查看某些磁盘分区 inode 的总的数量

# dumpe2fs -h /dev/sda3 |grep ‘Inode count’

种种 inode 都有1个数码,操作系统用 inode 号码来分别分歧的公文,通过‘ls
-i’命令能够查阅文件名对应的 inode 号

 

若果要翻看这些文件更详尽的 inode 音讯,能够通过 stat 命令来兑现

# stat install.log

消除难点

# find /var/spool/clientmqueue/ -name “*” -exec rm -rf {} \;

理清掉一部分日记  mysql就像常了,  应用也寻常了, 
 故而规整了一下服务器的磁盘, 防止下次再一次产生磁盘不足的状态

 

主题材料 四:文件已经去除,可是空间未有自由的来由

干脆那四次面世的标题都以某个里头的施用,  出现了难点影响范围有限

 

运营监察和控制系统一发布来文告,报告一台服务器空间满了,登录服务器查看,根分区确实满了,这里先说一下服务器的一些删减战略,由于
linux 没有回收站作用,所以线上服务器上有所要删减的文书都会先移到系统 /
tmp 目录下,然后定期清除 / tmp
目录下的数量。那一个战略本人并未什么样难题,不过透过检查开掘那台服务器的系统分区中并不曾单独划分
/ tmp 分区,那样 / tmp
下的数额实际上占用根分区的半空中,既然找到了难题,那么删除 / tmp
目录下一些据为己有空间非常的大的数据文件就能够。

 

# du -sh /tmp/* | sort -nr |head -3

经过命令开掘在 / tmp 目录下有个 66G 大小的文本
access_log,那个文件应当是 apache
产生的造访日志文件,从日记大小来看,应该是很久未有清理的 apache
日志文件了,基本剖断是那个文件导致的根空间爆满,在确认此文件可以去除后,推行如下删除命令,

# rm /tmp/access_Iog

# df -h

 

从输出来看,根分区空间还是未有自由,那是怎么回事

貌似的话不会产出删除文件后空中不自由的景况,可是也设有分裂,比方文件进程锁定,可能有进程一直在向这几个文件写多少,要清楚这么些标题,就须求理解linux 下文件的积攒机制和存款和储蓄结构。

 

三个文件在文件系统中存放分为八个部分:数据部分和指针部分,指针位于文件系统的
meta-data 中,在将数据删除后,这些指针就从 meta-data
中清除了,而数据部分存款和储蓄在磁盘中。在将数据对应的指针从 meta-data
中排除后,文件数量部分占用的空中就能够被遮盖并写入新的剧情,之所以现身删除
access_log 文件后,空间还从未自由,就是因为 httpd
进程还在间接向这么些文件写入内容,导致就算删除了 access_Ilog
文件,不过出于经过锁定,文件对应的指针部分从没从 meta-data
中排除,而由于指针并未有删除,系统基本就以为文件未有被剔除,由此通过 df
命令查询空间未有释放。

 

难点排查:

既然如此有了缓和思路,那么接下去看看是或不是有进程一贯在向 access_log
文件中写入数据,这里须要用到 linux 下的 losf
命令,通过那个命令能够获得2个如故被应用程序占用的已去除文件列表

 

# lsof | grep delete

从输出可以观察,/tmp/access_log 文件被进度 httpd 锁定,而 httpd
进度还一向向那个文件写入日志数据,最后一列的‘deleted’状态表达这些日志文件已经被去除,可是由于经过还在直接向此文件写入数据,因而空间未有释放。

 

消除难点:

到这里难题就基本排查清楚了,消除那1类难点的措施有繁多,最简便易行的艺术便是停业或许重启
httpd
进度,当然重启操作系统也得以。但是那些并不是最棒的格局,对待那种经过不停对文本写日记的操作,要自由文件占用的磁盘空间,最佳的法子是在线清空那个文件,具体能够由此如下命令实现:

# echo “”>/tmp/access_log

 

通过那种情势,磁盘空间不但能够登时释放,也足以保持进城继续向文件写入日志,这种办法日常用来在线清理
apache /tomcat/nginx 等 web 服务发生的日志文件。

 

难题 五:”too many open files” 错误与缓和方法

 

主题素材现象:那是1个基于 java 的 web
应用系统,在后台增多数据时提示无法增加,于是登入服务器查看 tomcat
日志,开采如下相当消息,java.io.IOException: Too many open files

 

因而这一个报错音讯,基本决断是系统能够用的文书讲述符不够了,由于 tomcat
服务室系统 www 用户运转的,于是以 www 用户登入系统,通过 ulimit –n
命令查看系统能够展开最大文件讲述符的多寡,输出如下:

$ ulimit -n

65535

 

能够看出那台服务器设置的最大能够打开的文本讲述符已经是 65535了,这么大的值应该丰富了,可是怎么提醒这样的一无所能吗

消除思路,那么些案例涉及 ulimit 命令的接纳

 

在应用 ulimit 时,有以下二种选用方法:

 

壹、 在用户景况变量中插足

只要用户接纳的是 bash,那么能够在用户目录的情况变量文件. bashrc 或然.
bash_profile 中投入 “ulimit –u12捌” 来界定用户最多能够运用 12八 个过程

二、 在应用程序的启航脚本中投入

要是应用程序是 tomcat,那么能够再 tomcat 的启航脚本 startup.sh
中投入‘ulimit -n 65535’来限制用户最多能够运用 65535 个文本讲述符

3、 直接在 shell 命令终端奉行 ulimit 命令

那种措施的财富限制只是在实践命令的终极生效,在剥离可能和关闭终端后,设置失效,并且那些装置不影响其他shell 终端

 

消除难题:

 

在摸底 ulimit 知识后,接着上边的案例,既然 ulimit
设置没不日常,那么自然是安装没有生效导致的,接下去检查下运行 tomcat 的
www 用户处境变量是不是增加 ulimit 限制,检查后开采,www 用户并无 ulimit
限制。于是三番五次检查 tomcat 运维脚本 startup.sh 文件是还是不是增多了 ulimit
限制,检查后发觉也尚无拉长。最后考略是或不是将限量加到了 limits.conf
文件中,于是检查 limits.conf 文件,操作如下

# cat /etc/security/limits.conf | grep www

www soft nofile 65535

www hard nofile 65535

 

从出口可知,ulimit 限制加在 limits.conf
文件中,既然限制已经增多了,配置也从未什么错,为何还会报错,经过构思,决断唯有一种恐怕,那就是tomcat 的开行时间早于 ulimit 财富限制的丰盛时间,于是首先查看下 tomcat
运维时间,操作如下

# uptime

Up 283 days

# pgrep -f tomcat

4667

# ps -eo pid,lstart,etime|grep 4667

4667 Sat Jul 6 09;33:39 2013 77-05:26:02

 

从输出可以看来,那台服务器已经有 28三 未有重启了,而 tomcat 是在 20一3 年
七 月 6 日 九 点运行的,运维了接近 7柒 天,接着继续看看 limits.conf
文件的退换时间,

# stat /etc/security/limits.conf

 

经过 stat 命令清除的看看,limits.conf 文件最终的修改时间是 201三 年 7 月
1二,晚于 tomcat 运维时间,清楚难点后,消除难点的不贰秘籍很粗大略,重启一下
tomcat 就足以了。

 

 

主题材料 陆:Read-only file system 错误与缓慢解决办法

解析:出现那一个标题标来头有大多样,可能是文件系统数据块出现不雷同导致的,也恐怕是磁盘故障导致的,主流
ext3/ext四文件系统都有很强的本身修复机制,对于简易的荒唐,文件系统一般都能够自动修复,当遭遇致命错误无法修复的时候,文件系统为了保障数据一致性和黑河,会暂时屏蔽文件系统的写操作,讲文件系统
变为只读,今儿出现了地点的 “read-only file system” 现象。

 

手工业修复文件系统错误的命令式
fsck,在修补文件系统前,最佳卸载文件系统所在的磁盘分区

 

# umount /www/data

Umount : /www/data: device is busy

 

唤醒无法卸载,大概是其一磁盘中还有文件对应的进程在运作,检查如下:

 

# fuser -m /dev/sdb1

/dev/sdb1: 8800

 

随之检查一下 8800 端口对应的什么样进度,

 

# ps -ef |grep 8800

 

反省后意识时 apache 未有关闭,甘休 apache

 

# /usr/local/apache2/bin/apachectl stop

# umount /www/data

# fsck -V -a /dev/sdb1

# mount /dev/sdb1 /www/data

 

———————————————————————————–华丽的分割线——————————————————————————————-

在收十linux磁盘的时候  查了一部分素材 故而规整一下
,留给今后供给的时候的采用

df  -h  查看磁盘占用情形

du -sh *  进入某些人文件夹后 
使用该命令能够看该公文夹下文件的攻下境况

 

唯独开掘使用rm -rf  文件名 
 删除文件后    磁盘空间并不曾成形    

询问资料发掘是   
通过rm恐怕文件管理器删除文件将会从文件系统的目录结构上革除链接(unlink).然则只要文件是被展开的(有1个进度正在使用),那么进度将还能读取该文件,磁盘空间也直接被占用。

粗略的知道  就是rm  删除的是引用 
若是引用对应的文书正在被接纳,那一个文件是不会真正的被去除掉的

lsof | grep deleted

网赌十大信誉的平台 4

 

 

 

———————————————————————————–华丽的分割线——————————————————————————————-

 

附带学习一下 lsof  (list opened files)

lsof全名list opened
files,也等于列举系统中已经被张开的文件。大家都清楚,linux情形中,任何事物都以文本,
设备是文本,目录是文本,乃至sockets也是文本。所以,用好lsof命令,对一般性的linux管理拾1分有帮扶。

 lsof -i : 端口号   
 能够用来查询端口时候被侵夺

lsof -i :8082

网赌十大信誉的平台 5

lsof 
文件  呈现开启文件/usr/local/tomcat_backend/logs/catalina.out的进程

lsof 
/usr/local/tomcat_backend/logs/catalina.out

网赌十大信誉的平台 6

 lsof – p 进程PID 

lsof – p 1498

 看经过号为14九八的长河张开了何等文件

网赌十大信誉的平台 7

 

Post Author: admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注