ssh连接远程主机执行脚本的环境变量问题

近日在使用ssh命令ssh user@remote ~/myscript.sh登陆到远程机器remote上执行脚本时,遇到一个奇怪的问题:

~/myscript.sh: line n: app: command not found

app是一个新安装的程序,安装路径明明已通过/etc/profile配置文件加到环境变量中,但这里为何会找不到?如果直接登陆机器remote并执行~/myscript.sh时,app程序可以找到并顺利执行。但为什么使用了ssh远程执行同样的脚本就出错了呢?两种方式执行脚本到底有何不同?如果你也心存疑问,请跟随我一起来展开分析。

目录


说明,本文所使用的机器是:SUSE Linux Enterprise。

问题定位

这看起来像是环境变量引起的问题,为了证实这一猜想,我在这条命令之前加了一句:which app,来查看app的安装路径。在remote本机上执行脚本时,它会打印出app正确的安装路径。但再次用ssh来执行时,却遇到下面的错误:

which: no app in (/usr/bin:/bin:/usr/sbin:/sbin)

这很奇怪,怎么括号中的环境变量没有了app程序的安装路径?不是已通过/etc/profile设置到PATH中了?再次在脚本中加入echo $PATH并以ssh执行,这才发现,环境变量仍是系统初始化时的结果:

/usr/bin:/bin:/usr/sbin:/sbin

这证明/etc/profile根本没有被调用。为什么?是ssh命令的问题么?

随后我又尝试了将上面的ssh分解成下面两步:

user@local > ssh user@remote    # 先远程登陆到remote上
user@remote> ~/myscript.sh      # 然后在返回的shell中执行脚本

结果竟然成功了。那么ssh以这两种方式执行的命令有何不同?带着这个问题去查询了man ssh

If command is specified, it is executed on the remote host instead of a login shell.

这说明在指定命令的情况下,命令会在远程主机上执行,返回结果后退出。而未指定时,ssh会直接返回一个登陆的shell。但到这里还是无法理解,直接在远程主机上执行和在返回的登陆shell中执行有什么区别?即使在远程主机上执行不也是通过shell来执行的么?难道是这两种方式使用的shell有什么不同?

暂时还没有头绪,但隐隐感到应该与shell有关。因为我通常使用的是bash,所以又去查询了man bash,才得到了答案。

bash的四种模式

在man page的INVOCATION一节讲述了bash的四种模式,bash会依据这四种模式而选择加载不同的配置文件,而且加载的顺序也有所不同。本文ssh问题的答案就存在于这几种模式当中,所以在我们揭开谜底之前先来分析这些模式。

interactive + login shell

第一种模式是交互式的登陆shell,这里面有两个概念需要解释:interactive和login:

login故名思义,即登陆,login shell是指用户以非图形化界面或者以ssh登陆到机器上时获得的第一个shell,简单些说就是需要输入用户名和密码的shell。因此通常不管以何种方式登陆机器后用户获得的第一个shell就是login shell。

interactive意为交互式,这也很好理解,interactive shell会有一个输入提示符,并且它的标准输入、输出和错误输出都会显示在控制台上。所以一般来说只要是需要用户交互的,即一个命令一个命令的输入的shell都是interactive shell。而如果无需用户交互,它便是non-interactive shell。通常来说如bash script.sh此类执行脚本的命令就会启动一个non-interactive shell,它不需要与用户进行交互,执行完后它便会退出创建的shell。

那么此模式最简单的两个例子为:

  • 用户直接登陆到机器获得的第一个shell
  • 用户使用ssh user@remote获得的shell

加载配置文件

这种模式下,shell首先加载/etc/profile,然后再尝试依次去加载下列三个配置文件之一,一旦找到其中一个便不再接着寻找

  • ~/.bash_profile
  • ~/.bash_login
  • ~/.profile

下面给出这个加载过程的伪代码:

execute /etc/profile
IF ~/.bash_profile exists THEN
    execute ~/.bash_profile
ELSE
    IF ~/.bash_login exist THEN
        execute ~/.bash_login
    ELSE
        IF ~/.profile exist THEN
            execute ~/.profile
        END IF
    END IF
