HAProxyのパフォーマンスチューニングをやったメモ(CPS編) - 元RX-7乗りの適当な日々
HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。 基本的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。 あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。 前提 HAProxyを動かすのに使用した環境は以下の通り。 Server: DELL PowerEdge R420 CPU: Intel Xeon E5-2430L @ 2.00GHz * 2 Memory: 96GB Ethernet controller: Intel Corporation Ethe
Ubuntu(Debian)でのamd64(x86_64) - 元RX-7乗りの適当な日々
Ubuntu Serverで、諸事情でdpkgコマンドでパッケージ(debファイル)をインストールしようとして、debファイルを探していると、アーキテクチャがi386用とamd64用しかなくて、あれ、Intel系の64ビットOS使っているんだけど、どうしたものかと思ったのでメモ。 例えば、このパッケージ。 http://packages.ubuntu.com/oneiric/vlan 対象のサーバでは↓の通りなので、Ubuntuのサイトで、"x86_64"を探してみたのですが、見当たらず。 # arch x86_64 で、dpkgのman見つつ、アーキテクチャの確認っぽいオプションがあったので実行。 # dpkg --print-architecture amd64 お。"amd64"とな。 ・・・で、恥ずかしながら、今更知ったのですが、UbuntuというかDebianの世界では、AMD6
HAProxyを透過型のプロキシとして使う(HAProxy with tproxy) - 元RX-7乗りの適当な日々
HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。 で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。 使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。 参考: Transparent proxy support (www.kernel.org/doc) https://www.kernel.org/doc/Documentation/networking/tproxy.txt Linux kernelのnf_tproxy_coreモジュールを
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
はじめてのAmazon VPC - 2. 外部インターネットと接続する(NATインスタンスを使う) - 元RX-7乗りの適当な日々
前回のエントリ「はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する」の続きです。(今更シリーズ) Amazon VPCでは、各サブネットでのアクセスコントロールを柔軟に設定できたり、自ネットワークからVPNトンネルをはって接続できるなど、よりセキュアなネットワーク構成を意識できることもあり、VPC内で起動したサーバ(Amazon EC2インスタンス)は、場合によっては外部インターネットに出て行くことが出来ないケースがあります。 しかし、サーバから外部の必要なものをダウンロードしたり、外部リポジトリや外部APIアクセスしたい場合、Amazon S3等のVPC外のAWS各サービスに接続したい場合(パブリックネットワークからしかアクセスできない)などもあるでしょう。 もちろん、そこはVPCでの設定次第となりますので、今回は、前回作成したAmazon VPC網内で起動した
はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する - 元RX-7乗りの適当な日々
ぼちぼちAmazon VPCを触り始めてみました。 今更な感じもしますが、Amazon VPCのPrivate SubnetにHardware VPN(IPsec VPN)を使って接続できる今時点での詳しい手順を残しておこうと思います。(シリーズ化します。多分。) Amazon VPCの概要は、下記公式サイトの説明に任せますが、簡単に説明すると、Amazon VPCを使うことで、AWSクラウド内にプライベートネットワークを作成することができるので、従来よりネットワークレベルでの細やかなアクセスコントロールを実現できます。 また、VPN接続をサポートしているので、会社やデータセンターと接続することで、プライベートネットワーク内でAWSのリソースをシームレスに扱うことができるようになります。つまり、自社ネットワークのアドレスをAmazon EC2のインスタンスに振ることができる、みたいなイメー
Linuxで2つのファイルの共通行を出力する - 元RX-7乗りの適当な日々
機会があったので、調べてみました。 2ファイルの差分はdiffコマンドで取るけど、その逆の共通している部分はどうやって取得するのか。エレガントなやり方はやっぱりgrepコマンドを使うのかしら？ 前提 $ diff -c5 {a,b}.txt *** a.txt 2013-08-28 18:54:49.293055071 +0900 --- b.txt 2013-08-28 18:53:58.517693404 +0900 *************** *** 1,6 **** 1 - 2 3 5 5 6 --- 1,6 ---- 1 3 + 4 5 5 6こういう2つのファイルがあったとして・・・ grepで $ grep -x -f {a,b}.txt 1 3 5 5 6grepコマンドの"-x"オプションを使うと、こんな感じで、2ファイルの共通部分が出力される。 -x, --line
tracerouteの色々 - 元RX-7乗りの適当な日々
インターネットのネットワークに多少なりと興味がある方なら、指定の目的地までの経路探索をしてくれる、みんな大好きtracerouteコマンド。 そんなtracerouteの色々をメモしておきます。 tracerouteの仕組み 既に多くの解説サイトがあるので、そちらに譲りますｗ tracerouteはTTLを1ずつ増やしながらパケットを送信することで、経路情報を取得する。 TTLとはパケットの生存期間を表し、ルータを1つ経由することに1ずつ減算される。 ルータはTTLが2以上のパケットが届いた場合、TTLの値を1だけ小さくし次のルータへ転送する。 TTLが1のパケットが届いた場合、届いたパケットを破棄しICMP time exceededパケットを送信者に返す。 tracerouteはまず、TTLを1にセットしたパケットを送信する。最初のルータに届いた時点でTTLがゼロになり、ICMP ti
AWS Command Line Interface(awscli)を使ってみた - 元RX-7乗りの適当な日々
今更な話題ではありますが、Pythonで作られたAWS Command Line Interface(aws-cli: 従来のJavaで動いていたEC2 API Toolsとは別物)を入れて動かしてみました。メモ的な感じで残しておきます。 aws-cliは、pipで管理できるし、これ1つで複数のAWSサービスを扱うことが出来て、かつレスポンスもJSONとかで返ってくるので、なかなか便利です。 $ aws autoscaling ec2 importexport sns cloudformation elasticache opsworks sqs cloudsearch elasticbeanstalk rds storagegateway cloudwatch elastictranscoder redshift sts datapipeline elb route53 support
muninサーバのチューニングの考え方 - 元RX-7乗りの適当な日々
色々見ていたら、ちょっと思うところがあったので、tweetしようと書き始めたんだけど、長くなってしまったのでブログに残しておこうと思う。 muninのサーバは、対象ノードが多くなってきたりして、処理が増えてくると、多くのケースでネックになってくるのはCPUとディスクI/Oで、それらの有限なリソースをcronの定期実行が走る5分間隔の間々でいかに効率よくリソースを使うかがmuninサーバのチューニングのポイントだと思っている。 リソースを使いきった＝サーバが重い、という図式が成り立つのであれば、リソースを完全に使い切る時間帯を作らない努力/調節をすれば良いわけです。要件によっては、パフォーマンスを最大限出し切る設定(チューニング)が正とは限らないわけです。 つまり、muninのようにビューを提供していて、(バックグラウンドの処理以外の)その表示自体にもそれなりにリソースを食われる前提だとした
Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々
とりとめもなく書いてみる。主にルーキー向けです。 サーバの運用とかやっていると、不定期ではあるが、たまにタイトルのようなディスク容量が逼迫する話題に直面します。 まぁ、それが起こるのは一旦良いとして、みんなこういう時、どうやって調べているのだろう？ とりあえず、僕がどうやってるか書いてみます。 何はともあれ現状確認 みんな大好き"df"コマンドです。細かい説明は省きますが、各パーティション・ファイルシステムごとにディスクの使用状況を確認。 # df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/sda3 130G 88G 36G 72% / /dev/sda1 494M 23M 447M 5% /boot tmpfs 12G 0 12G 0% /dev/shm正確とは言いませんが、だいたいどのパーティションにどのくらい容量が空いているかが確認できます。 ど
AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々
昨日から、色々調べ始めています。今日はAWSの上位ネットワークまわり。特に東京リージョン(Asia Pacific (Tokyo) Region)。 現時点の情報のスナップショットとしてログがわりに残しておきます。 ASN (AS番号) まず、以下のサイトで調べてみると、、、 http://bgp.he.net/search?search[search]=Amazon&commit=Search この通り、Amazonが取得しているASNは10個ほど見受けられますが、中身を見ていくと、このうちAS16509にほぼ集約されていることがわかります。 AS16509に接続されているBGPのPeerの数は現時点で、v4が158、v6が10となっています。(公開情報のみ) Peerの内訳は以下のリンク先から確認できます。 http://bgp.he.net/AS16509#_peers ざっくり確認
Linux/Mac/Windowsでハードウェア構成に関する情報を調べる - 元RX-7乗りの適当な日々
サーバ/クライアントPC問わず、今使っているマシンのハードウェア構成がどのようなものかをOS上で確認したくなることもあるでしょう。 そんな時にお手軽に調べられる方法を、たまーにググったりするので、Linux/Mac OS X/Windowsの3つのOSの場合の調べ方をここに残しておきます。 Linux Linuxでは、dmidecodeコマンドを使います。 BIOSの情報とか、マシンの各種システム情報(シリアルナンバー等の各種メタ情報、CPU、メモリ、その他デバイス情報とか)が取得できます。 CentOS/RHELとかだと"kernel-utils"パッケージがインストールされていれば使えます。 ちょっと長いですが、以下のような感じです。 # dmidecode # dmidecode 2.11 SMBIOS 2.7 present. 87 structures occupying 399
大容量ファイルのSCP転送を高速にする方法 - 元RX-7乗りの適当な日々
比較的大きいサイズのファイルをSCPで転送することがあって、できるだけ高速化してみたかったので、色々試してみたメモ。 scpというかsshには、暗号化方式と圧縮有無の指定があるので、それらのベンチマークを。 尚、以下は、SSH v2が対象です。v1はかなり遅かったのと、そもそも使っていないので試していません。 (追記: 2019/11) 本エントリの情報は既に古いため、以下のエントリにて再検証しています。あわせてご覧くださいませ。 ベンチマークで利用した環境 [Server1] <=> [Gigabit Switching Hub] <=> [Server2] Server1 (HP ML115 G5) AMD Phenom 9950, 8GB, RAMディスク使用, Gigabit Ethernet Server2 (HP ML115 G1) AMD Opteron 1210, 4GB,
Chef 11 での client/server/knife のセットアップ手順(+α) - 元RX-7乗りの適当な日々
遅れながら、Chefの新しい11系のバージョンを触ってみました。 つまづいた途中経過を含めて、セットアップのログや動きで気付いた事を簡単に残しておきます。 尚、今回使ってみた実行環境は、CentOSの6系です(Linux)。 結論から申し上げますと、Chefの新しいバージョンは、サーバのセットアップが物凄く楽でした。 旧来のバージョンでもUbuntuはそこそこ楽でしたが、CentOSの面倒くささと言ったら、んもう。 インストールパッケージの入手先 最近は、下記のChef本家となるOpscodeのサイトから、client/serverともインストーラ(各OSでのパッケージ)をダウンロードできるようになっています。 Chef Downloads Clientのインストール 上記サイトからパッケージをダウンロードしてインストールしてもよいのですが、Linuxであれば curl -L https:
複数のChef-serverで同一のvalidation.pemを利用させたいとき - 元RX-7乗りの適当な日々
運用設計・ルール的な是非は一旦おいておいて、複数のChef Serverでvalidation.pem(chef-validatorの鍵)を共通化させたいときに、どうやったかというメモ。ちなみに、バージョン10系での話です。 イメージは、既に1台のChef-serverを運用していて、もう1台新しいChef-serverを足したいんだけど、nodeとなるサーバの運用フローを変えたくないので(面倒くさいので)、validation.pemは共通で使いたいなー、というケース。(これはユースケースによってメリット・デメリットがあります) 僕が探した感じ、APIではその口が用意されていなかった(というか、あるように見えてeditしてみたけど反映されなかった)ので、結論からいうとバックエンドのCouchDBにアクセスして書き換えた感じです。 説明はここまででいいような気もしますが、一応自分のために手
Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々
以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですｗ) 実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった＆今はまた結果が違うかもなので、やってみた。 ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。 というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた -
xfsファイルシステムのデフラグ方法とパフォーマンスについて - 元RX-7乗りの適当な日々
4/1のエントリで、頑張ってブログを書く頻度を上げます、と言ったまま4日が経過し、このままだとただのエイプリルフールの戯言になりかねないと思ったので、ちょっと調べてみたログを残します。 XFSの設計はエクステントベースで、ファイルの内容は1つ以上のエクステントと呼ばれる連続的な領域内に保存されている。XFSファイルシステム内のファイルは、ユーザーの使い方によってはフラグメント化することがあるが、xfs_fsrユーティリティを使ってそのようなファイルをデフラグすることでファイルアクセスについてのシステムの性能を向上させることができる。 xfs_fsrを使ってXFSファイルシステムをベストの状態で使用する (1/2) - ITmedia エンタープライズ ココの部分の使い方を実際に試してみることにしました。 まず、用意したのは、xfsファイルシステムで2年くらい運用して役目を終えた、とあるサー
muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
なぜかJenkinsを起動させたらパケットロスが多発しまくったのを無理やり直した話 - 元RX-7乗りの適当な日々
※ まず、はじめに、僕があまりJenkins自体の挙動に詳しくないので、誰か正しい直し方をご存知の方がいらっしゃったら、教えてほしいです。 本題。これは明らかな環境依存下(特にネットワークまわり)での話なのですが、KVM上でのLinux(CentOS 5/6系)な環境で、Jenkinsを起動するとパケットロスが多発して全然使い物にならないケースがありました。 (Jenkinsを落とすと普通に復旧しちゃうんですよね。。。) で、こんな感じで若手が苦しんでいたので、ちょっとOS上で色々と調べていたのですが、どうもtcpdumpを眺めていると、 11:31:14.427406 IP xxx.xxx.40.102 > 239.77.124.213: igmp v2 report 239.77.124.213 11:31:17.905397 IP xxx.xxx.40.102 > 239.77.12
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
