搞了一個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.xiguqu.com/read/263
下載地址:https://github.com/snooda/openvz_checker










Tags: , ,

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"


    這是引發困擾的三個參數。平時建議全部開啟,或開啟后兩個。
Tags: ,
    忘記之前從哪看過的一個文章說不要在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參數時仍會優化)
具體原因待深究
    今天編譯lua程序時發現總是報缺少dlopen和pow之類的,需要手動加-lm -dl才行。感覺有點奇異,按我的理解來說使用靜態庫是不需要考慮依賴的。仔細研究了下,發現很多誤區。
    首先用靜態庫編譯出的可執行文件是不考慮庫依賴的,但并不代表用靜態庫時也不需要考慮。靜態庫在編譯時是不檢查函數是否被實現的,也就是說只需要.h即可。
    其次,靜態庫和動態庫其實區別很大,靜態庫只是編譯出.o的一個打包的文件,而動態庫添加了鏈接信息。

    這樣的話靜態庫還有一個特性,就是在靜態庫中可以調用一些預留接口,而把這些接口留待以后實現。
Tags:
    今天想在我的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就能繼續使用了。
Tags: ,

BAE-百度開放云發布了

[| 不指定 2012/03/23 15:59]
    今天百度開發者大會上發布了百度開放云,包括了BAE(Baidu App Engine),云存儲以及各種服務,注冊了一個。

    http://snooda.duapp.com

    
Tags:
    突然想到一個問題,linux能否支持一個用戶有別名?試了試,發現一定程度上是可以的。

    創建一個用戶,然后把其uid,gid改的和一個已知用戶相同。然后登陸。

    發現w命令和last命令里面都顯示的是新用戶名,但建立的文件權限顯示還是老用戶名。權限跟老用戶相同。內部文件權限存儲應該是用的uid和gid,顯示時區passwd里面查出用戶名然后顯示的。

    無聊鼓搗,想想這個特性有什么用。。
    一個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的軟鏈即可
Tags: , ,
    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。
    搞定
    今天用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 /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為空。這個有待詳細考證
分頁: 9/33 第一頁 上頁 4 5 6 7 8 9 10 11 12 13 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
黄se大片全集,s8视频 情色视频,国产在线久久播放,天天鲁天一鲁,第一色色资源站 一色屋,3X免费视频 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>