END IF

为了验证这个过程,我们来做一些测试。首先设计每个配置文件的内容如下:

user@remote > cat /etc/profile
echo @ /etc/profile
user@remote > cat ~/.bash_profile
echo @ ~/.bash_profile
user@remote > cat ~/.bash_login
echo @ ~/.bash_login
user@remote > cat ~/.profile
echo @ ~/.profile

然后打开一个login shell,注意,为方便起见,这里使用bash -l命令,它会打开一个login shell,在man bash中可以看到此参数的解释:

-l Make bash act as if it had been invoked as a login shell

进入这个新的login shell,便会得到以下输出:

@ /etc/profile
@ /home/user/.bash_profile

果然与文档一致,bash首先会加载全局的配置文件/etc/profile,然后去查找~/.bash_profile,因为其已经存在,所以剩下的两个文件不再会被查找。

接下来移除~/.bash_profile,启动login shell得到结果如下:

@ /etc/profile
@ /home/user/.bash_login

因为没有了~/.bash_profile的屏蔽,所以~/.bash_login被加载,但最后一个~/.profile仍被忽略。

再次移除~/.bash_login,启动login shell的输出结果为:

@ /etc/profile
@ /home/user/.profile

~/.profile终于熬出头,得见天日。通过以上三个实验,配置文件的加载过程得到了验证,除去/etc/profile首先被加载外,其余三个文件的加载顺序为:~/.bash_profile~/.bash_login > ~/.profile,只要找到一个便终止查找。

前面说过,使用ssh也会得到一个login shell,所以如果在另外一台机器上运行ssh user@remote时,也会得到上面一样的结论。

配置文件的意义

那么,为什么bash要弄得这么复杂?每个配置文件存在的意义是什么?

/etc/profile很好理解,它是一个全局的配置文件。后面三个位于用户主目录中的配置文件都针对用户个人,也许你会问为什么要有这么多,只用一个~/.profile不好么?究竟每个文件有什么意义呢?这是个好问题。

Cameron Newham和Bill Rosenblatt在他们的著作《Learning the bash Shell, 2nd Edition》的59页解释了原因:

bash allows two synonyms for .bash_profile: .bash_login, derived from the C shell’s file named .login, and .profile, derived from the Bourne shell and Korn shell files named .profile. Only one of these three is read when you log in. If .bash_profile doesn’t exist in your home directory, then bash will look for .bash_login. If that doesn’t exist it will look for .profile.

One advantage of bash’s ability to look for either synonym is that you can retain your .profile if you have been using the Bourne shell. If you need to add bash-specific commands, you can put them in .bash_profile followed by the command source .profile. When you log in, all the bash-specific commands will be executed and bash will source .profile, executing the remaining commands. If you decide to switch to using the Bourne shell you don’t have to modify your existing files. A similar approach was intended for .bash_login and the C shell .login, but due to differences in the basic syntax of the shells, this is not a good idea.

原来一切都是为了兼容,这么设计是为了更好的应付在不同shell之间切换的场景。因为bash完全兼容Bourne shell,所以.bash_profile.profile可以很好的处理bash和Bourne shell之间的切换。但是由于C shell和bash之间的基本语法存在着差异,作者认为引入.bash_login并不是个好主意。所以由此我们可以得出这样的最佳实践:

  • 应该尽量杜绝使用.bash_login,如果已经创建,那么需要创建.bash_profile来屏蔽它被调用
  • .bash_profile适合放置bash的专属命令,可以在其最后读取.profile,如此一来,便可以很好的在Bourne shell和bash之间切换了

non-interactive + login shell

第二种模式的shell为non-interactive login shell,即非交互式的登陆shell,这种是不太常见的情况。一种创建此shell的方法为:bash -l script.sh,前面提到过-l参数是将shell作为一个login shell启动,而执行脚本又使它为non-interactive shell。

对于这种类型的shell,配置文件的加载与第一种完全一样,在此不再赘述。

interactive + non-login shell

第三种模式为交互式的非登陆shell,这种模式最常见的情况为在一个已有shell中运行bash,此时会打开一个交互式的shell,而因为不再需要登陆,因此不是login shell。

