鯖屋のお仕事ってどーよ 大規模サイトの為のLinuxカーネルチューニング

Presentation on theme: "鯖屋のお仕事ってどーよ 大規模サイトの為のLinuxカーネルチューニング"— Presentation transcript:

1 鯖屋のお仕事ってどーよ 大規模サイトの為のLinuxカーネルチューニング
関西オープンソース 2004 ステージ 2004年10月22日 13: :00 もりかわひろかず

2 はじめに SunOS4, Solaris2, FreeBSD系で育ってきた鯖屋が、1999年に Linuxでの大規模サーバ(大規模なweb、メール、共有型仮想サーバ)の運用を試行錯誤しながら行い、肌で感じた Linux kernel の体験記(格闘記)をお話し、それを通じて運用の現場の姿を感じていただけたらと思います 実感体験記　OSの研究者でもなく、エバンジェリストやエンスージャストでもない ただ道具としてOSに関わってきた鯖屋が体と心で関わってきた話をしたいとおもいます 鯖屋の運用の現場を笑ってやってください 複数のユーザを相乗りさせるシェアード型のインターネットサーバの運用やってます

3 遠い昔… A long time ago in the UNIX far, far away….
1994年頃からインターネットサーバのSIを手がけていた その頃、Solaris 2系が安定してきて、SunOS4を捨ててSolaris 2系に移行していた PC-UNIXは*BSD系しか選択肢無し 当時、Linux系はnetwork系の信頼性が無いという話で、実際のサービスには使わなかった (冒険はしたくなかった) 安定性があり、運用ノウハウが多いOSを選択した

4 枯れたOS 実際の業務に使用するOSの選択に際しては、枯れたOS(信頼性があり、安定して、ノウハウも蓄積された)を選択するでしょう
大規模なサーバ運用にも枯れたチューニングの定石があった

5 なぜチューニングが必要なのか 一般的な使用状況を想定してる 安全性を確保するためにリソース制限をしている
無駄なリソース浪費を避けるため 安全性を確保するためにリソース制限をしている open files, memory, process…etc 各ユーザごとのリミット 何につかうのか? その用途に合わせてチューニングする必要がある リソースを消費してもスピード優先という用途 DBのような巨大アプリを動かすという用途 たくさんのユーザを安全にさばくという用途 もちろん拡張性は十分考慮して設計されてますが 最近のOSは運用状況で自動的に拡張して、無駄な消費ふせぎつつ運用のしやすさと拡張性を向上させている アベーラビリティとスケーラビリティ

6 定石 Solaris系では /etc/system の maxusers, rlim_fd_max, rlim_fd_cur
maxusersを変更することによってkernel内のテーブルサイズを自動的に調整する (BSD系であるSunOS4から引き継いだ) あとはnddでdriverのconfigurationをさわる 挙動を見てNetwork系のパラメータを変更 大規模なDBサーバやroot DNSにも実績がある 世の中に書籍やよくまとまったtuning 系の tips Web Siteがあった たとえばSolaris系ではarpテーブルの保存期間が長いので ネットワーク機器を入れ替えた場合に孤立してしまう場合があるのでそのあたりは変えます

7 定石 (2) FreeBSDでは 学術分野での長年のノウハウ蓄積 過負荷で悲鳴をあげても予測の範囲 (調整の範囲)
Kernel configuration の maxusers, NMBCLUSTERS をさわる 今は maxusers=0 にしておけばハードのスペックを見てよしなに設定してくれる kernel recompile すら不要で /boot/loader.confにホゲっておわり FD_SETSIZE, SOMAXCONN系の調整 sysctl と アプリ側の調整 学術分野での長年のノウハウ蓄積 過負荷で悲鳴をあげても予測の範囲 (調整の範囲) ユーザ毎の limit は /etc/login.conf 3.x から全然さわる必要がなくなった そんな比較的保守的なスタンスでサーバ運用やってたのですが…

8 Linux を使え! 1999年 Linuxバブル全盛期 営業サイドから Linux を使えとのご命令
お客様のニーズに早く対応すべき Linux ac? ぐらいから安定してきたという噂があった ちょいとLinuxさわってみるのもいいかな まー UNIX(like)だしなんとかなるかー というわけでテスト運用始めてみた

9 おどろいた! おそろしく速い filesystem I/Oが早いのは大規模なWebサーバにとってはうれしい さっと動かしたら安定してるじゃん
恐れていた障害時の不整合は皆無 意外と丈夫じゃん I/Oが早いのは大規模なWebサーバにとってはうれしい さっと動かしたら安定してるじゃん 結構 Linux ラヴ☆かもぉ 非同期なので早くてあたりまえなのだが、なかなか対障害性もよかった Sendmail社が行っていたセミナー資料でlinuxの非同期ファイルシステムは mail spoolには絶対つかうなと書いて合ったがまったく問題なし

10 限界まで鯖をシバク Size matters not.
こんな鯖 ps ax | wc -l 1115 cat /proc/net/sockstat Sockets: used 643 TCP: inuse 637 orphan 45 tw alloc 641 mem 796 Apache combined format の access log が 1日で6GB以上 サーバのスペックはあまりいえねー 大規模なサーバは 某気象情報サイトの台風接近時期の平日のお昼休みと、定時前から定時後直後 某世界的スポーツの国際試合の全世界向け公式サイトとか これがいわゆる共有サーバで稼働していた

