タグ:"server" で記事を検索

vimの環境設定などなど
2009.02.13 01:35 | server, vi, vim, コマンド

vimを便利に使おうと思い始めたので、とりあえず設定ファイルを作ってみることにした。

困り事1
CentOS上で日本語で書かれているファイルを開くと文字化けしまくりで日本語が読めない

困り事2
行番号表示する度に set number は面倒


$ vi ~/.vimrc
:set number
:set encoding=utf-8
:set fileencodings=iso-2022-jp,euc-jp,sjis,utf8


あーこういうやりかたあったのねー
日本語も問題なく表示できましたー

Xenをインストール
2009.02.03 04:00 | server, xen

Xenのインストールメモ

xenblkモジュールを読み込むように設定
# vi /etc/modprobe.conf
alias scsi_hostadapter xenblk


xenカーネルで起動するように設定
# vi /etc/sysconfig/kernel
DEFAULTKERNEL=kernel-xen


xen本体とxenカーネルをインストール
# yum -y install xen kernel-xen


楽するためにスクリプト作ってみました。

#!/bin/bash

# Add xenblk module
echo alias scsi_hostadapter xenblk >> /etc/modprobe.conf

# Change default kernel
mv /etc/sysconfig/kernel /etc/sysconfig/kernel.org
sed -e "s/DEFAULTKERNEL/#DEFAULTKERNEL/g" /etc/sysconfig/kernel.org > /etc/sysconfig/kernel
echo "DEFAULTKERNEL=kernel-xen" >> /etc/sysconfig/kernel

# Install Xen and Xen kernel
yum -y install xen kernel-xen

PHPのソースコードをRPMで配布したい
2008.12.22 23:50 | server, rpmbuild

先日(2ヶ月くらい前だけど)、友人に「PHPのプログラムをRPMで簡単インストールとかってできないのかねー?」って聞かれて、できると思うよーと答えるだけだったけども、必要にかられたため書いてみました。

実際この配布方法がいいのかどうかわからないけど(ライセンスなどなど)、とりあえず作り方だけならいいと思うので書いておきます。

必要なもの
rpmbuild

rpmbuildがインストールされていれば、/usr/src/redhat というディレクトリの中に以下のディレクトリ群があるはず。
・ BUILD (RPM生成中のテンポラリファイルが入っているディレクトリみたいなもの)
・ RPMS (できあがったRPMが入っているディレクトリ)
・ SOURCES (RPMパッケージに含めるファイルなどを入れておくディレクトリ)
・ SPECS (RPM生成のための設定ファイルのようなものを入れておくディレクトリ)
・ SRPMS (できあがったSRPMが入っているディレクトリ)


まずは SPEC ファイルを作ることからはじまる。

# cd /usr/src/redhat/SPECS
# vi test.spec

# ウェブディレクトリを定義
%define webroot /var/www/html

# アプリケーション名
Name: test
# アプリケーションの説明
Summary: test package
# バージョン
Version: 1.0
# リリース番号
Release: 1
# ライセンス
License: BSD
# ソースコードの入手場所
Source: %{name}-%{version}-%{release}.tar.gz
# パッケージグループ
Group: Application/Internet
# ビルドルート
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}
# 対象アーキテクチャ(PHPのプログラムだから noarch でいいだろう)
BuildArch: noarch
# このパッケージを使うのに必要な他のパッケージ
Requires: httpd, php


%description
ここにこのパッケージの説明を書いておく。


%prep
# 作業ディレクトリを削除しておく(BuildRootで指定したディレクトリが削除される)
rm -rf $RPM_BUILD_ROOT


# Sourceで指定したファイルを$RPM_BUILD_ROOTに展開する
%setup -qn %{name}-%{version}-%{release}


%build
# ビルドは必要ないのでここでは指定しない


%install
# インストール先のディレクトリを作成する
install -d $RPM_BUILD_ROOT%{webroot}/%{name}
# 展開したファイル群をコピーする
cp -r * $RPM_BUILD_ROOT%{webroot}/%{name}/
# キャッシュディレクトリを作ってみる
mkdir -p $RPM_BUILD_ROOT%{webroot}/cache
# キャッシュディレクトリパーミッション変更(これは %filesセクションでも可能)
chmod 777 $RPM_BUILD_ROOT%{webroot}/cache


%clean
# 作業ディレクトリを削除する
rm -rf $RPM_BUILD_ROOT


%files
# デフォルトのパーミッションや、所有者情報をセット
%defattr(-,root,root)
# コピーしたファイル群をインストール対象として追加(ディレクトリごと追加)
%{webroot}/%{name}