加载配置文件

对于此种情况,启动shell时会去查找并加载/etc/bash.bashrc~/.bashrc文件。

为了进行验证,与第一种模式一样,设计各配置文件内容如下:

user@remote > cat /etc/bash.bashrc
echo @ /etc/bash.bashrc
user@remote > cat ~/.bashrc
echo @ ~/.bashrc

然后我们启动一个交互式的非登陆shell,直接运行bash即可,可以得到以下结果:

@ /etc/bash.bashrc
@ /home/user/.bashrc

由此非常容易的验证了结论。

bashrc VS profile

从刚引入的两个配置文件的存放路径可以很容易的判断,第一个文件是全局性的,第二个文件属于当前用户。在前面的模式当中,已经出现了几种配置文件,多数是以profile命名的,那么为什么这里又增加两个文件呢?这样不会增加复杂度么?我们来看看此处的文件和前面模式中的文件的区别。

首先看第一种模式中的profile类型文件,它是某个用户唯一的用来设置全局环境变量的地方, 因为用户可以有多个shell比如bash, sh, zsh等, 但像环境变量这种其实只需要在统一的一个地方初始化就可以, 而这个地方就是profile,所以启动一个login shell会加载此文件,后面由此shell中启动的新shell进程如bash,sh,zsh等都可以由login shell中继承环境变量等配置。

接下来看bashrc,其后缀rc的意思为Run Commands,由名字可以推断出,此处存放bash需要运行的命令,但注意,这些命令一般只用于交互式的shell,通常在这里会设置交互所需要的所有信息,比如bash的补全、alias、颜色、提示符等等。

所以可以看出,引入多种配置文件完全是为了更好的管理配置,每个文件各司其职,只做好自己的事情。

non-interactive + non-login shell

最后一种模式为非交互非登陆的shell,创建这种shell典型有两种方式:

  • bash script.sh
  • ssh user@remote command

这两种都是创建一个shell,执行完脚本之后便退出,不再需要与用户交互。

加载配置文件

对于这种模式而言,它会去寻找环境变量BASH_ENV,将变量的值作为文件名进行查找,如果找到便加载它。

同样,我们对其进行验证。首先,测试该环境变量未定义时配置文件的加载情况,这里需要一个测试脚本:

user@remote > cat ~/script.sh
echo Hello World

然后运行bash script.sh,将得到以下结果:

Hello World

从输出结果可以得知,这个新启动的bash进程并没有加载前面提到的任何配置文件。接下来设置环境变量BASH_ENV

user@remote > export BASH_ENV=~/.bashrc

再次执行bash script.sh,结果为:

@ /home/user/.bashrc
Hello World

果然,~/.bashrc被加载,而它是由环境变量BASH_ENV设定的。

更为直观的示图

至此,四种模式下配置文件如何加载已经讲完,因为涉及的配置文件有些多,我们再以两个图来更为直观的进行描述:

第一张图来自这篇文章,bash的每种模式会读取其所在列的内容,首先执行A,然后是B,C。而B1,B2和B3表示只会执行第一个存在的文件:

+----------------+--------+-----------+---------------+
|                | login  |interactive|non-interactive|
|                |        |non-login  |non-login      |
+----------------+--------+-----------+---------------+
|/etc/profile    |   A    |           |               |
+----------------+--------+-----------+---------------+
|/etc/bash.bashrc|        |    A      |               |
+----------------+--------+-----------+---------------+
|~/.bashrc       |        |    B      |               |
+----------------+--------+-----------+---------------+
|~/.bash_profile |   B1   |           |               |
+----------------+--------+-----------+---------------+
|~/.bash_login   |   B2   |           |               |
+----------------+--------+-----------+---------------+
|~/.profile      |   B3   |           |               |
+----------------+--------+-----------+---------------+
|BASH_ENV        |        |           |       A       |
+----------------+--------+-----------+---------------+

上图只给出了三种模式,原因是第一种login实际上已经包含了两种,因为这两种模式下对配置文件的加载是一致的。

另外一篇文章给出了一个更直观的图:

上图的情况稍稍复杂一些,因为它使用了几个关于配置文件的参数:--login--rcfile--noprofile--norc,这些参数的引入会使配置文件的加载稍稍发生改变,不过总体来说,不影响我们前面的讨论,相信这张图不会给你带来更多的疑惑。

典型模式总结

为了更好的理清这几种模式,下面我们对一些典型的启动方式各属于什么模式进行一个总结:

  • 登陆机器后的第一个shell:login + interactive
  • 新启动一个shell进程,如运行bash:non-login + interactive
  • 执行脚本,如bash script.sh:non-login + non-interactive
  • 运行头部有如#!/usr/bin/env bash的可执行文件,如./executable:non-login + non-interactive
  • 通过ssh登陆到远程主机:login + interactive
  • 远程执行脚本,如ssh user@remote script.sh:non-login + non-interactive
  • 远程执行脚本,同时请求控制台,如ssh user@remote -t 'echo $PWD':non-login + interactive
  • 在图形化界面中打开terminal:
  • Linux上: non-login + interactive
  • Mac OS X上: login + interactive

相信你在理解了login和interactive的含义之后,应该会很容易对上面的启动方式进行归类。

再次尝试

在介绍完bash的这些模式之后,我们再回头来看文章开头的问题。ssh user@remote ~/myscript.sh属于哪一种模式?相信此时你可以非常轻松的回答出来:non-login + non-interactive。对于这种模式,bash会选择加载$BASH_ENV的值所对应的文件,所以为了让它加载/etc/profile,可以设定:

user@remote > export BASH_ENV=/etc/profile

然后执行上面的命令,但是很遗憾,发现错误依旧存在。这是怎么回事?别着急,这并不是我们前面的介绍出错了。仔细查看之后才发现脚本myscript.sh的第一行为#!/usr/bin/env sh,注意看,它和前面提到的#!/usr/bin/env bash不一样,可能就是这里出了问题。我们先尝试把它改成#!/usr/bin/env bash,再次执行,错误果然消失了,这与我们前面的分析结果一致。

第一行的这个语句有什么用?设置成sh和bash有什么区别?带着这些疑问,再来查看man bash

If the program is a file beginning with #!, the remainder of the first line specifies an interpreter for the program.

它表示这个文件的解释器,即用什么程序来打开此文件,就好比Windows上双击一个文件时会以什么程序打开一样。因为这里不是bash,而是sh,那么我们前面讨论的都不复有效了,真糟糕。我们来看看这个sh的路径:

user@remote > ll `which sh`
lrwxrwxrwx 1 root root 9 Apr 25  2014 /usr/bin/sh -> /bin/bash

原来sh只是bash的一个软链接,既然如此,BASH_ENV应该是有效的啊,为何此处无效?还是回到man bash,同样在INVOCATION一节的下部看到了这样的说明:

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interactive login shell, or a non-interactive shell with the –login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order. The –noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the –rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read.

简而言之,当bash以是sh命启动时,即我们此处的情况,bash会尽可能的模仿sh,所以配置文件的加载变成了下面这样:

  • interactive + login: 读取/etc/profile~/.profile
  • non-interactive + login: 同上
  • interactive + non-login: 读取ENV环境变量对应的文件
  • non-interactive + non-login: 不读取任何文件

这样便可以解释为什么出错了,因为这里属于non-interactive + non-login,所以bash不会读取任何文件,故而即使设置了BASH_ENV也不会起作用。所以为了解决问题,只需要把sh换成bash,再设置环境变量BASH_ENV即可。

另外,其实我们还可以设置参数到第一行的解释器中,如#!/bin/bash --login,如此一来,bash便会强制为login shell,所以/etc/profile也会被加载。相比上面那种方法,这种更为简单。

配置文件建议

回顾一下前面提到的所有配置文件,总共有以下几种:

  • /etc/profile
  • ~/.bash_profile
  • ~/.bash_login
  • ~/.profile
  • /etc/bash.bashrc
  • ~/.bashrc
  • $BASH_ENV
  • $ENV

