linux, 超解釈

cronとanacronとRHEL5系6系についてですが

結構、適当に設定し、
はまることが多々あったので自分なりに簡単に解釈してみましたのでお話しします。

anacronについては同じものではあるのですが
5系と6系で解釈を変えるとすんなりと頭に入り込んでくるようになると思います。

では、始めます。

RHEL5系

cron
特定のプログラムなどの処理を定期的に実行してくれるプログラム

anacron
サーバ停止中のためcronが実行できなかった場合にジョブを再実行させるためのcronのヘルパープログラム

定期ジョブは下記の二つのうちのいずれかで設定を行う。

■/etc/crontab
cron処理の実行スケジュールを設定する。

■/etc/cron.{hourly,daily,weekly,monthly}
スケジュールごとに指定のディレクトリでプログラムを登録する。
上記の設定だけで定期スケジュールとプログラムの設置が完了する

■/etc/cron.d
自分ではさわらない。

ヘルパーのanacronを利用したい場合はcron.dailyなどのディレクトリでプログラムを登録し、
/etc/init.d/anacronで定期的にstartしてあげる。
設定ファイルは/etc/anacrontabを読み込みます。
標準で/etc/cron.{daily,weekly,monthly}配下に登録されたプログラムがanacronで動作していなかった場合に再実行してくれます。

RHEL6系

cron
特定のプログラムなどの処理を定期的に実行してくれるプログラム

anacron
仮想環境などのゲスト環境でcron処理が特定の時間に集中しないように定期ジョブをうまいこと分散してくれるプログラム
なので、サーバが稼働し続けていなくともRHELの5系の時のanacronのように、サーバが稼働した時点でジョブを実行してくれるようになります。

■/etc/crontab
確実にcronを指定時間に動かしたい場合はこちらを利用する。

■/etc/anacrontab
実行時間は変動するが確実にcronを実行させたい場合はこちらを利用する。

■/etc/cron.{daily,weekly,monthly}
こちらのディレクトリでプログラムを登録するとanacronのほうで実行されます。
※cron.hourlyを使いたい場合はanacrontabで設定を忘れずに

■/etc/cron.d
自分ではさわらない。

5系と同じようにcronを利用したい場合はcronie-nonanacronをインストールしてcronie-anacronをremoveするといいみたい。

p.s.
タイトルは「部屋とYシャツと私」を字余りで歌いながら書き込んでました^^;

艦これ

簡単にクリアできそうな[3-2]

攻略しようと頑張っているんですが、なんどやっても、ボスにたどり着けない。

時は流れ数日、傷つき成長しながら

15回以上は戦ったでしょうか。

もしかして攻略に必要な艦娘がいるんじゃないかと気づき

作戦内容をよくよく読んでみました。

提督失格です。

駆逐艦のみの艦隊じゃないと先に進めないらしい。。。

駆逐高速艦隊を組んだ時には

レベル24の島風ちゃんが旗艦で
残りはレベル1の駆逐艦が5隻

さあ、どうしてくれようか。(T・T)

linux

非常に忙しいサーバやNATやプロクシサーバなどを運用している環境だと上記のようなエラーによく遭遇するかと思います。

iptablesを利用している環境では利用するステートフルなパケットのエントリを管理するためのテーブルが必要で、
管理するエントリが多すぎるとエントリテーブルのサイズが上限に達してしまい上記のエラーとともにパケットをドロップしましたよというエラーが表示されるようになります。
※iptablesが動作していない環境では問題とはなりません。

この問題を解決するためにはエントリのテーブルサイズの上限を引き上げる必要があります。

みなさんと同じように我々も下記のように設定しています。
※CentOS6系

vi /etc/sysctl.conf
net.nf_conntrack_max = 1000000

そして、

当然、「この値は監視しなくてはならない」となると思います。

dmmではmuninのip_conntrackというプラグインを利用してこの値を監視することになるのですが、

どうもネットワーク系のエラーが多発して調子が悪い。