%changelog
* 変更日時 パッケージ作成者の名前 メールアドレス
ログメッセージ


とこんな感じで作る。

続いて tar ball を用意する。これは、SPECのSource欄で定義したもの。
SOURCESディレクトリの中にソースコードを入れておいて tar ball を作る。
ここでのディレクトリ名は test-1.0-1 を使用する。

# cd /usr/src/redhat/SOURCES
# tar zcvf test-1.0-1.tar.gz test-1.0-1

SVNからチェックアウトした場合は、.svnとか.projectとかをexcludeしてあげる。
(小生はeclipse使っているので .project がコミットされている)

# tar zcvf test-1.0-1.tar.gz --exclude .svn --exclude .project test-1.0-1


これで、ソースコードの準備ができた。

続いて、RPMを実際に作ってみる。

# cd /usr/src/redhat/SPECS

%prepまでを実行して検証できる
# rpmbuild -bp test.spec

%installまでを実行して検証できる
# rpmbuild -bi test.spec

%filesの検証ができる
# rpmbuild -bl test.spec

通常のビルドはこれ
# rpmbuild -bb test.spec

ソースRPMは特に必要はないと思う(ソースがtarで固まっているだけだから)
# rpmbuild -ba test.spec

これでいい感じに配布できると思われます。

業務用ではエラい役に立ちそうなネタでした。

Apacheをチューニング(Prefork)
2008.10.17 04:20 | server, apache

前回の続きです。

http://httpd.apache.org/docs/2.0/ja/mod/prefork.html
スレッドを使わず、先行して fork を行なう ウェブサーバを実装しています。 スレッドセーフでないライブラリとの互換性をとるために、 スレッドを避ける必要のあるサイトでは、このモジュールの使用が適切でしょう。

本家のウェブにこんなことが書いてありますが、僕は基本的にスレッドセーフでないPHPを使用しているため、preforkの使用をしています。PHPを使用しない場合はworkerを使用した方がたぶんいいと思いますが、使用したことがないのでここでは説明をさけます。。

StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 256
MaxClients 256
MaxRequestPerChild 10000

StartServersはサーバが起動したときに生成される子プロセスの数です。
負荷があがると自動的に数は増えていくので特に設定する必要はないと思われます。

MinSpareServers/MaxSpareServersはアイドル状態の子プロセス数を制御するパラメータです。
MinSpareServersよりもアイドル状態の子プロセスが少なくなると親プロセスが新しい子プロセスを生成します。新しく生成されるのは1秒に一度のため、高負荷のウェブサーバの場合応答が間に合わなくなる可能性があります。
このパラメータはチューニングしがいのある部分で、高負荷サーバでは応答速度に変化が見られる場合がありますが、そこまで高負荷でない場合は触る必要のない項目であります。

ServerLimit/MaxClientsは、リクエストに応答するための子プロセスの最大数です。
preforkの場合は、この値が同時アクセス数の値になるので、チューニングができる項目になります。
デフォルト値は256となっていますが、メモリ容量とのからみもあるので安易に増やすとPHPが実行できないなどの状況に陥ってしまいます。
例えば、2Gのメモリを搭載しているサーバで、PHPのmemory_limitに32Mを当てている場合、OSに使用するメモリを考えて1.5Gをウェブサーバで使用させるとすると・・・
2G / 32M = 46プロセス
になります。256プロセスデフォルトのままで運用してしまうと、同時アクセスがマックスになるとPHPがメモリエラーをはいてしまう可能性もある感じになります。
(PHPがマックスまでメモリを使用していればの話ですが)
ServerLimit/MaxClientsの値と、memory_limitは連動してくるお話になるので、両方を注意しながら地道にチューニングしていくと、同時アクセス数も調整できて、サーバがどのくらいさばけるのかが把握できるのでとても幸せ気分になれます。

最後にMaxRequestPerChildですが、これは子プロセスが再起動する頻度を設定する項目です。
プロセス再起動には時間がかかるので、再起動の間に大量アクセスがきていたら大変です。
が、メモリリークがおこってしまった場合などの対処用に設定をしておいたほうがよい項目です。
デフォルトでは10000が設定されていますが、10000回プロセスにアクセスがされたらプロセスの再起動を行う設定になっています。
あまり設定する必要のない項目ではありますが、error_logでエラーが頻発しているようだったらこの値を変更してみて挙動をウォッチする手もあると思います。


ざっくりと書いてきましたが、ほとんど本家ウェブサイトに書いてあることの転載なので、詳しくはそちらを参照した方がいいかもしれません。
チューニングは実行するウェブアプリケーションによっても違ってきますし、搭載しているメモリ容量などにも関連してくるので、教科書通りにいかないというのが経験上いえることです。
ちょっとずつ値を変更して最適なパラメータを見つけるのも楽しみの一つであるので、地道にやるのが一番いいのかなーと。