不知你是否会有疑问,这么多的配置文件,究竟每个文件里面应该包含哪些配置,比如PATH应该在哪?提示符应该在哪配置?启动的程序应该在哪?等等。所以在文章的最后,我搜罗了一些最佳实践供各位参考。(这里只讨论属于用户个人的配置文件)

  • ~/.bash_profile:应该尽可能的简单,通常会在最后加载.profile.bashrc(注意顺序)
  • ~/.bash_login:在前面讨论过,别用它
  • ~/.profile:此文件用于login shell,所有你想在整个用户会话期间都有效的内容都应该放置于此,比如启动进程,环境变量等
  • ~/.bashrc:只放置与bash有关的命令,所有与交互有关的命令都应该出现在此,比如bash的补全、alias、颜色、提示符等等。特别注意:别在这里输出任何内容(我们前面只是为了演示,别学我哈)

写在结尾

至此,我们详细的讨论完了bash的几种工作模式,并且给出了配置文件内容的建议。通过这些模式的介绍,本文开始遇到的问题也很容易的得到了解决。以前虽然一直使用bash,但真的不清楚里面包含了如此多的内容。同时感受到Linux的文档的确做得非常细致,在完全不需要其它安装包的情况下,你就可以得到一个非常完善的开发环境,这也曾是Eric S. Raymond在其著作《UNIX编程艺术》中提到的:UNIX天生是一个非常完善的开发机器。本文几乎所有的内容你都可以通过阅读man page得到。最后,希望在这样一个被妖魔化的特殊日子里,这篇文章能够为你带去一丝帮助。

转载:http://feihu.me/blog/2014/env-problem-when-ssh-executing-command-on-remote/

FM算法(Factorization Machine)

因子分解机(Factorization Machine, FM)是由Steffen Rendle提出的一种基于矩阵分解的机器学习算法。目前,被广泛的应用于广告预估模型中,相比LR而言,效果强了不少。

一、FM背景

FM(Factorization Machine)主要目标是:解决数据稀疏的情况下,特征怎样组合的问题。以一个广告分类的问题为例,根据用户画像、广告位以及一些其他的特征,来预测用户是否会点击广告(二分类问题)。数据如下:

Clicked?是分类值,表明用户是否点击了此广告。1表示点击,0表示未点击。而Country,Day,Ad_type则是Categorical特征(类别特征),一般都是进行one-hot编码处理。

将上面的离散特征数据进行one-hot编码以后(假设Country,Day,Ad_type类别只有图中几种),如下图所示

显然可以看出,特征从最初的3个变成了现在的7个。而实际工程当中,由于有的Categorical特征维度会非常大(比如地区等),如果采用One-Hot编码,那么互联网公司的动辄上亿个特征的数据集就是这么来的了。

因式分解机是一种基于LR模型的高效的学习特征间相互关系,
对于因子分解机FM来说,最大的特点是对于稀疏的数据具有很好的学习能力。

二、FM优点

  • ① FMs allow parameter estimation under very sparse data where SVMs fails.(FM模型可以在非常稀疏的数据中进行合理的参数估计,而SVM做不到这点)
  • ② **FMs have linear complexity,**can be optimized in the primal and do not rely on support vectors like SVMs.
    在FM模型的复杂度是线性的,优化效果很好,而且不需要像SVM一样依赖于支持向量。)
  • ③ FMs are a general predictor that can work with any real valued feature vector. In contrast to this, other state-of-the-art factorization models work only on very restricted input data.
    FM是一个通用模型,它可以用于任何特征为实值的情况。而其他的因式分解模型只能用于一些输入数据比较固定的情况。)

三、FM模型

在一般的线性模型中,是各个特征独立考虑的,没有考虑到特征与特征之间的相互关系。但实际上,大量的特征之间是有关联的。最简单的以电商为例,一般女性用户看化妆品服装之类的广告比较多,而男性更青睐各种球类装备。那很明显,女性这个特征与化妆品类服装类商品有很大的关联性,男性这个特征与球类装备的关联性更为密切。如果我们能将这些有关联的特征找出来,显然是很有意义的。

一般的线性模型为(nn为特征维度):

y=ω0+i=1nωixiy=ω0+∑i=1nωixi

对于度为2的因子分解机(FM)的模型为:

y=ω0+i=1nωixi+i=1n1j=i+1n<vi,vj>xixjy=ω0+∑i=1nωixi+∑i=1n−1∑j=i+1n<vi,vj>xixj

其中,vRn,kv∈Rn,k<vi,vj><vi,vj>表示的是两个大小为kk的向量之间的点积

<vi,vj>=f=1kvi,fvj,f<vi,vj>=∑f=1kvi,f·vj,f

与线性模型相比,FM的模型就多了后面特征组合的部分。

四、FM求解

在基本线性回归模型的基础上引入交叉项,如下:

y=ω0+i=1nωixi+i=1n1j=i+1nωijxixjy=ω0+∑i=1nωixi+∑i=1n−1∑j=i+1nωijxixj

组合部分的特征相关参数共有n(n1)2n(n−1)2个。但是在数据很稀疏的情况下,满足xixi,xjxj都不为0的情况非常少,这样将导致ωijωij无法通过训练得出,无法对相应的参数进行估计。

这里,采用的方法是:对每一个特征分量xixi引入辅助向量vi=(vi1,vi2,...,vik)vi=(vi1,vi2,…,vik)。然后,利用vivTjvivjT对交叉项的系数ωijωij进行估计

ω^ij=vivTjω^ij=vivjT




这就对应了一种矩阵的分解。对kk值的限定,对FM的表达能力有一定的影响,下图为论文中说明的kk值选取原则。

这里写图片描述

下面,求<vi,vj><vi,vj>,这块的求解用到了
((a+b+c)2a2b2c2)/2((a+b+c)2−a2−b2−c2)/2求出交叉项。过程如下:

php 正则表达式匹配中文

GB2312汉字字母数字下划线正则表达式

preg_match(“/^[“.chr(0xa1).”-“.chr(0xff).”A-Za-z0-9_]+$/”, $str);

替换非中文和大小写字母数字及_

preg_replace(“/[^”.chr(0xa1).”-“.chr(0xff).”A-Za-z0-9_]/”, “”, $str);

UTF-8汉字字母数字下划线正则表达式

preg_match(“/^[\x{4e00}-\x{9fa5}A-Za-z0-9_]+$/u”, $str);

替换非中文和大小写字母数字及_

preg_match(“/[^\x{4e00}-\x{9fa5}A-Za-z0-9_]/u”, $str);

cpulimit 解决cpu使用率过高

安装

cpulimit 就是一款可以对 CPU 使用率进行控制的软件。

包安装

Centos:

yum install cpulimit

Debian/Ubuntu

apt-get install cpulimit
编译安装
cd  /tmp
wget  'http://downloads.sourceforge.net/cpulimit/cpulimit-1.1.tar.gz'
tar  cpulimit-1.1.tar.gz
cd cpulimit-1.1
make
cp cpulimit  /usr/local/sbin/
rm -rf cpulimit*
使用
说明
cpulimit -h
Usage: cpulimit [OPTIONS...] TARGET
   OPTIONS
      -l, --limit=N          percentage of cpu allowed from 0 to 100 (required)//cpu限制的百分比
      -v, --verbose          show control statistics//显示版本号
      -z, --lazy             exit if there is no target process, or if it dies//如果限制的进程不存在了,则退出。
      -i, --include-children limit also the children processes//包括子进程。
      -h, --help             display this help and exit //帮助,显示参数
   TARGET must be exactly one of these:
      -p, --pid=N            pid of the process (implies -z) //进程的pid
      -e, --exe=FILE         name of the executable program file or path name //可执行程序
      COMMAND [ARGS]         run this command and limit it (implies -z)

用法

限制firefox使用30% cpu 利用率

cpulimit -e firefox -l 30

限制进程号1313的程序使用30% cpu 利用率

cpulimit -p 1313 -l 30

限制绝对路径下该软件的 cpu 利用率

cpulimit -e /usr/local/nginx/sbin/nginx -l 50

注意事项

  1. -l后面限制的cpu使用量,要根据实际的核心数量而成倍减少。40%的限制生效在1核服务器中,如果是双核服务器,则应该限制到20%,四核服务器限制到10%以此类推。
  2. root用户可以限制所有的进程,普通用户只能限制己有权限管理的进程。