muninのグラフを見てみるとインターフェースで多くのエラーが発生してしまいます。

if_err2_vnet1-day

if_err2_eth1-day (2)

調査していくとこのプラグインはスクリプトの中で

上記のコマンドを呼び出しているようです。
このプロセスが動作している時だけロードアベレージが跳ね上がるので、
root権限でのコマンドのせいで競合が発生しこの値の取得に多くの時間を要しているのかもしれません。
※混雑する時間帯は15秒もかかる場合も。

あまり混雑していない15時くらいの時間でも下記のように多くの時間を要していました。

sudo time cat /proc/net/ip_conntrack|wc -l

24028

real 0m2.616s
user 0m0.005s
sys 0m2.621s

因果関係はわかっていませんがこの状況のためエラーが高くなっているのではないかと推測。

該当するプラグインを停止してみました。
その時の画像が下記の3枚となります。※先ほどと同じではあるのですが。
12時すぎに該当のmuninプラグインを停止したのですが、その後エラーが発生していないことが分かるかと思います。

if_err2_eth1-day (2)

if_err2_vnet1-day

また、下記はロードアベレージの値ですが、muninが動作する5分毎にギザギザになっていたものが、
なめらかになったのがわかるかと思います。

load-day

自分でプラグインを作ればなんとかなるかなとプラグインのソースを眺めていると

my $conntrack = '/usr/sbin/conntrack';
my $nf_conntrack_file = '/proc/net/nf_conntrack';
my $ip_conntrack_file = '/proc/net/ip_conntrack';
my $command;
if ( -x $conntrack) {
$command = "$conntrack -L -o extended 2&>/dev/null";
} elsif ( -r $nf_conntrack_file ) {
$command = "cat $nf_conntrack_file";
} elsif (-r $ip_conntrack_file ) {
$command = "cat $ip_conntrack_file";
} else {
die "Can't find conntrack information\n";
}

という部分がありました。

まずはconntrackというコマンドが実効可能かどうかを確認し可能であればそのコマンドを使うようになっています。

/usr/sbin/conntrackコマンド???

はい、知らなかったです。調べてみました。

conntrackコマンドはconntrack-toolsに含まれているコマンドでredhat系の標準レポジトリでは含まれていません。

我々の環境でもconntrackコマンドが入っていないため、当然catコマンドが呼び出される状態だった。

リッチな機能を搭載したユーザ空間で動作するコマンドで/proc/net/nf_conntrackを置き換えるべく作られたようなので、
兎にも角にも、早速、インストールして違いを確認してみました。

インストール方法

wget http://sourceforge.net/projects/flexbox/files/flexbox-release-1-1.noarch.rpm/download
rpm -ivh flexbox-release-1-1.noarch.rpm
yum -y install conntrack-tools

コマンド結果

$ sudo time cat /proc/net/ip_conntrack|wc -l
27311

real 0m3.324s
user 0m0.002s
sys 0m3.322s

$ time conntrack -L|wc -l
conntrack v0.9.15 (conntrack-tools): 27062 flow entries have been shown.
27062

real 0m0.142s
user 0m0.101s
sys 0m0.047s

15時30分の時間帯でもかなりの差がついています。

なるほど、
だから、conntrackコマンドがあれば優先して利用し、なるべくcatを利用しないような設計になっているんだと。

とりあえずは自分でプラグインを作成する必要はなさそうで、

今後は高負荷なサーバでconntrackテーブルを監視する場合はconntrackコマンドをインストールしようかなと思っています。

追記です。

23時30分時点でのコマンド結果

$ time conntrack -L|wc -l
conntrack v0.9.15 (conntrack-tools): 53225 flow entries have been shown.
53225<
real 0m0.265s
user 0m0.191s
sys 0m0.087s

ユーザ空間で動作するコマンドなのでユーザで利用時間が多くなっています。

$ sudo time cat /proc/net/ip_conntrack|wc -l
51947