次回は・・・なにをやりましょう。。。

Apacheをチューニング(KeepAlive)
2008.10.15 01:15 | server, apache

ウェブサーバのレスポンスが遅くなったときにどのようにしたら早くなるのか。
一時期かなり悩み悩み、色々試行錯誤をしたのですが、メモ程度にやったことを書いておこうと思います。
遅くなっているウェブアプリケーションによって、設定方法も変える必要がかなりあって、あまりにもパターンがありすぎる感があるけども、何かの参考になれば・・・

設定対象のファイルは httpd.conf になります。

今日は KeepAlive の設定について。
ウェブサーバは基本的には1ファイルごとにセッションを接続ー切断を繰り返して、処理を行うものですが、この設定を加えてあげることでセッションを切断せずに通信できるようになります。

KeepAlive On
MaxKeepAliveRequests 30
KeepAliveTimeout 5

上記設定では、30リクエストごとにいったん切断を行い、30リクエストに満たなくても5秒間でセッションを切断する設定になっています。
注意すべき点としては、MaxKeepAliveRequestsをきちんと設定してあげることです。
ページの表示が完了するまでに、画像ファイルやCSSなどのファイルも含めて、そのサーバから何ファイル出力されるのかを把握する必要があります。一番多いリクエストに合わせて、少々余裕を持たせた数字にしておくのがいいと思います。
セッションを保持したままにするということは、その間はプロセスが占有されているままになるということなので、これもまた注意が必要です。なので、KeepAliveTimeoutを設定して、リクエストが来なくなったらリリースしてあげる仕組みになっています。

ブログパーツのリクエストが多い場合や、携帯サイトの場合はあまりこの設定は意味がないかもしれません。ブログパーツはswfファイルの読み込みのみだったりするので、1リクエストで終了してしまう方が多いと思いますし、携帯は回線が遅いので、一回ずつ処理をしたほうが、プロセスをガメる量が減らせますし。

実環境でテストしながらでないとなんともいえない部分なので、参考程度ということで。


次回は prefork とか行ってみようと思います。

PHPにImageMagicのモジュールを組み込む
2008.07.29 00:25 | server, php, imagick

PHPでの画像処理系はGDをよく使っていたんだけども、大きい画像になるとメモリ消費量が激しかったりしてエラーが発生してしまうことが多々。
で、色々調べていたらImageMagicがPHPで使えることがわかったのでちょっと導入してみました。
Pearからインストールで普通に使えるみたい。

うちのサーバ環境はこんな感じ
CentOS 5.1
PHP 5.2.6
# yum -y install ImageMagick ImageMagick-devel
# yum -y install php-devel php-pear
# pecl install imagick

でphp.iniに追記

# vi /etc/php.iniextension=imagick.so


これだけでとりあえず使えるようにはなるみたい。

今度使ってみます。

サーバ負荷やトラフィックの監視ツール
2008.03.15 02:55 | server, munin

サーバ負荷とかトラフィックの監視ツールの王道はMRTGですが、設定が相当面倒だったり、サーバ移行したときに手間がかかったりととても面倒です。

で、GIGAZINEに掲載されていたMuninなるものをインストールしてみることにしました。
GIGAZINEによると相当設定が簡単だそうな。

以下のURLにRPMパッケージが用意されていますが、Perlの各種モジュールが必要だったりとインストールに手間がかかるのが嫌だったので、RPMをダウンロードして、yumのリポジトリにつっこみました。
sourceforge.net

[munin-1.2.5-1rhel4.noarch.rpm] と [munin-node-1.2.5-1rhel4.noarch.rpm ] の二つをダウンロードしたら、レポジトリに放り込んで createrepo をしてあげれば完了です。

あとは# yum -y install munin-* これでインストール完了

Perlのパッケージの中に dag レポジトリの設定が必要なものがあるので yum の設定に加えておいてあげましょう。
yum は依存関係すべてを自動でインストールしてくれるからとてもとても便利ですわ。


munin の構成は、munin-node と munin の二つからなっています。
munin はノードから情報を収集して、HTMLに吐き出す役目で、munin-node はサーバの情報を収集する役目。

複数サーバに node を入れておいて、一台のホストマシンで HTML を生成するなんていう使い方もできる優れものです。



ということで設定
まずはノードからですが、一台で munin と munin-node を兼ねる場合はまったく設定なしです。
複数サーバで構築する場合は、以下のように ホストマシンのIPアドレスからのアクセスを許可してあげるだけです。

