[an error occurred while processing this directive]
hayabusaサーバーセッティングのご紹介

第182日目:hayabusaサーバーセッティングのご紹介

こんにちは、( ,_ノ` )です。

6月19日に行われました FIFA ワールドカップ 2010 日本対オランダ戦は、
優勝候補のオランダ相手に果敢に攻めましたが0対1で惜しくも日本が敗れました。
次の試合は6月24日木曜日27時30分(日本時間)決勝トーナメント進出を掛けて
デンマークと対戦します。

さて、日本対オランダ戦に向けて2ちゃんねる実況サーバーとして投入された
Intel Core i7-960搭載の新型SSDサーバーですが、試合の盛り上がり
に合わせた瞬間的なアクセス増加もなんなく耐え抜き、当初懸念されていた
100Mbps の壁も無事に突破する事が出来ました。

ピーク転送量 109.990Mbps

試合終了後にhttpdの最大接続数不足によりウェブページの表示待ち状態が
発生しましたが、hayabusaサーバーは溜まった処理を高速にこなしていき、
約4分ほどでサーバーが自力で復帰していました。

しかもhayabusaサーバーには、
httpdの最大接続数をまだまだ増やす事が出来るだけの余裕があります。

live28サーバーで数々の検証を重ねて生み出されたセッティングを、
hayabusaサーバー用に更なるチューニングが施されています。

hayabusaサーバーのチューニングをこちらにご紹介いたします。

スペシャルセッティング
2ちゃんねるセッティング
changiセッティング
むむむさんスペシャルセッティング1 ネットワークバッファ拡大
むむむさんスペシャルセッティング2 httpd待機数の増量(hayabusa用06/22改良)
むむむさんスペシャルセッティング3 無駄なディスクI/Oの削減
むむむさんスペシャルセッティング4 1Gbps接続用TCPチューニング
むむむさんスペシャルセッティング5 ネットワークバッファ使用量節約
むむむさんスペシャルセッティング6 コネクションのキューの最大長を拡大(hayabusa用
むむむさんスペシャルセッティング7 rtprioによるlogbufferの活入れ
むむむさんスペシャルセッティング8 rtprioによるspeedy_backendの活入れ
1Gbps 完全帯域保証
ハードディスク(仮)

サーバースペック
・CPU:Intel Core i7 CPU 960 @ 3.20GHz
・MEM:24 GB (6x 4GB)
・HDD:Seagate Barracuda 7200.10 250GB
          Model<Seagate ST3250410AS 3.AAA>
・SSD:X25-M Solid-State Drive 80GB SATA-2 2.5(G2)
          Model<INTEL SSDSA2M080G2GC 2CV102HD>

・サーバー名: tiger3552.maido3.com
・IPアドレス: 206.223.151.80
・OS: FreeBSD 7.0R (amd64)
・Apache/2.2.10

その他の設定
speedy_backendプロセスの最大数の調整
・ICMP redirectログを記録しないよう変更(/etc/rc.conf icmp_log_redirect をコメントアウト)
・SunOSさん版logbufferのインストール(2ch特化型サーバースレッド Part46 / 178
・/home と /hd にマウントオプション「noatime」を設定
・ExtendedStatus On
・BufferedLogs On
・ユーザレベルで全プロセスをtopコマンドで表示可能
・ユーザレベルで smartmontools でデバイス情報を取得可能


2ちゃんねるセッティング
2ちゃんねるセッティングではメモリディスクの作成、Apacheチューニング、
カーネルモジュール追加
を行っています。

メモリディスク
頻繁に更新されるファイルや呼び出し回数が多いファイルをメモリディスク上に
置く事によりハードディスクへのアクセス回数を減らして負荷を解消します。

容量はサーバーに搭載されているメモリのサイズに合わせて任意に設定可能です。
BIG-server.com のサーバーは大容量メモリを標準搭載していますので、
メモリの追加無しでメモリディスクを作成できます。

Apacheチューニング
アクセス数が多いサーバーでもリソースを効率よく使えるように、
Apacheの各種パラメーターを調整します。

カーネルモジュール追加
accf_http.ko HTTP通信のパフォーマンスを向上させるモジュールを追加します。
accf_data.ko HTTPS通信のパフォーマンスを向上させるモジュールを追加します。


changiセッティング
changiセッティングは2ちゃんねるセッティングの発展形です。
(設定方法についてはこちらの日記でもご紹介しています。)

ウェブサーバーメイン機能の高速化
changiセッティングでは、OSの実行ファイル/ライブラリ/モジュール、
Apacheの実行ファイル/ライブラリ/モジュールを、データ処理が速い
メモリディスク上にすべて展開しています。

各種プログラム実行時のオーバーヘッドを軽減
changiセッティングでは、Apacheの実行ユーザーをシステムユーザーから
一般ユーザーに変更する事により、以下の効果が期待できます。

1. CGIプログラム実行時のSuExecによるオーバーヘッドを無くすことができ、
サーバーパフォーマンスの向上につながります。

2. mod_cgidsoやPHPなどのApacheモジュールから直接実行されるプログラムと
通常のCGIプログラムが同一ユーザとなるため、生成されるファイルのオーナーや
パーミッション等も同一となり、より円滑な運用が可能になります。

3. 高速なCGI実行を実現するためのSpeedyCGIを、従来のspeedyプログラムを
経由する方法(CGI方式)から、子プロセスの生成を伴わないmod_speedycgiモジュール
経由での実行に変更できます。

特に3.は、外部イベント等により集中的・爆発的にCGIが実行されるサーバーにおいて、
パフォーマンス上の大きな効果が期待できます。

このようにchangiセッティングでは、データ処理が速いメモリディスク上で
ウェブサーバーメインの機能を動かし、かつ各種プログラム実行時の
オーバーヘッドを軽減させる事によりサーバー負荷を極限まで減少させて、
より大量のアクセスがあっても快適にサーバーを動かします。


むむむさんスペシャルセッティング1
突発的なアクセス数の増加でデータのやりとりが頻繁になった時に
処理が詰まらないように、ネットワークのデータバッファの値をチューニングしています。

/boot/loader.conf
# increase nmbclusters, maxsockets, etc.
kern.ipc.nmbclusters=131072
kern.ipc.maxsockets=65536
vm.pmap.shpgperproc=2048
kern.ipc.maxpipekva=41943040

/etc/sysctl.conf
# increase maximum file descriptors
kern.maxfiles=131072
kern.maxfilesperproc=65536
# increase listen queue
kern.ipc.somaxconn=32768
kern.ipc.maxsockbuf=20480000
# see http://qb5.2ch.net/test/read.cgi/operate/1097931665/666-676
net.inet.icmp.icmplim=3000
net.inet.icmp.icmplim_output=0
# authority
security.bsd.see_other_uids=1
# nmb (number of mbufs) tuning for FreeBSD 7.x
# note: kern.ipc.nmbclusters=131072 should be set at /boot/loader.conf
kern.ipc.nmbjumbop=65536
kern.ipc.nmbjumbo9=32768
kern.ipc.nmbjumbo16=16384
# original settings of A-tiger
net.inet.tcp.rfc3042=1
net.inet.tcp.rfc3390=1
net.link.ether.inet.log_arp_wrong_iface=0
# changi Memory settings
vfs.ufs.dirhash_maxmem=134217728


むむむさんスペシャルセッティング2(hayabusa用)
最初に指定した数のhttpd起動して、待機状態のhttpdが一定数を下回らないよう
起動数を変化させ、突発的なアクセスの増加があった場合は、待機数を最大値まで
伸ばす事により、受け入れ可能になるまでの待ち時間を作らないよう設定しています。

Apacheディレクトリ/conf/httpd.conf
【hayabusaサーバー用チューニング 6/22 改良】
最初にhttpdをN個起動し、アイドル状態のhttpdが常に(N - k - 1)個以上になるように起動数を変化させ、非常時には待機数をN + M個まで増やす設定

StartServers          N
MinSpareServers      (N - k - 1)
MaxSpareServers       N + m
ServerLimit           N + M
MaxClients            N + M
MaxRequestsPerChild   10000
MaxMemFree             2000

N: 初期値
M: マージン
m: アイドル定数(M >= m >= 0)
k: 平常時の込み具合

StartServers           4096
MinSpareServers        3775
MaxSpareServers        5120
ServerLimit            5120
MaxClients             5120
MaxRequestsPerChild   10000
MaxMemFree             2000

hayabusaサーバー用セッティング
N: 4096
M: 1024
m: 1024
k: 320

Apacheディレクトリ/conf/httpd.conf
【hayabusaサーバー用チューニング 6/21】
最初にhttpdを1536個起動し、アイドル状態のhttpdが常に1024(1023+1)個以上になるように起動数を変化させ、非常時には待機数を8192個まで増やす設定

StartServers           1536
MinSpareServers        1023
MaxSpareServers        1536
ServerLimit            8192
MaxClients             8192
MaxRequestsPerChild   10000
MaxMemFree             2000

hayabusaサーバーではメモリサイズを24GBに増量していますので、
httpdの最大接続数を更に増やす事が出来る余裕が生まれました。
hayabusaサーバーではhttpdの最大接続数をlive28サーバーの4倍に設定しています。


むむむさんスペシャルセッティング3
BIG-server.com ではサーバー内にDNSキャッシュを内包しています。
サイトのアクセス数が多くなってくると、DNSキャッシュへの問い合わせ回数も
それだけ多くなりますので、DNSキャッシュの問い合わせログの記録でかかる
I/O負荷も無視できなくなってきます。

スペシャルセッティング3ではDNSキャッシュの問い合わせログを止めて、
DNSキャッシュのログによるI/O負荷を解消します。

live28.2ch.net が入っているSSDサーバー7号機では、
DNSキャッシュの問い合わせログの記録でI/O負荷の約20%を占めていましたが、
スペシャルセッティング3の適用によりサーバーのパフォーマンスに余裕が生まれました。


むむむさんスペシャルセッティング4
hayabusaサーバーでは、1Gbps専用線に接続しています。
FreeBSD 7.0におけるTCPのデフォルト設定は100Mbps接続を想定しているため、
1Gbps接続用にTCPのチューニングを施しました。

/etc/sysctl.conf
# additional network settings for 1Gbps connection
# http://fasterdata.es.net/TCP-tuning/FreeBSD.html
net.inet.tcp.sendbuf_max=20480000
net.inet.tcp.recvbuf_max=20480000
#net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=16384
#net.inet.tcp.recvbuf_auto=1 # Receive buffer autotuning enabled by default
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.inflight.enable=0


むむむさんスペシャルセッティング5
大量のアクセスが一気にサーバーに押し寄せてネットワークバッファが足りなくなると、
httpdプロセスが「zoneli(mit)」状態となり、サービスが停止する事があります。
この設定では、ネットワークバッファ使用量を節約する事により、バッファ不足の
発生を抑えてhttpdが「zoneli(mit)」状態になりにくいようにしています。

/etc/sysctl.conf
# The higher the buffer, the more mbufs will be used for network connections.
# Lowering these buffers down will reduce your memory usage and
# save yourself some mbufs.
# This should dramatically reduce your mbuf usage and get your server
# out of zonelimits once and for all.
# http://www.realfreebsdtips.com/networking/freebsd-stopping-zoneli-state/
net.inet.tcp.sendspace=8192
net.inet.tcp.recvspace=8192


むむむさんスペシャルセッティング6(hayabusa用)
Apacheの方で制限している保留状態のコネクションのキューの最大長を
サーバー規模に合わせて拡大しています。

この設定により突発的に発生するアクセスの集中時(混雑時)の接続で
「詰まり」や「エラー」が発生しにくくなる事が期待されています。

Apacheディレクトリ/conf/httpd.conf
# Increasing maximum length of the queue of pending connections.
# (Default value is 511)
ListenBackLog 8192

FreeBSD 7.0RではListenBackLogは実際には設定値の1.5倍が設定されます。
デフォルト値511の場合、保留状態のコネクションのキューの最大長は768となり、
この数値を超えたTCP接続は破棄されます。

ListenBackLogに設定出来る最大値はkern.ipc.somaxconnの値に依存しており、
0より小さい値やkern.ipc.somaxconnより大きい値が設定された場合は、
kern.ipc.somaxconnの値が強制的に適用されます。

hayabusaサーバーではメモリサイズを24GBに増量していますので、
httpdの最大接続数を更に増やす事が出来る余裕が生まれました。
hayabusaサーバーではhttpdの最大数をlive28サーバーの4倍に設定しています。


むむむさんスペシャルセッティング7
rtprioによるlogbufferの活入れ
logbufferコマンドは、多くのhttpdプロセスからのアクセスログを同時並列的に
受信しており、従来はlogbufferコマンドの処理が滞ることにより、httpdの処理も
ブロックされてしまう場合がありました。

SunOSさんがlogbufferに改良を施し、aio(4)を使用した高効率かつ非同期な
ログの書き込みが実現された事により、logbufferの処理待ちでhttpdの処理が
ブロックしてしまうことが軽減され、全体の処理能力が向上しました。

スペシャルセッティング7では、logbufferをrtprioコマンド経由で起動するように
httpd.confに設定を追加することにより、同コマンドを通常の「タイムシェアリング」
優先度から「リアルタイムプロセススケジューリング」優先度に変更して動作させることで、
httpdのブロックをさらに高いレベルまで起こりにくくすることを意図した設定となります。

Apacheディレクトリ/conf/httpd.conf
2010/06/30:logbufferの優先度をspeedy_backendよりも上にするため31→23に変更

TransferLog "| exec /usr/sbin/rtprio 23 /usr/local/sbin/logbuffer"

TransferLog "| exec /usr/sbin/rtprio 31 /usr/local/sbin/logbuffer"

/etc/sysctl.conf
# tuning for aio(4)
vfs.aio.max_aio_queue_per_proc=1024
vfs.aio.max_aio_queue=4096

speedy_backendプロセスの最大数の調整
SpeedyCGIでは、speedy_backendというバックエンドプロセスが実際の処理を行います。

speedy_backendは処理状況によりプロセスが必要に応じて起動され、
並列処理を実行することが可能となっています。

しかし、あまりにも多くのプロセスが同時に起動されると、
例えばHDDのパフォーマンスが低い場合、多くのspeedy_backend
プロセス同士が競合してしまい、全体の処理能力が低下する事がありました。

従来の主な設定値は以下の通りです。
(実際にはサーバの状況により、微妙な調整を実施しています)

-M 8 旧banana
-M 16〜-M 32 旧tiger、T-banana
-M 32〜-M 48 A-tiger
-M 64 live28

hayabusaサーバでは従来の4倍 -M 256 に設定値を上げる事にしました。

これにはCPU処理能力の向上と、SSDの採用によるディスクI/Oの大幅な
パフォーマンス向上が大きく寄与しています。


むむむさんスペシャルセッティング8
mod_speedycgiを有効にした環境では、httpdが受け取ったSpeedyCGIで処理する
プログラムは、httpdに包含されたmod_speedycgiモジュールにより、speedy_backendを
直接起動して実行されます。

この場合、httpd → speedy_backendという形でプログラムが実行され、
httpdから起動されるspeedy_backendプログラムは一般的な優先度で実行されます。

これを、setuidとrtprio(2)機能を利用して自分自身の優先度を
「リアルタイムスケジューリング」に上げてspeedy_backendプログラムを上書き実行して
処理を渡す「speedy_backend_wrapper」という特別なプログラムを作成・インストール
して、speedy_backendプログラムの優先度を向上させます。

具体的には、

httpd ―(子プロセスとして起動)→ speedy_backend

という従来の形を、

httpd ―(子プロセスとして起動)→ speedy_backend_wrapper ―(自分自身を上書き)→ speedy_backend

という形に変更することにより、
speedy_backend_wrapperプログラム内で、優先度の変更を実施できるようにします。

この場合、speedy_backendを直接実行する形よりも起動コストは上がりますが、
一度起動したspeedy_backendはしばらくの間常駐し、毎回起動されるわけではないため、
コストの上昇は最小限にとどめられることとなります。


live28サーバーからhayabusaサーバーへのハードウェアの進化は非常に大きく、
live28サーバーそのままの設定で大量のアクセス数をなんなくこなす事が出来ました。

しかも、httpdの最大接続数を更に増やすなどチューニングの改良にまだまだ余裕
がありますので、ソフトウェアの設定値による限界を超えた場合でも、設定値の増量など
拡張が可能です。

hayabusaサーバーにある掲示板の一覧やサーバーの稼働状況など、
こちらのページでご確認いただけます。

新作戦「一羽の鴎」/ i7-960 + SSD サーバー / hayabusa.2ch.net

ぜひご覧ください。


181日目に戻る。   183日目に続く。

目次に戻る
1日目 2日目 3日目 4日目 5日目 6日目 7日目
8日目 9日目 10日目 11日目 12日目 13日目 14日目
15日目 16日目 17日目 18日目 19日目 20日目 21日目
22日目 23日目 24日目 25日目 26日目 27日目 28日目
29日目 30日目 31日目 32日目 33日目 34日目 35日目
36日目 37日目 38日目 39日目 40日目 41日目 42日目
43日目 44日目 45日目 46日目 47日目 48日目 49日目
50日目 51日目 52日目 53日目 54日目 55日目 56日目
57日目 58日目 59日目 60日目 61日目 62日目 63日目
64日目 65日目 66日目 67日目 68日目 69日目 70日目
71日目 72日目 73日目 74日目 75日目 76日目 77日目
78日目 79日目 80日目 81日目 82日目 83日目 84日目
85日目 86日目 87日目 88日目 89日目 90日目 91日目
92日目 93日目 94日目 95日目 96日目 97日目 98日目
99日目 100日目 101日目 102日目 103日目 104日目 105日目
106日目 107日目 108日目 109日目 110日目 111日目 112日目
113日目 114日目 115日目 116日目 117日目 118日目 119日目
120日目 121日目 122日目 123日目 124日目 125日目 126日目
127日目 128日目 129日目 130日目 131日目 132日目 133日目
134日目 135日目 136日目 137日目 138日目 139日目 140日目
141日目 142日目 143日目 144日目 145日目 146日目 147日目
148日目 149日目 150日目 151日目 152日目 153日目 154日目
155日目 156日目 157日目 158日目 159日目 160日目 161日目
162日目 163日目 164日目 165日目 166日目 167日目 168日目
169日目 170日目 171日目 172日目 173日目 174日目 175日目
176日目 177日目 178日目 179日目 180日目 181日目 182日目
183日目 184日目 185日目 186日目 187日目 188日目 189日目
190日目 191日目 192日目 193日目 194日目 195日目 196日目
197日目 198日目 199日目 200日目 201日目 202日目 203日目
204日目 205日目 206日目 207日目 208日目 209日目 210日目
211日目 212日目 213日目 214日目 215日目 216日目 217日目
218日目 219日目 220日目 221日目 222日目 223日目 224日目
225日目 226日目 227日目 228日目 229日目 230日目 231日目
232日目 233日目 234日目 235日目 236日目 237日目 238日目
239日目 240日目 241日目 242日目 243日目 244日目 245日目
246日目 247日目 248日目 249日目 250日目 251日目 252日目
253日目 254日目 255日目 256日目 257日目 258日目 259日目
260日目 261日目 262日目 263日目 264日目 265日目 266日目
267日目 268日目 269日目 270日目 271日目 272日目 273日目
274日目 275日目 276日目 277日目 278日目 279日目 280日目
281日目 282日目 283日目 284日目 285日目 286日目 287日目
288日目 289日目 290日目 291日目 292日目 293日目 294日目
295日目 296日目 297日目 298日目 299日目 300日目 301日目
302日目 303日目 304日目 305日目 306日目 307日目 308日目
309日目 310日目 311日目 312日目 313日目 314日目 315日目
316日目 317日目 318日目 319日目 320日目 321日目 322日目
323日目 324日目 325日目 326日目 327日目 328日目 329日目
330日目 331日目 332日目 333日目 334日目 335日目 336日目
337日目 338日目 339日目 340日目 341日目 342日目 343日目
344日目 345日目 346日目 347日目 348日目 349日目 350日目
351日目 352日目 353日目 354日目 355日目 356日目 357日目
358日目 359日目 360日目 361日目 362日目 363日目 364日目

いま一番お得なページ! 解析
[an error occurred while processing this directive]