限制所有进程的 CPU 使用率

默认情况下 cpulimit 只能对已经存在的进程进行限制,但是设置此脚本为随机自启动即可(设置方法参看上面的脚本链接中),它会对所有进程(包括新建进程)进行监控并限制(3秒检测一次,CPU限制为75%)

这就可以防止因为 CPU 使用率过高而被 suspend 了!

#!/bin/bash
while true ; do
 id=`ps -ef | grep cpulimit | grep -v "grep" | awk '{print $10}' | tail -1`
 nid=`ps aux | awk '{ if ( $3 > 75 ) print $2 }' | head -1`
 if [ "${nid}" != "" ] && [ "${nid}" != "${id}" ] ; then
 cpulimit -p ${nid} -l 75 & 
 echo "[`date`] CpuLimiter run for ${nid} `ps -ef | grep ${nid} | awk '{print $8}' | head -1`" >> /root/cpulimit-log.log
 fi
 sleep 3
done

保存到 /root/cpulimit.sh,会自动生成日志文件 /root/cpulimit-log.log
然后将此降本添加开机启动。

设置为开机启动
 
修改 /etc/rc.local 在对应位置加入 /root/cpulimit.sh 再重启系统,就会全程限制各个进程的 CPU 使用了!

浮点运算问题

浮点数运算

你使用的语言并不烂,它能够做浮点数运算。计算机天生只能存储整数,因此它需要某种方法来表示小数。这种表示方式会带来某种程度的误差。这就是为什么往往 0.1 + 0.2 不等于 0.3。

为什么会这样?

实际上很简单。对于十进制数值系统(就是我们现实中使用的),它只能表示以进制数的质因子为分母的分数。10 的质因子有 2 和 5。因此 1/2、1/4、1/5、1/8和 1/10 都可以精确表示,因为这些分母只使用了10的质因子。相反,1/3、1/6 和 1/7 都是循环小数,因为它们的分母使用了质因子 3 或者 7。二进制下(进制数为2),只有一个质因子,即2。因此你只能精确表示分母质因子是2的分数。二进制中,1/2、1/4 和 1/8 都可以被精确表示。但是,1/5 或者 1/10 就变成了循环小数。所以,在十进制中能够精确表示的 0.1 与 0.2(1/10 与 1/5),到了计算机所使用的二进制数值系统中,就变成了循环小数。当你对这些循环小数进行数学运算时,并将二进制数据转换成人类可读的十进制数据时,会 对小数尾部进行截断处理。

下面是在不同的语言中,运行 0 .1 + 0.2 的输出结果:

语言 代码 结果
C #include<stdio.h>int main(int argc, char* argv) {printf(“%.17fn”, .1+.2);return 0;} 0.30000000000000004
C++ #include <iomanip>std::cout << setprecision(17) << 0.1 + 0.2 << std.endl; 0.30000000000000004
PHP echo .1 + .2; 0.3
注1:PHP 将 0.30000000000000004 格式化成字符串时,会把它缩短成 “0.3″。为了得到需要的浮点数结果,在 ini文件中调整精度设置:iniset(“precision”, 17)。
MySQL SELECT .1 + .2; 0.3
Postgres SELECT select 0.1::float + 0.2::float; 0.3
Delphi XE5 writeln(0.1 + 0.2); 3.00000000000000E-0001
Erlang io:format(“~w~n”, [0.1 + 0.2]). 0.30000000000000004
Elixir IO.puts(0.1 + 0.2) 0.30000000000000004
Ruby puts 0.1 + 0.2 And puts 1/10r + 2/10r 0.30000000000000004 And 3/10
注2:Ruby 2.1及以后版本在语法上支持有理数。对于老版本,请使用 Rational。Ruby还有一个专门处理小数的库: BigDecimal
Python 2 print(.1 + .2)float(decimal.Decimal(“.1″) + decimal.Decimal(“.2″))  .1 + .2 0.30.3

0.30000000000000004

