艦これ

簡単にクリアできそうな[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程度なのですが、回線が安定しているのか地球の裏側からでも結構早いんですよね。

linux, インフラ全般

みなさんの会社ではどのように切っているのでしょうか?非常に気になります。

なので、まずはdmmのパーティションの切り方をシェアします。

といっても、

ほぼ標準のままです。

ただ、下記の2点だけは変更はします。

snapshot用の領域確保のため10%だけ領域を余らせる。

swap領域は512MBとする。

その他は標準のままです。

領域は3つのグループに分けて考えています。

1.OS領域
2.アプリデータ領域(ウェブデータ、DBデータ)
3.ユーザ領域(作業領域)

OS領域やアプリデータを守ることでサービスの停止を防ぐことになりますが、

いつもユーザ領域から問題はやってきます。

OS領域やアプリデータ領域は緩やかの右肩上がりな傾向なのでアラートに引っかかってきますが、

ユーザ領域はデータのバックアップ作業や大きなデータをコマンドで生成したりするため、アラートに引っかかる時にはすでに時遅しで100%になった後です。

逆に言えば、

この1点だけを社内で徹底して守ることで同じ仕様のサーバが一律に提供が可能となり運用の負荷が格段に下げることができます。

quotaで守ればという意見もあるのですが、そこまで必要性を感じていないのが現状です。quotaの設定を可変させる運用をなくしたほうが良いのではないかと考えているためです。

また、kickstartなどで複数パターンを作ってそれぞれを適用させればいいじゃんという意見もあるのですが、これもメンテナンスをし続けなくていけないので採用していません。

なので、一つのデザインパターンを確立してそのパターンにはめて運用の負荷を下げるという考えになるかと思います。

最悪、リザーブの5%の領域も使えますし、このような形でシンプルなパーティションとしています。

もちろん例外も考えられます。
外部のユーザが数百人いてそれぞれのディレクトリにファイルをアップロードするような用途だとquotaやユーザ領域を分けることで対応することもあります。

swapに関しては

入らせないためメモリの搭載量を増やす

vm.swappinessで対応するという流れです。

パーティションに関してはこのようが考えを持っています。

みなさんはどのようにお考えですかね。コメント、ツイートお願いします。

PAGE TOP