OpenVZ VPS内存查看分析工具/超售检查脚本
[
|
2012/04/12 02:52]


搞了一个python脚本,用来查看OpenVZ VPS内存情况的,原始数据取自/proc/user_beancounters文件,脚本内做了一个数据简单的分析提取和可视化提高的工作,已经很晚了,先搞几个基本功能出来,增强功能以后再补。
用法: python vz_checker.py /proc/user_beancounters (需要root权限)
输出内容:
filename is:[user_beancounters]
Kernel Mem Info: used:[5.723M] max_used:[35.539M] limit:[2048.000M] fail_count:[0]
Mem already allocated Info: used:[17.621M] max_used:[33.074M] limit:[96.000M] fail_count:[0]
Ram actually used: used:[8.516M] max_used:[67.820M] limit:[96.000M] fail_count:[0]
Mem (Ram + swap) used: used:[9.848M] max_used:[13.219M] limit:[96.000M] fail_count:[0]
Kernel Mem Info:占用的内核内存大小,不可被swap,主要用来存放进程数据等。
Mem already allocated Info:已分配的内存大小,limit即为burst内存大小。
Ram actually used: 实际占用的物理内存大小。
Mem (Ram + swap) used: 占用的物理内存和swap大小。
如果 实际占用的物理内存 == 占用的物理内存和swap大小 那么恭喜你,你的vps里运行的程序都在内存中,主机超售不严重。
如果 实际占用的物理内存 < 占用的物理内存和swap大小 情况不妙,主机已经开始占用swap了,超售比较严重了。
另外我在测试过程中发现有一台vps实际占用物理内存大小显示比物理内存+swap总和还要大,现象很奇怪,查了一些资料没有关于这方面的说明,待后续调查。
脚本功能还比较粗糙,一些数据需要继续打磨,欢迎大家提意见~~
本文地址:http://www.snooda.com/read/263
下载地址:https://github.com/snooda/openvz_checker
用法: python vz_checker.py /proc/user_beancounters (需要root权限)
输出内容:
filename is:[user_beancounters]
Kernel Mem Info: used:[5.723M] max_used:[35.539M] limit:[2048.000M] fail_count:[0]
Mem already allocated Info: used:[17.621M] max_used:[33.074M] limit:[96.000M] fail_count:[0]
Ram actually used: used:[8.516M] max_used:[67.820M] limit:[96.000M] fail_count:[0]
Mem (Ram + swap) used: used:[9.848M] max_used:[13.219M] limit:[96.000M] fail_count:[0]
Kernel Mem Info:占用的内核内存大小,不可被swap,主要用来存放进程数据等。
Mem already allocated Info:已分配的内存大小,limit即为burst内存大小。
Ram actually used: 实际占用的物理内存大小。
Mem (Ram + swap) used: 占用的物理内存和swap大小。
如果 实际占用的物理内存 == 占用的物理内存和swap大小 那么恭喜你,你的vps里运行的程序都在内存中,主机超售不严重。
如果 实际占用的物理内存 < 占用的物理内存和swap大小 情况不妙,主机已经开始占用swap了,超售比较严重了。
另外我在测试过程中发现有一台vps实际占用物理内存大小显示比物理内存+swap总和还要大,现象很奇怪,查了一些资料没有关于这方面的说明,待后续调查。
脚本功能还比较粗糙,一些数据需要继续打磨,欢迎大家提意见~~
本文地址:http://www.snooda.com/read/263
下载地址:https://github.com/snooda/openvz_checker
etag生成规则的配置-lighttpd
[
|
2012/04/11 15:20]


最近两天调试一个程序的时候遇到一个问题,发现把一个文件两行对换位置的时候lighttpd不会载入新文件,增加或删除一行就会,考虑到lighttpd有stat cache,怀疑是不是不考虑mtime,只看inode,于是cp了一下,发现还是不行。没办法开gdb调试了一下,囧,原来生成的etag只用到了文件size这一个参数。怪不得。
# 生成ETag的时候是否考虑文件的inode
etag.use-inode = "enable"
# 生成ETag的时候是否考虑文件的mtime
etag.use-mtime = "enable"
# 生成ETag的时候是否考虑文件的size
etag.use-size = "enable"
这是引发困扰的三个参数。平时建议全部开启,或开启后两个。
# 生成ETag的时候是否考虑文件的inode
etag.use-inode = "enable"
# 生成ETag的时候是否考虑文件的mtime
etag.use-mtime = "enable"
# 生成ETag的时候是否考虑文件的size
etag.use-size = "enable"
这是引发困扰的三个参数。平时建议全部开启,或开启后两个。
c程序中变量在循环内部还是外部声明的问题
[
|
2012/04/09 15:40]


