tonextone.com/note/

Last-modified: 2006-09-01 (金)

Copyright ©master_at_tonextone.com All rights reserved.

サーバ管理その1

Posted : 2005-12-13 04:00 / Category : [開発日誌/server]
tf-idf + bayesian-filter を試したいので、このサーバに chasen とか mecab とか入れる事にした。
で、かなり放置していたので、いろいろと整備した。
以下、メモ:

ports

packageはコンパイル済だが、ports は未コンパイル。その分、強力。
ports の実体はスケルトン。↓こんな感じ。
$ tree /usr/ports/graphics/ImageMagick/
/usr/ports/graphics/ImageMagick/
|-- Makefile
|-- distinfo
|-- files
|   |-- patch-Makefile.in
|   |-- patch-coders::jp2.c
|   `-- patch-configure
|-- pkg-descr
`-- pkg-plist

1 directory, 7 files

で、portupgrade っていう管理ユーティリティがあって便利。 linux の apt-get に相当する。
$ # ports を最新にする。
$ cvsup -g /usr/local/etc/ports-supfile;

$ # ports のデータベースを更新する。
$ portsdb --update --fetchindex;  # index は配布されているものを使う。
$ # または、
$ portsdb --update --updateindex; # index も構築する。
$ # または、
$ cd /usr/ports/; make index; # より確実らしい。

$ # ports の内容を表示する。
$ portversion --verbose;

$ # ports からインストールする。 (= cd /usr/ports/foo/bar; make install clean; )
$ portinstall --verbose foo/bar;

$ # ports からアップグレードする。
$ portupgrade --interactive foo/bar;

$ # ports の作業ファイルを削除する。distclean は 2 回指定する。
$ portsclean --workclean --distclean --distclean;

portinstall / portupgrade の再に現れる CUI で、大抵の config オプションを設定できる。
( ports で管理できる config オプションを 'knob' と呼ぶらしい。)

設定を変えて再インストールしたい場合とかは、
$ まず消す。
$ cd /usr/ports/foo/bar;
$ make deinstall;

$ # config の CUI を使えるかもしれない。
$ make config;

# # CUI 使えたら、
$ make reinstall;

# # CUI 使えなかったら、
$ # /usr/local/etc/pkgtools.conf の MAKE_ARGS にオプションを指定して、
$ portinstall --verbose foo/bar ;

今回は、先ず、いろいろアップグレードした。
$ portupgrade --interactive --all;
$ portsclean --workclean --distclean --distclean;

それから、無くて困っていた screen をインストールした。
FreeBSD Portsで cvs から 'screen' を検索して、それが /usr/ports の下にあることを確認して、
$ portinstall --verbose sysutils/screen;
$ portsclean --workclean --distclean --distclean;
簡単。

参考:
  1. アプリケーションのインストール - packages と ports
  2. portupgrade

src からインストール

APP(ApachePostgresqlPhp) は、 src で管理している。
これも、ついでにアップグレード。
(apache-1.3.34 も出ているが、これは Apache-SSL が出るまで待つことにした。)
  • postgresql-8.1.1
  • php-4.4.1
  • ZendOptimizer-2.6.0
  • php-json-ext-1.1.0
PostgreSQL の migration も、

[backup]
pg_dumpall -g > /home/postgres/backup/all.dmp;
pg_dump -b -F c foo > /home/postgres/backup/foo.dmp;
[restore]
psql -f all.dmp template1
pg_restore -d foo foo.dmp
で、無事完了。

参考:
  1. PHP 4.4.1. Release Announcement
  2. PostgreSQL 8.1.0 Documentation

ハマりどころ

