在AWS的服务器上碰到了scp占用cpu100%的问题,通过kerberos认证。以下是收集到的信息,为后续解决作为参考。
[code]
#ps auxfww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1140 0.0 0.0 19712 996 ? Ss Apr27 3:06 crond
root 29599 0.0 0.0 44836 1344 ? S 10:10 0:00 \_ crond
root 29601 0.0 0.0 8700 984 ? Ss 10:10 0:00 | \_ /bin/sh -c cd /xxx;sh xx_log_hourly.sh 1>>/data/logs/hourly.log.`date +%y-%m-%d-%H`.log 2>>/data/logs/hourly.error.`date +%y-%m-%d-%H`.log
root 29602 0.0 0.0 8704 1056 ? S 10:10 0:00 | \_ sh xx_log_hourly.sh
root 29672 0.0 0.0 53900 1904 ? S 10:11 0:00 | \_ scp root 10.x.0.y /data/logs/stat.log.2015-11-04_09 /data/logs/stat.log.2015-11-04_09.12
root 29673 99.6 0.0 58416 3380 ? R 10:11 650:16 | \_ /usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -lroot 10.x.0.y scp -f /data/logs/stat.log.2015-11-04_09
root 4658 0.0 0.0 44836 1344 ? S 19:10 0:00 \_ crond
root 4662 0.0 0.0 8700 988 ? Ss 19:10 0:00 \_ /bin/sh -c cd /xx;sh xx_log_hourly.sh 1>>/data/logs/hourly.log.`date +%y-%m-%d-%H`.log 2>>/data/logs/hourly.error.`date +%y-%m-%d-%H`.log
root 4663 0.0 0.0 8708 1056 ? S 19:10 0:00 \_ sh xx_log_hourly.sh
root 4766 0.0 0.0 53900 1904 ? S 19:10 0:00 \_ scp root 10.x.0.z /data/logs/hours/access.log.2015-11-04-18 /data/logs/access.log.2015-11-04-18
root 4767 99.6 0.0 58412 3336 ? R 19:10 113:23 \_ /usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -lroot 10.x.0.z scp -f /data/logs/hours/access.log.2015-11-04-18
[/code]
简单总结:
这两个操作是完全相对的脚本,对应不用的服务器,平时正常,分别在10:10时与Y服务器scp时有问题,另一个是19:10时对Z有问题。

- 阅读剩余部分 -

之前碰到过一次,需要查一批正在运行的脚本的调用关系,用ps输出树状结果以方便查看。
当时没记,备忘一下。实际上用ps --help后,找forest字样就是了,f应该是forest的简写。
树状结果的参数是f,比如,用ps auxf执行的结果,其中有部分会是类似这个样子的
[code]
root 6788 0.0 0.0 64644 1236 ? Ss Feb04 0:00 /usr/sbin/sshd
root 6135 0.0 0.0 98860 4528 ? Ss 14:27 0:00 \_ sshd: root@pts/1
root 6139 0.0 0.0 108636 1824 pts/1 Ss 14:27 0:00 | \_ -bash
root 6185 0.0 0.0 61168 4312 pts/1 S+ 14:28 0:00 | \_ ssh aa.bb.cc.dd
root 6715 0.0 0.0 98860 4492 ? Ss 15:14 0:00 \_ sshd: root@pts/3
root 6719 0.0 0.0 108636 1824 pts/3 Ss 15:14 0:00 \_ -bash
root 6748 0.0 0.0 108448 1040 pts/3 R+ 15:14 0:00 \_ ps auxf
[/code]

ps结果只显示一行,超长自动截断的问题,也可以通过参数ww来控制,ps --help中找到wide output就是了。

目前的做法:
每个功能点独立实现,有重发标志位及App本地的唯一标识。平台中的功能点发现重发标志后,根据唯一标识确认是否已经成功。来确定返回结果。

可以的做法:
平台统一增加重发标志参数,唯一标识用现有的callId。平台中设定哪些接口需防重发,及重发的有效时间,收到非重发请求时,根据用户及唯一标识缓存结果到有效时间,重发命中时直接返回。

听到了一句话:
[code]
自由不是你想做什么就能做什么,而是你不想做什么就可以不做什么。
[/code]

觉得很有道理,查了一下出处,好像解释的不太对:
出自于德国哲学家康德的《道德形而上学原理》,判断一个行为是不是道德的要符合三个条件之一:自律性公式。
原意是:所谓自由,不是随心所欲,而是自我主宰。
把“自我主宰”解释成:“不想做什么就可以不做什么”,显然片面且极端,经不起推敲。

到底什么是自由呢?
[code]
在西方哲学里,叫:美。
在中国哲学里,叫:道。
在印度哲学里,叫:空(佛教)。
[/code]

先看代码
[code]
public E take() throws InterruptedException {
return takeFirst();
}

public E takeFirst() throws InterruptedException {
ReentrantLock localReentrantLock = this.lock;
localReentrantLock.lock();
try {
Object localObject1;
while ((localObject1 = unlinkFirst()) == null)
this.notEmpty.await();
Object localObject2 = localObject1;
return localObject2;
} finally {
localReentrantLock.unlock();
}
}
[/code]
问题1:当队列非空时,不会感知到被中断,也不会抛InterruptedException,除非队列空了。
有一种解释是当中断发生时,需处理完队列后才允许产生中断异常。按这种思路,生产者线程也要先检测中断,确保不会生产了,是否为空才有意义,实际上生产者并没有检验。
而带有超时时间的poll和offer操作,都会提前检查中断,用的是lockInterruptibly。
个人感觉:只要是会触发中断异常的地方,就应该用lockInterruptibly,不容易产生误解。

问题2:localObject2的存在是否有意义。
运行期经过复写传播(Copy Propagation)和无用代码消除(Dead Code Elimination)后,localObject2会直接消失,变成return localObject1;
作者这么干的意义是什么呢?感觉毫无意义。欢迎拍砖~

先贴代码,看运行结果:
[code]
Class<?> cache = Integer.class.getDeclaredClasses()[0];
Field c = cache.getDeclaredField("cache");
c.setAccessible(true);
Integer[] array = (Integer[]) c.get(cache);
array[130] = array[131];

Integer x = 2;
System.out.println(x + 2);
[/code]
运行结果实际上是5,其它地方如果出现Integer类型的数值,2就会变成3。

- 阅读剩余部分 -