忘记之前从哪看过的一个文章说不要在for、while等循环内声明变量,因为每次都会重复分配空间,很慢。
今天发现一个模块把变量声明都放到while里面了,看了下代码没有发现必须声明在里面的原因,于是开始怀疑是不是声明在内外是差不多的。
于是测试了一下:
int main() {
int i = 0;
for(;i < 10000000; i++) {
int b;
b++;
}
return 1;
}
使用gcc 编译,把int b放在循环内外试了试,用time ./a.out查看执行时间,发现用时基本相同。
添加-O2优化选项,执行时间均缩减到之前的1/3,内外两种方式时间依然相同。
定义了一个struct实验了下,结果相同
也就是说栈上元素的操作不必纠结于变量声明于何处。
尝试了下堆上元素操作,在预料之内:时间差距巨大,因为重复分配释放内存。
所以对于栈上元素,声明放在循环里和循环外是一样的。堆上元素不同,需注意。
另,仍然需要注意一些计算操作需要放在循环外,比如求大小之类的,避免循环的每个周期重复计算。
原因猜测:1, cpu对栈操作有优化,速度非常快。
2,编译器的基本优化中会优化(gcc没有使用-O参数时仍会优化)
具体原因待深究
今天发现一个模块把变量声明都放到while里面了,看了下代码没有发现必须声明在里面的原因,于是开始怀疑是不是声明在内外是差不多的。
于是测试了一下:
引用
int main() {
int i = 0;
for(;i < 10000000; i++) {
int b;
b++;
}
return 1;
}
使用gcc 编译,把int b放在循环内外试了试,用time ./a.out查看执行时间,发现用时基本相同。
添加-O2优化选项,执行时间均缩减到之前的1/3,内外两种方式时间依然相同。
定义了一个struct实验了下,结果相同
也就是说栈上元素的操作不必纠结于变量声明于何处。
尝试了下堆上元素操作,在预料之内:时间差距巨大,因为重复分配释放内存。
所以对于栈上元素,声明放在循环里和循环外是一样的。堆上元素不同,需注意。
另,仍然需要注意一些计算操作需要放在循环外,比如求大小之类的,避免循环的每个周期重复计算。
原因猜测:1, cpu对栈操作有优化,速度非常快。
2,编译器的基本优化中会优化(gcc没有使用-O参数时仍会优化)
具体原因待深究
静态库和动态库编译链接时的依赖检查
[
|
2012/04/05 19:48]


今天编译lua程序时发现总是报缺少dlopen和pow之类的,需要手动加-lm -dl才行。感觉有点奇异,按我的理解来说使用静态库是不需要考虑依赖的。仔细研究了下,发现很多误区。
首先用静态库编译出的可执行文件是不考虑库依赖的,但并不代表用静态库时也不需要考虑。静态库在编译时是不检查函数是否被实现的,也就是说只需要.h即可。
其次,静态库和动态库其实区别很大,静态库只是编译出.o的一个打包的文件,而动态库添加了链接信息。
这样的话静态库还有一个特性,就是在静态库中可以调用一些预留接口,而把这些接口留待以后实现。
首先用静态库编译出的可执行文件是不考虑库依赖的,但并不代表用静态库时也不需要考虑。静态库在编译时是不检查函数是否被实现的,也就是说只需要.h即可。
其次,静态库和动态库其实区别很大,静态库只是编译出.o的一个打包的文件,而动态库添加了链接信息。
这样的话静态库还有一个特性,就是在静态库中可以调用一些预留接口,而把这些接口留待以后实现。
Ubuntu停止支持版本的源列表
[
|
2012/03/27 21:49]


今天想在我的ubuntu 9.10 Server开发用虚拟机上装个软件,发现apt各种404,以为是用的上海交大的教育网源把不在支持周期内的版本都删除了,于是换了官方源,发现还是不行。找了半天,发现过期版本的源地址都改变了,以9.10为例,改成:
deb http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse
对于其他版本则只需把karmic改成其他版本对应的代号即可。
这样超期ubuntu就能继续使用了。
deb http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-proposed main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-proposed main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse
对于其他版本则只需把karmic改成其他版本对应的代号即可。
这样超期ubuntu就能继续使用了。
BAE-百度开放云发布了
[
|
2012/03/23 15:59]


linux共用同uid的两个用户名(用户别名)
[
|
2012/03/14 23:38]


