- PR -

apacheが遅い原因（libhttpd.ep？)

«前のページへ 1|2|3|4|5|6
投稿者投稿内容
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-06-16 15:20
引用:

angelさんの書き込み (2005-06-16 10:17) より:
・(3) 程度のswap I/Oでは、90% 以上もの CPU idle の原因となるとは、単純計算でも考えられない。つまり、CPU は本気で遊んでいる ( 元々やることが無い )。
・全I/Oを足しても 2MB/s 程度であり、これでディスクの性能をフルに使いきっているとは考え難い、つまり I/O にも余裕がある。

いや、そう言われても現に常時10〜20個のプロセスが「b」の欄に
出ているわけで...
ここで、bは "The number of processes in uninterruptible sleep." で、
Linuxのプロセス管理上、uninterruptible sleep とは I/O 待ちを
しているプロセスが入る状態です。
# 文字通りの意味は「割り込み不可」ということですが、
# 実質的にはI/O待ち。

ディスクの性能は... 長い話になるかも。
こんなプログラムを書いてみました。
コード:

#include <fcntl.h>

#include <sys/mman.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <unistd.h>



#define BUFMAX 4096



int

main(int argc, char **argv)

{

    char *buf;

    int dstf;

    int srcf;

    off_t offset = 0;

    off_t src_len;

    size_t len;

    struct stat src_stat;





    srcf = open(argv[1], O_RDONLY);

    fstat(srcf, &src_stat);

    src_len = src_stat.st_size;

    dstf = open(argv[2], O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR);



    while(src_len > 0){

        if(src_len > BUFMAX){

            len = BUFMAX;

        } else {

            len = (size_t)src_len;

        }



        buf = mmap(0, len, PROT_READ, MAP_PRIVATE, srcf, offset);

        write(dstf, buf, len);

        munmap(buf, len);

        fsync(dstf);

        src_len -= len;

        offset += len;

    }

    close(dstf);

    close(srcf);



    _exit(0);

}

第1引数のファイルを第2引数のファイルにコピーするものです。
エラーチェック等を一切行っていないので実用には耐えませんが、
ディスクの性能ってどんなもの？という感覚をつかむのには
使えると思います。
このプログラムを使って、Xeon 2.8GHz + 2.5インチ5400回転HDD
という構成のマシンで16MBのファイルをコピーすると1分半ほど
かかりました。CPU使用率はvmstatでみると1か0が表示されます。
大部分は1でした。
ハードウェア構成によって、かなり違ってくるものではありますが。
CPUが遅くてディスクが速いマシンだと、CPU使用率が何十%かに
なることもあるでしょう。

腰が抜けるほど遅いのはちょっと細工をしてあるからですが、
無意味に休んでいるわけではありません。スワップの際にも
これと似たようなことがあるはず。

<font size=-1>[ メッセージ編集済み 編集者: ぽんす 編集日時 2005-06-16 15:24 ]
</font>

[ メッセージ編集済み 編集者: ぽんす 編集日時 2005-06-16 15:35 ]
McLaren
ぬし
会議室デビュー日: 2002/01/15
投稿数: 784
お住まい・勤務地: 東京
投稿日時: 2005-06-16 16:03
　今度はスクリプトの中の　vacuum　をやめ、tarとsftpだけにして明日の朝を迎えてみようと思います。

　もしこれで早くなればtarとsftpは白で　postgreSQL　が問題であることがわかります。
素人戦術ですがやってみます。
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2005-06-16 16:19
こんにちは。
引用:
いや、そう言われても現に常時10〜20個のプロセスが「b」の欄に
出ているわけで...

これは、SQLクエリーの結果を待っている Apache がいるからでしょう。
これだけでは、スラッシングの問題なのか、Postgres が単にロックしているからかは区別できないと思います。

では、何故スラッシングの問題では無いと考えたかというと…、次のコマンド結果が出てきたからです。vmstat 10 でスラッシングの様子を取ったものです。
スラッシングしつつも、CPU に全く遊びが無いのが分かります。
引用:
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
3 3 120472 4056 368 1808 918 1558 2387 1560 183 198 96 4 0 0
3 4 120472 3716 420 2592 766 768 1310 770 168 142 98 2 0 0
3 3 120428 4016 368 3044 1037 402 1754 405 167 164 97 3 0 0
3 3 123436 3956 392 3992 909 883 2940 886 177 174 97 3 0 0
3 3 123824 3556 404 4908 974 404 3191 406 172 175 95 5 0 0
3 3 126016 3640 372 2952 890 429 3144 432 175 176 97 3 0 0
5 1 126908 3428 396 4936 860 716 3098 718 177 179 97 3 0 0
4 4 128236 3524 408 4532 774 265 2584 268 170 163 97 3 0 0
4 3 128236 3192 424 4328 917 819 3033 822 176 173 97 3 0 0
3 3 128236 3184 444 5008 984 126 3328 128 171 182 97 3 0 0
3 3 128312 3848 308 4692 922 646 2818 649 175 174 97 3 0 0
4 2 128312 3068 328 3516 923 424 3104 427 172 175 97 3 0 0

なお、環境は Fedora Core 2 を積んだ Windows ME時代のノートPC、Celeron550Mhz + 192MBメモリですから、McLarenさんのマシンよりかなり貧弱だと思います。
※ディスクがガリガリ言い放しで、気分のいいものでは無かったです…

ちなみに
引用:
ディスクの性能は... 長い話になるかも。

こちらに関しては、vmstat で目安はつけられるかと。巨大ファイルをただ読み込む/書き込むプロセスを実行して、vmstat で bi/bo を計測する、という方法で。
in もしくは out に専念した場合は、上記マシンで転送速度 10MB/s でした。
( 試しに職場のテスト用サーバ〜RAID無しSCSI〜で試したら 30MB/s を出していました )

以上、ご参考まで。
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-06-16 21:46
引用:

angelさんの書き込み (2005-06-16 16:19) より:
これは、SQLクエリーの結果を待っている Apache がいるからでしょう。

それならただのsleepです。uninterruptible sleep にはなりません。

引用:

スラッシングしつつも、CPU に全く遊びが無いのが分かります。

CPU使用率の97%がuserです。常時runqにプロセスが溜まってますし。
ユーザランドでひたすら処理が行われていますから、I/Oで
待っているわけではありません。
多数のプロセスがイベントの待ち合わせをポーリングでやってたり
するのかな？と一瞬思いましたが、CSの値がたいして大きくない
ところをみると、実行権を獲得した後すぐに自発的に手放す、
という動作ではないですね。ビジーウェイトでもしているのでわ。

引用:

こちらに関しては、vmstat で目安はつけられるかと。巨大ファイルをただ読み込む/書き込むプロセスを実行して、vmstat で bi/bo を計測する、という方法で。
in もしくは out に専念した場合は、上記マシンで転送速度 10MB/s でした。
( 試しに職場のテスト用サーバ〜RAID無しSCSI〜で試したら 30MB/s を出していました )

それは非同期でのシーケンシャルアクセスを測っているだけです。
問題はそこではありません。

さきに示したプログラムを使うと、通常のcpコマンドの50倍〜100倍
くらいの時間がかかるのがわかるはずなのですが...
# write on cache になっていると違いますが。
«前のページへ 1|2|3|4|5|6

スキルアップ／キャリアアップ（JOB@IT）