昏鸦

linux 运维（工作）

先来一些基础操作：

查看内存使用情况：（注意：1. 真实可用内存=free + cached 2.Swap的使用量如果较大，将严重影响应用的性能）

[@yd-80-133 ~] # free -m

total used free shared buffers cached

Mem: 96636 96400 235 0 522 75056

-/+ buffers /cache : 20821 75814

Swap: 8189 49 8139

查看磁盘使用情况：（如果你部署应用的磁盘使用率100%，你的应用就会变得不可用）

[@yd-81-74 ~] # df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 3.9G 977M 2.8G 26% /

/dev/sda6 1.4T 194G 1.1T 16% /opt

/dev/sda3 3.9G 2.4G 1.3G 66% /var

/dev/sda5 4.9G 3.0G 1.7G 64% /usr

tmpfs 12G 38M 12G 1% /dev/shm

10.13.81.44: /data/scribelog

21T 7.3T 13T 37% /opt/scribelog

查看系统概况：（top命令，可以看到很多信息。shift+p按cpu倒序,shift+m按内存倒序,1查看每个cpu繁忙程度）

top - 16:38:58 up 1019 days, 1:53, 28 users , load average: 0.77, 0.53, 0.56

Tasks: 325 total, 1 running, 324 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 98.6% id , 0.4%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 24659996k total, 22502624k used, 2157372k free , 118628k buffers

Swap: 4192956k total, 13344k used, 4179612k free , 324068k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

4033 root      18   0 1996m 975m  13m S 159.0  4.1   6:40.52 java

12336 root      18   0 2020m 1.2g  10m S  9.8  5.3   2860:34 java

3484 root      34  19     0    0    0 S  2.0  0.0  16159:29 kipmi0

7350 root 15 0 12868 1192 740 R 2.0 0.0 0:00.01 top

29636 smc       21   0 1092m 579m  14m S  2.0  2.4   1:20.44 java

30469 smc 21 0 1075m 708m 14m S 2.0 2.9 5:34.31 java

查看一个进程有多少线程：

[@yd-81-211 ~]$ ps -eLf | grep 24941 | wc -l

583

查看端口被哪个进程占用：（pid显示的就是那个进程）

[@yd-81-74 ~] # lsof -i tcp:8080

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

java 30469 smc 239u IPv4 64471973 TCP 10.13.81.74:webcache (LISTEN)

这个命令还可以查看文件被哪个进程占用

[@yd-81-130 nginx] # lsof | grep /data/log/scribelog

bash 4171 smc cwd DIR 0,23 16384 17797 /data/log/scribelog/user (10.13.81.44: /data/scribelog/ )

cat 4172 smc cwd DIR 0,23 16384 17797 /data/log/scribelog/user (10.13.81.44: /data/scribelog/ )

查看端口是否在监听：（最后一列显示哪个进程在监听这个端口）

[@yd-81-74 ~] # netstat -nalp | grep 8080

tcp        0      0 10.13.81.74:8080            0.0.0.0:*                   LISTEN      30469

/java

比较两个文件是否一样：

md5sum targetfile.txt > targetfile.md5

把targetfile.md5和targetfile.txt放到同一目录下进行校验：

md5sum -c targetfile.md5

下面是我们遇到过的情况，如有错误或需要补充的内容，请直接修改。

内存异常：
♦ java.lang.OutOfMemoryError: PermGen space
》resin热部署，重新加载jar包
》持久代设置得太小：-XX:PermSize=32m -XX:MaxPermSize=64ma
》常见于测试环境，线上基本不会出现这种问题。
♦ java.lang.OutOfMemoryError: Java heap space
》通常情况是从数据库或缓存加载了大量数据或者用户上传了大量文件。
》一般来说，由于会触发GC，只要代码不存在内存泄漏问题，线上很难出现这个异常。
》解决办法：重启、修复代码隐患
♦ java.lang.OutOfMemoryError: GC overhead limit exceeded
》这是因为使用并发收集算法进行GC，并且jvm启动参数中加了-XX:-UseGCOverheadLimit选项。
》目前只在hive的应用中遇到此情况，线上应用一般是CMS算法，不会出现这种情况。
》解决办法：增加heap size或者禁用上面那个选项。
♦ 很多时候内存异常并不会表现为异常，还没有达到这个临界点，你的系统就已经不可用了，这个时候需要主动去检查内存使用情况：
》查询GC状态，看一下jvm是否在进行GC操作（下面是一个示例，等下次碰到典型场景再贴一个）：

[@tc-152-92 ~]$ jstat -gcutil 16590 3000

S0 S1 E O P YGC YGCT FGC FGCT GCT

0.00 0.00 85.96 90.60 54.20 3336 0.781 38188 13952.038 13952.819

0.00 0.00 91.42 90.60 54.20 3336 0.781 38189 13952.565 13953.346

0.00 0.00 97.43 90.60 54.20 3336 0.781 38190 13952.960 13953.741

》查询java对象内存占用情况，看一下内存里的java对象是否合理（下面只是一个例子，等下次碰到内存占用异常的场景我再贴一个）。

[@zjm-110-88 ~]$ jmap -histo 2234 | head -10

num #instances #bytes class name

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

1: 3373503 2209452824 [C

2: 3334031 133361240 java.lang.String

3: 260 101301344 [Lcom.caucho.util.LruCache$CacheItem;

4: 326846 63127704 [Ljava.lang.Object;

5: 151274 50828064 com.wap.sohu.mobilepaper.model.NewsContent

6: 19812 45474976 [I

7: 110209 40197776 [B

8: 145988 30902344 [Ljava.util.HashMap$Entry;

9: 1846859 29549744 java.lang.Object

10: 270121 19448712 com.wap.sohu.mobilepaper.model.xml.Image

♦ 常用jvm参数：

-XX:MaxPermSize=512m -XX:PermSize=512m -Xss128k

-Xmx4096m -Xms4096m -Xmn1024m

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=85 -XX:+PrintGCDetails

-XX:MaxTenuringThreshold=30

CPU异常：
♦ 运行的线程多了，我们的应用里有不少线程去异步地执行任务，可能某个时间点或事件触发了大量线程同时去执行操作，导致cpu资源紧张。
♦ 程序运行的慢了，比如大量的计算操作，频繁地进行循环遍历。
♦ io操作多，比如频繁地打印日志，频繁地进行网络访问（mysql,memcache)。
♦ 过多的同步操作。比如synchronize
♦ 一般情况下，我们都是通过观察jvm的栈信息来识别程序的异常，主要看java.lang.Thread.State这个值，一般BLOCKED和RUNNABLE都需要重点关注。BLOCKED状态肯定是有锁，比如频繁的IO操作会导致资源BLOCK或者我们代码里显式的加锁。RUNNABLE状态理论上是正常的，但是很有可能是逻辑处理太慢（比如网络io或计算）或调用频繁导致一段代码执行时间较长，这个也需要优化。

[@yd-80-133 ~]$ jstack 1344

2013-06-08 16:15:42

Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode):

"pool-40-thread-5" prio=10 tid=0x000000005cea6800 nid=0x639c runnable [0x00000000493c5000]

java.lang.Thread.State: RUNNABLE

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream. read (SocketInputStream.java:129)

at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)

at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)

at com.mysql.jdbc.util.ReadAheadInputStream. read (ReadAheadInputStream.java:189)

- locked <0x000000074c115a08> (a com.mysql.jdbc.util.ReadAheadInputStream)

at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3014)

at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3467)

at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3456)

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3997)

at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2468)

at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2629)

at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2719)