突然想到一个问题,linux能否支持一个用户有别名?试了试,发现一定程度上是可以的。
创建一个用户,然后把其uid,gid改的和一个已知用户相同。然后登陆。
发现w命令和last命令里面都显示的是新用户名,但建立的文件权限显示还是老用户名。权限跟老用户相同。内部文件权限存储应该是用的uid和gid,显示时区passwd里面查出用户名然后显示的。
无聊鼓捣,想想这个特性有什么用。。
创建一个用户,然后把其uid,gid改的和一个已知用户相同。然后登陆。
发现w命令和last命令里面都显示的是新用户名,但建立的文件权限显示还是老用户名。权限跟老用户相同。内部文件权限存储应该是用的uid和gid,显示时区passwd里面查出用户名然后显示的。
无聊鼓捣,想想这个特性有什么用。。
ubuntu下设置cron任务不生效原因(run-parts的bug)
[
|
2012/03/14 13:48]


一个ubuntu server某用户配了crontab任务后一直不执行。但系统的可以。刚开始以为是crontab -e后是否要重启cron服务,man了一下,不需要。然后加了一个每分钟1次的echo,执行正常,排除了cron的问题。
然后检查run-parts是否执行正常,执行run-parts --test cron.daily,发现是空结果。。。疑惑,上ubuntu的wiki一查,原来ubuntu版的run-parts有个bug,凡是带.sh后缀的不执行。。。这是什么鸟设计。并且06年就有这个bug了,还没修复。不靠谱。
解决方法是建个不带sh的软链即可
然后检查run-parts是否执行正常,执行run-parts --test cron.daily,发现是空结果。。。疑惑,上ubuntu的wiki一查,原来ubuntu版的run-parts有个bug,凡是带.sh后缀的不执行。。。这是什么鸟设计。并且06年就有这个bug了,还没修复。不靠谱。
解决方法是建个不带sh的软链即可
nginx强制使用https(http到https自动跳转
[
|
2012/03/11 10:45]


nginx对于使用http访问开启了https的站点会返回400.而浏览器输入网址默认是http的,每次都要去改成https很烦,于是考虑自动跳转的方法,刚开始用的$scheme变量判断,如果不是https则跳转。发现无效。
搜了一下,网上的一大抄们都表示rewrite (.*)https://$host/$1 permanent;可以,光目标地址没考虑端口号就让人感觉不是特别靠谱。试了下,果然不行。
想了下,应该是在一开始就被判断出异常,根本没有往后走的缘故。
这时找到一个方法:error_page 497 https://$host:$server_port$request_uri;
497表示使用http连接https的错误码。一旦出错让其跳转到https。
搞定
搜了一下,网上的一大抄们都表示rewrite (.*)https://$host/$1 permanent;可以,光目标地址没考虑端口号就让人感觉不是特别靠谱。试了下,果然不行。
想了下,应该是在一开始就被判断出异常,根本没有往后走的缘故。
这时找到一个方法:error_page 497 https://$host:$server_port$request_uri;
497表示使用http连接https的错误码。一旦出错让其跳转到https。
搞定
nginx做反向代理proxy_pass,proxy_redirect的使用
[
|
2012/03/11 01:39]


今天用nginx作为trac的反代,发现一个问题,就是登入登出跳转的时候是白页,看了下网页相应内容,发现相应的location是空的。查了一下发现是只单纯用了proxy_pass,没有使用proxy_redirect.
假设前端url是example.com。后端server域名是in.com,那么后端server在返回refresh或location的时候,host为in.com,显然这个信息直接返回给客户端是不行的,需要nginx做转换,这时可以设置:
proxy_redirect http://in.com /
nginx会将host及port部分替换成自身的server_name及listen port。不过这种配置对server_name有多个值的情况下支持不好。
我们可以用nginx内部变量来解决这一问题:
proxy_redirect http://in.com http://$host:$server_port
搞定
如果不设定的话,proxy_redirect默认是default属性,官网例子是这样介绍default的:
我试了下,location /{}规则时似乎不太正常,会导致location为空。这个有待详细考证
假设前端url是example.com。后端server域名是in.com,那么后端server在返回refresh或location的时候,host为in.com,显然这个信息直接返回给客户端是不行的,需要nginx做转换,这时可以设置:
proxy_redirect http://in.com /
nginx会将host及port部分替换成自身的server_name及listen port。不过这种配置对server_name有多个值的情况下支持不好。
我们可以用nginx内部变量来解决这一问题:
proxy_redirect http://in.com http://$host:$server_port
搞定
如果不设定的话,proxy_redirect默认是default属性,官网例子是这样介绍default的:
引用
location /one/ {
proxy_pass http://upstream:port/two/;
proxy_redirect default;
}
location /one/ {
proxy_pass http://upstream:port/two/;
proxy_redirect http://upstream:port/two/ /one/;
}
proxy_pass http://upstream:port/two/;
proxy_redirect default;
}
location /one/ {
proxy_pass http://upstream:port/two/;
proxy_redirect http://upstream:port/two/ /one/;
}
我试了下,location /{}规则时似乎不太正常,会导致location为空。这个有待详细考证