最近 PHP のリリースが安定していないので、必要以上にビビっていたせいもあり、
実は結構ハマった。
  1. $ pkgdb -F;
    このサーバの構築に際して、上記 APP などを src で管理するために、
    VPS7 の標準構成から package/ports 版をアンインストールして頂いた。
    その際、PHP の拡張(php4-xxx) の package/ports が取り残されていたらしく、
    存在しない apache との依存関係を引きずっているようだった。
    とりあえず、
    $ pkgdb -F;
    
    したら問題無さそう。

  2. autoconf,automake,libtool の重複
    ひとしきり portupgrade/portsclean して、
    $ portversion --verbose;
    
    してみたら、autoconf,automake,libtool がバージョン違いで複数ある。
    不安に思いつつ、PHP を src からインストールする作業に取り掛かると、
    configure で warning が出て、make も失敗。
    *** Warning: inter-library dependencies are not known to be supported.
    *** All declared inter-library dependencies are being dropped.
    
    *** Warning: libtool could not satisfy all declared inter-library
    *** dependencies of module libphp4.  Therefore, libtool will create
    *** a static module, that should work as long as the dlopening
    *** application is linked with the -dlopen flag.
    
    package/ports のツリーがイカレたか?
    と思ったが、重複自体は問題ないらしい。
    package/ports 間の依存関係の連鎖を最小限にするために、
    被依存バージョンを残しつつ、別のバージョンもインストールする方針らしい。
    とりあえず、libtool とかが見つからないのはマズい気がしてタマらなかったので、
    $ ln -s /usr/local/bin/libtool15 /usr/local/bin/libtool
    
    とか、しばらくゴニョゴニョやってたら、なんかコンパイルできた。
    途中、不安が不安を呼んで、
    config.log の fail とか warn とかの多さにくじけそうになったが、
    もともと config.log は、そういうものらしいし、とりあえず動いてるのでヨシ。

ということで、PHP に不安が残るので、念のため php.ini を見直す予定。
本題の chasen, mecab を、src, ports のどっちで管理するかも要検討。

トラックバック

1: Shoulder.jp/サーバの性能管理 (06/01 11:53)
性能管理するのに大切なのが、「ハードウェア資源の利用率」を把握すること。特に重要なのが、 1.CPU 2.メモリ 3.ディスク 4.回線(ネットワーク)CPUの使用率を把握するには、「iostat」コマンドが使われる。「%user」がアプリケーションのCPU使用率を表し、「%sys」がカーネルのCPU使用率を表し、「%idle」がCPUの未使用率を表している。次にCPUの負荷を把握するには「uptime」コマンドが使われる。直近の1分、5分、15分の平均CPU負荷が表示される。(load average)CPUの負荷とは、CPUの割り当てを待っているプロセス数のことをいう。CPUの割り当てを待っているプロセスが多いということはそれだけCPUの負荷が高いということである。目安としては、CPU負荷が2以上が続くようであれば、何か対応が必要であり、常時6以上ならば、トラブルが発生していると判断してよい。ちなみに、CPU使用率が低いのに、CPUの負荷が高いという場合がある。それは、ディスクへの入出力待ちが多い場合であることが多い。その場合は、ディスクへの入出力を頻繁に行っているプロセスを夜の4時や5時といった時間へ移すとか、高性能ディスクに交換するとかの対応が必要になる。メモリの使用率を把握するには「free」コマンドが使われる。「total」はカーネル・メモリを除いた総メモリを表し、「used」は使用中のメモリ量を表し、「free」は空きメモリを表す。(単位はKB)ただし、「-/ buffers/cache」というのが、ディスクへのアクセスを高速化するためのバッファ分であるので、実際の空きメモリは、この項目のfreeを参照すればOK。メモリの性能を把握するには「vmstat」コマンドが使われる。「si」はスワップからメモリへ返されたメモリ量(KB/秒)「so」はメモリからスワップへ出されたメモリ量(KB/秒)であり、この数値をみれば、スワップが頻繁に発生しているか把握できる。スワップが使われるということは、メモリが足りないために、一時的にディスクを仮想メモリとして使っているということなので、メモリ不足だと判断できる。また、iostatやvmstatをみて、ディスク入出力の総量を把握できる。vmstatのbは、入出力処理完了待ち状態のプロセス数を表している。この値が大きいと、プロセスが要求する入出力処理をディスクがさばききれていないということがわかる。ただし、メモリ不足のためにスワップ領域が使われ、ディスクの入出力が増えているという可能性もある。ディスクを高性能にするといった対応をうつかどうかの判断基準になる。

ツッコミ

1: master (12/16 17:56)
その後、PECL の filter を入れようとしたら、make でこけた。
PHP 変わり過ぎ。
拡張で提供されるはずの関数の API 真似て、関数を自作しといて、
安定したら乗り換えるとか…無謀か。
2: master (12/17 14:19)
ちなみに、PRCL の chasen はコンパイルできたんだけど、
使うとセグメンテーションエラーで落ちる。
しかたないので、システム関数で呼んでおきます。
[ このエントリへはツッコミ出来ません ]