注3:Python 2 中的 “print” 语句将 0.30000000000000004 转成一个字符串,并缩短成 “0.3″。为了达到需要的浮点数结果,使用 print(repr(.1 + .2))。在 Python 3中这是内置设定(见下面例子)。
Python 3 print(.1 + .2).1 + .2 0.300000000000000040.30000000000000004
Lua print(.1 + .2) print(string.format(“%0.17f”, 0.1 + 0.2)) 0.3 0.30000000000000004
JavaScript document.writeln(.1 + .2); 0.30000000000000004
Java System.out.println(.1 + .2);System.out.println(.1F + .2F); 0.300000000000000040.3
Julia .1 + .2 0.30000000000000004
注4:Julia 内置 支持有理数 ,并且还有一个内置的数据类型BigFloat,它支持任意精度 。要得到正确的运算结果,使用 1//10 + 2//10 会返回3//10。
Clojure (+ 0.1 0.2) 0.30000000000000004
注5:Clojure 支持任意精度的数据。 (+ 0.1M 0.2M) 返回 0.3M,而 (+ 1/10 2/10) 返回 3/10。
C# Console.WriteLine(“{0:R}”, .1 + .2); 0.30000000000000004
GHC (Haskell) 0.1 + 0.2 0.30000000000000004
注6:Haskell 支持有理数。要得到正确的运算结果,使用 (1 % 10) + (2 % 10) 返回 3 % 10。
Hugs (Haskell) 0.1 + 0.2 0.3
bc 0.1 + 0.2 0.3
Nim echo(0.1 + 0.2) 0.3
Gforth 0.1e 0.2e f+ f. 0.3
dc 0.1 0.2 + p .3
Racket (PLT Scheme) (+ .1 .2) And (+ 1/10 2/10) 0.30000000000000004 And 3/10
Rust extern crate num; use num::rational::Ratio; fn main() { println!(.1+.2); println!(“1/10 + 2/10 = {}”, Ratio::new(1, 10) + Ratio::new(2, 10)); } 0.30000000000000004 3/10
注7:Rust 中,使用 num crate 支持获得 有理数支持 。
Emacs Lisp (+ .1 .2) 0.30000000000000004
Turbo Pascal 7.0 writeln(0.1 + 0.2); 3.0000000000E-01
Common Lisp (+ .1 .2) And * (+ 1/10 2/10) 0.3 And 3/10
Go package main import “fmt” func main() { fmt.Println(.1 + .2) var a float64 = .1 var b float64 = .2 fmt.Println(a + b) fmt.Printf(“%.54fn”, .1 + .2) } 0.3 0.30000000000000004 0.299999999999999988897769753748434595763683319091796875
注8:Go语言的数字常数有任意精度
Objective-C 0.1 + 0.2; 0.300000012
OCaml 0.1 +. 0.2;; float = 0.300000000000000044
Powershell PS C:>0.1 + 0.2 0.3
Prolog (SWI-Prolog) ?- X is 0.1 + 0.2. X = 0.30000000000000004.
Perl 5 perl -E ‘say 0.1+0.2′ perl -e ‘printf q{%.17f}, 0.1+0.2′ 0.3 0.30000000000000004
Perl 6 perl6 -e ‘say 0.1+0.2′ perl6 -e ‘say sprintf(q{%.17f}, 0.1+0.2)’ perl6 -e ‘say 1/10+2/10′ 0.3 0.30000000000000000 0.3
注9:Perl 6 与 Perl 5 不同,默认使用有理数。因此 .1 被存储成类似这样 { 分子 => 1, 分母 => 10 }.
R print(.1+.2) print(.1+.2, digits=18) 0.3 0.300000000000000044
scala scala -e ‘println(0.1 + 0.2)’ And scala -e ‘println(0.1F + 0.2F)’ And scala -e ‘println(BigDecimal(“0.1″) + BigDecimal(“0.2″))’ 0.30000000000000004 And 0.3 And 0.3
Smalltalk 0.1 + 0.2. 0.30000000000000004
Swift 0.1 + 0.2 0.3
D import std.stdio; void main(string[] args) { writefln(“%.17f”, .1+.2); writefln(“%.17f”, .1f+.2f); writefln(“%.17f”, .1L+.2L); } 0.29999999999999999 0.30000001192092896 0.30000000000000000

转载:https://blog.csdn.net/ialexanderi/article/details/78936466