ホストマシン: 192.168.0.1
ノードマシン: 192.168.0.2
# vi /etc/munin/munin-node.conf
-----------------------------------------
allow ^192\.168\.0\.1$
-----------------------------------------次にホストのほうの設定
ホストマシン側では、HTMLの吐き出しディレクトリの設定と、収集するノードの情報を記述してあげる。
# vi /etc/munin/munin.conf
-----------------------------------------
# html ディレクトリの設定
htmldir /var/www/html/munin

# ノード情報
[node]
address 192.168.0.2
use_node_name yes
-----------------------------------------

たったこれだけでした・・・
ノード情報を、どんどん増やしていけばどんどん出力されるノードが増えていきます。

ほとんどデフォルト設定のまんまでいけてしまうようです。



設定が終わったら# /etc/init.d/munin-node restart
これで設定が反映されて、5分に一回HTMLが更新されます。


なんて素敵なツールでしょうか・・・

yumでdagレポジトリを使う
2008.03.05 16:05 | server, yum

CentBaseに書かれているレポジトリだけではどうも物足りなくなってきたのでdagレポジトリを導入する事にしました。

dagはとにかく色々なツールが用意されていて、yum を多用している僕としてはそれはとても便利なレポジトリです。

うちではCentOSを利用しているのでRedHatのレポジトリをそのまま利用できるのがありがたい。
ということで設定
# vi /etc/yum.repos.d/dag.repo
-------------------------------------------------
[dag]
name=Dag RPM Repository for Redhat EL4
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
gpgkey=http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt
-------------------------------------------------
dagのレポジトリに入っているツール類のインストールなんかも紹介できたらいいなぁとか思ってます。

とりあえず今日はインストールのみ!

MySQLのクエリログをとる
2008.02.07 02:20 | server, mysql

MySQLのバイナリログは大変便利だが、やっぱり生のSQL文のほうがデバッグのときとかに便利です。

他のWebサイトでは、MySQLの起動オプションに --log をつける方法を紹介しているケースが多いが、my.cnfに記述方法もある。
my.cnfに記述するほうがお手軽なのでサンプルを以下に書いておきます。
# vi my.cnf
-------------------------------------
[mysqld]
log=/var/lib/mysql/query.log
-------------------------------------
これだけです。

手軽にできるのでデバッグ用途には相当使えます。

ちなみに、log オプションで記録できるログは SELECT文のみです。
ログの量がものすごいことになるので、デバッグ用途にしか使わないほうがいいです。

YUM レポジトリの作り方
2007.01.20 23:45 | server, yum

yum は依存関係含めてほとんどオートでインストールをしてくれる、とてもとても便利なソフト。

自分でレポジトリとか作れたら色々遊べるかなーと思ってちょっとテスト。


【環境】
CentOS 4.4
Apache 2.0.52

まずは、yumレポジトリを作るアプリのインストール
# yum -y install createrepo
適当な場所に公開用のディレクトリを作る
# mkdir -p /var/www/repos
自分のレポジトリ用のRPMを作ったディレクトリに入れて、レポジトリ作成コマンド発行
# createrepo /var/www/repos

たったこれだけでした。

RPMは、ソースから作成する際に依存関係を指定できるようになっていて、ほとんどのRPMではこれが指定されています。
依存関係を調べて必要なRPMパッケージをローカルに入れておけば、超高速インストールサーバーになるわけです。

うん。便利。

MySQL の文字化け問題
2006.12.25 23:30 | server, mysql

UTF8でデータを突っ込んでいるはずなのにデータを見ようとしても文字化けするのです。
ネットで調べていたら変なオプション発見したので試してみると文字化けが解消されているではないか・・・

以下メモ
MySQLバージョン: 5.0.27

#vi my.cnf
-------------------------------------------
skip-character-set-client-handshake
default-character-set=utf8
-------------------------------------------


副次効果として MySQL Administrator の文字化けが直った。
これは相当効率が上がりますわ。。

携帯メアドの独自性について
2006.11.07 13:35 | server, postfix, mobile

携帯電話のキャリアさんたちはまったくもって仕様を無視している模様です。

良く見かけるハイフンから始まるメールアドレス。
こいつはPC用メールアドレスでは恐らくありえないことであり、うちのPostfixでもエラーをはいていました。

- maillog -
invalid recipient syntax: "-xxx@example.jp"


でも対策は超簡単で、postfixの設定に一行追加するだけ。
これで問題なく送信できるようになるはず・・・


# vi /etc/postfix/main.cf
---------------
#最後に追記
allow_min_user = yes
---------------

タグ一覧