real 0m14.574s
user 0m0.009s
sys 0m14.611s

こちらのroot権限で動作するcatコマンドはシステムの利用時間が多くなっています。

こんなに違うんですね。

apache, linux

apacheでmod_disk_cacheを利用してキャッシュサーバを構築していますが、

mod_disk_cacheはキャッシュが利用するディスクの残り容量をコントロールしてくれません。

ですので、htcachecleanを使って容量のコントロールを行います。

ただ、このhtcacheclean

mtimeを利用してファイルを削除する仕様ですので、

ファイルが作成もしくは修正された時刻順(古いファイルから)で削除が行われるためヒット率が向上しません。

atimeを利用すれば人気のないコンテンツから削除が可能となりヒット率が向上するのですが現在の仕様ではそうなっていません。

そこで下記の3つのアプローチのいずれかで不人気作品からファイルが消えていくように設定します。

  1. htcachecleanのソースを改造する
  2. findコマンドを利用してatime基準で削除する。htcachecleanを使わない。
    例)find /cache/* -atime +600 -exec rm -rf {}
  3. findでアクセス頻度の少ないファイルを抽出しtouchでmtimeを強制的に修正してhtcachecleanを使って削除

キャッシュサーバとなるとnoatimeでmountしている方も多いと思いますが、

dmmではnoatimeオプションは指定せずにこういった用途のため残すようにしています。

ツール

WAN高速化ツール

自分に対しての備忘録です。

APPEX NETWORKSのWAN高速化のプロダクト

アプライアンス機器とソフトウェアの両方で有償で提供されています。

net.ipv4.tcp_available_congestion_controlで設定できるcubic、bicのようなアルゴリズム。

提供されている主な製品群はこちら

LotServer:コンテンツサーバにソフトウェアをインストールし高速化

LotWAN:コンテンツサーバの前段に専用のアプライアンスを挟み込み高速化

LotClient:クライアントPCにインストールしてアップロードを高速化

アプライアンスは提案のあった販社様より借りて評価するとして、

今回はLotServerを検証してみます。

LotServerはWindowsでもLinuxでも対応しているので小回りの利く使い方ができそうです。

では、早速試してみます。

まずはFreeTrialを申し込みます。

メアドと電話番号とパスワードの登録が必要です。

登録するとメールが届きますのでそこに記載されているURLへ飛んでアクティベーション化します。

次にLotServerをダウンロード

注意点

lotServerを起動するスクリプトにてtso gso gro lro sgがoffにされます。

ただ、私の環境ではlroをoffにしようとするとエラーになりlotServerが起動しませんでした。

bnx2xのnicではこれをオフするために下記の設定が必要でした。

こちらの設定でlroはoffとなります。

とりあえず、インストールはこれだけですので早速試してみます。

■zetatcpをON 米国バージニア州のec2環境より東京にあるサーバから1.2GBのファイルをダウンロード

15.0MB/sでした。

■zetatcpをOFF 米国バージニア州のec2環境より東京にあるサーバから1.2GBのファイルをダウンロード

こちらは4.65MB/s。ONの時の三分の一程度の速度でした。

ちなみに

ローカル同志でも高速化するのかも試してみました。

■zetatcpをON 隣接サーバから1.2GBのファイルをダウンロード

370M/sでした。

■zetatcpをOFF 隣接サーバから1.2GBのファイルをダウンロード

459M/sでした。逆にONのほうが遅い。

隣接なら輻輳等の制御などしなくていいので逆にないほうが高速ということでしょうかね。

検証結果から

世によくあるWAN高速化の製品とあまり変わらいように思います。

ただ、終端ノード側で設置、もしくはインストールするだけでも効果があるので、

金額や用途によっては検討できるかもしれません。

ちなみにawsのサンパウロリージョンのec2環境からも試しています。

ON:72Mbps
OFF:56Mbps

pingの応答時間は400ms程度なのですが、回線が安定しているのか地球の裏側からでも結構早いんですよね。

PAGE TOP