11 定石(3) 2.4.x Linux では システム中のファイル・ディスクリプタ数の上限を緩和する
echo "32768" > /proc/sys/fs/file-max ユーザ毎のファイル・ディスクリプタ数の上限を緩和する ulimit -n unlimited ユーザ毎の起動するプロセス数の上限を緩和する ulimit -u unlimited セマフォの設定の上限を緩和する echo " " > /proc/sys/kernel/sem ネットワークキューの上限を緩和する echo ”2048" > /proc/sys/net/ipv4/tcp_max_syn_backlog もちろん値は環境依存なのでハードウェアや用途によってかわります 最近ではいろんな書籍Webで情報が出ていますし、アプリベンダーからも運用tipsとしてまとめらているのをよく見かけます 2.2ではもっといろいろさわってやらないといけなかったのですが2.4以降では楽になっています

12 不可解な挙動 Linuxの心が解るまでの道のり
定石の調整はやっていたが… ふつーにつかってるかぎりはすごく安定していた むちゃな使い方したらMM系で不可解な挙動 メモリーは余裕があるのに突然のOOM-kill ドライバからはバッファが足りないとの悲鳴 なぜ急にメモリーが足りなくなるのぉ なぜ極端にパフォーマンスが悪くなるのぉ 2.2の途中までは過負荷時に突然死も ぐはっ吐血! メモリーマネージメントサブシステム メモリーは余裕があるのにfilesystemのパフォーマンスが極端にわるくなる

13 Linuxの心が解るまでの道のり(2) 当時は、Linuxを用いた大規模サーバの運用ノウハウの情報が不足
おしえてGoogle! しかし、当時はまとまった情報は無し できるヤツはそんなの当たり前でわざわざとりたてては書かない!? kernelあげろ、メモリー増やせ攻撃 本質の議論無し ユーザ系のmlでは 本気で大規模サーバにつかっている人っているんかなー

14 不可解な挙動の例 No! Try not. Do, or do not. There is no try.
パフォーマンスがよかったので採用したIntel EtherExpress Pro/100 で当時 2.2 のドライバ eepro100 が過負荷時に eth0: can’t fill rx buffer のメッセージをはきまくる (その当時は Linux でそのNICを使うことを嫌う人もたくさんいた) すでに過去の問題ですが、典型的な例として提示します

15 不可解な挙動の例(2) Googleで検索したら、同じように困ってる人ちらほら ズバリの解決策は見付けられなかった お決まりの監視
ふつーに使ってる限り出ないもん お決まりの監視 vmstat 1 watch -n 1 ’cat /proc/meminfo’ watch -n 1 ’cat /proc/slabinfo’ watch -n 1 free すでに過去の問題ですが、典型的な例として提示します

16 不可解な挙動の例(3) どうも、そのメッセージを吐く時は MemFree が極端に少なくなっているっぽい
しかし、Buffres, Cached はふんだんに確保されている そのあたりに秘密がありそう /proc/sys/vm あたりで tuneable な物を探すとbdflushとfreepages(2.2の場合) が怪しい

17 不可解な挙動の例(4) /usr/src/linux/Documentation を読む
ここでもカルチャーショック受る メンテされてない(^^;;; man も嘘書いてる場合もあるし… /proc/sys/vm/freepages を増やしてやると現象はおさまるようだ freepages をキーワードにざっと kernel の source を追っかけてみた なんか謎な閾値やら定数やら… Memory Management subsystem 怪しいなぁ

18 Linuxの心が解るまでの道のり(3) Use the source, luke!
「KISS principle」”Keep it Simple, Stupid”, “Keep it Simple and Small”には共感するが… コア開発者が議論している kernel mlやMM ml をあさる MMごっそりかえちゃえ的なノリ AndreaさんとRikさんが喧嘩してるしぃ 仕切りまくる Alan Cox 氏 慎重な Linus 氏 大体においては上手くいく… (ラテン系?)

19 Linuxの心が解るまでの道のり(4) No! No different! Only different in your mind.
猥雑だけどパワフル *BSD系にはない面白さ (猥雑さが嫌いという意見もよく解るけどね) 自分が同時代的に参加しているのだという気になるし、参加せざるを得ない面白い開発コミュニティー というわけで自分も何かしようと1999年から kernel tuning 系 tips を Web siteで書き始めた (今ではいろんな所にいっぱい情報が出てます)

20 枯れないOS とーれとれぴーちぴちLinux
“枯れ”とは無縁 日々改善、日々実験 ハードウェアやnetwork環境はものすごく変化している それにつれて kernel も変化している 現実のサービスに使っていいかどうかは議論があるが(安定性、信頼性の面で) 処理が速いのは得難いメリット “今”はかなりいいよね いつも”今”が旬 いろいろ格闘しながら解ったこと 他のOSももちろんそうなんだけど、ダイレクトに見えてしまうところが面白い 正直いって ありきたりだけども用途用途で使いわれるのがよい お客様はlinuxつかいたい linux環境でないとつかえないアプリも多いし

21 おまけ 最近のディストリビューションのkernelなら安定してます
特にサーバ用として提供されている物であれば変更を加えることも不要 (のはず) 自身でkernelをcompile場合は、-ac, -aa, -mm 等のpatchを吟味した上で、必要に応じた物を当てたほうがいいです 素のリリースのままでは不具合がでるパターンもある 2.4.x では -rmap は有効かも そろそろ 2.6.x にかえる時期かも RvR

22 May the source be with you!
(-ac patch) 旅に出ますた! (-aa patch) (-mm patch) the home page of Linux-MM Rik van Riel's Linux kernel patches (-rmap VM patch) TCP Tuning Guide 私のWeb Alan Cox Andrea Arcangeli Andrew Morton