Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
BP Study #16 Linuxシステムの物理制約と(web)システム監視のポイント
Search
Toshiaki Baba
December 14, 2008
Technology
0
14
BP Study #16 Linuxシステムの物理制約と(web)システム監視のポイント
(スライドのホストをSlideShareから引っ越し)
https://www.slideshare.net/toshiak_netmark/bp-study-16-presentation
Toshiaki Baba
December 14, 2008
Tweet
Share
More Decks by Toshiaki Baba
See All by Toshiaki Baba
SREsのためのSRE定着ガイド
netmarkjp
12
8.4k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
6.4k
技術書を活用してほしい!
netmarkjp
0
510
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.2k
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
4
2.9k
ばばさんは、なぜ本を書くの?という話
netmarkjp
0
800
SRE≠インフラなんだけどもう誤解されちゃってる から、DevOps新実装として Site Production Engineering はいかがでしょう?
netmarkjp
2
2.1k
非ITの事業会社にSREと言わずにSREを持ち込んだ
netmarkjp
16
30k
変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」
netmarkjp
0
2k
Other Decks in Technology
See All in Technology
Share my, our lessons from the road to re:Invent
naospon
0
130
Snowflakeの開発・運用コストをApache Icebergで効率化しよう!~機能と活用例のご紹介~
sagara
1
350
Helm , Kustomize に代わる !? 次世代 k8s パッケージマネージャー Glasskube 入門 / glasskube-entry
parupappa2929
0
290
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
170
日経のデータベース事業とElasticsearch
hinatades
PRO
0
200
速くて安いWebサイトを作る
nishiharatsubasa
15
15k
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
460
クラウドサービス事業者におけるOSS
tagomoris
3
980
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
150
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
100
OpenID BizDay#17 みんなの銀行による身元確認結果の活用 / 20250219-BizDay17-KYC-minna-no-ginko
oidfj
0
210
Windows の新しい管理者保護モード
murachiakira
0
200
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Building Your Own Lightsaber
phodgson
104
6.2k
Thoughts on Productivity
jonyablonski
69
4.5k
Site-Speed That Sticks
csswizardry
4
400
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
A Modern Web Designer's Workflow
chriscoyier
693
190k
A better future with KSS
kneath
238
17k
It's Worth the Effort
3n
184
28k
Transcript
1 Linuxシステムの物理制約と (web)システム監視のポイント 馬場 俊彰
[email protected]
http://netmark.jp from heartbeats (http://heartbeats.jp)
2 誰? 株式会社ハートビーツのCTOです たまにJPUGのお手伝いもしています MSP(Management Service Provider)してます 24時間有人監視サービス フルマネージドサービス(ハウジング、ホスティング) 今:サーバエンジニア+ネットワークエンジニア
前職:JavaでWebシステム開発 前々職:サーバエンジニア+ネットワークエンジニア OS(主にLinux(CentOS))、ネットワーク機器、 ミドルウェア(ApacheとかRDBMSとか)の
3 お仕事のご紹介 システムの運用開始後に プロジェクトに参画することが多いです でも「いまさらどうしようもナイよ。。。」ということ もしばし 設計段階で考慮しておいてもらえれば… 設計段階で声をかけてもらえれば… と思うこともしばし 要件定義
設計 開発 テスト 移行 運用
4 今日のお題 Linuxシステムの物理制約 Linuxシステムを運用していく上で問題になるポイント・ 問題になったことがあるポイントをご紹介します 設計段階で活かしてもらえれば… (web)システム監視のポイント 我々が、普段何を気にしているかをご紹介します 監視設計に活かしてもらえれば…
5 今日はLAMPシステムを例にします こんな感じの、web+db 1Uサーバ2台の構成を想定します スモールスタート。って感じです ほんとにスモールスタートだと1台構成ですが、説明の 都合上2台にします VPSもいいんですが、それなり性能でハードウェアを使 webサーバ Apache
dbサーバ MySQL PHP + フレームワークなどなど インターネット
6 制約ポイントその1 ポイント:ネットワークI/Oするところ ネットワーク帯域 同時接続数 グローバルIPアドレス webサーバ Apache dbサーバ MySQL
PHP + フレームワークなどなど インターネット このあたり
7 制約ポイントその1 ネットワークI/Oするところ データの出入り口 ここが詰まるとどうしようもない コストをかけないでも段階的な解消はある程度できる(= 時間稼ぎはできる)けど、根本解決は厳しいことが多 いです 「物理的に無理です」
8 制約ポイントその1 ネットワーク帯域(1/2) Q.インターネット回線はどのくらい使えるのかな? A.回線業者によって違います 100Mbps回線なら、だいたい100Mbpsまで出ます ※あまり帯域使いすぎると別料金になることがあるの でご注意ください Q.回線がいっぱいいっぱいになるとどうなるの? A.同時接続数が異常に増えます
よくあるパターン:
9 制約ポイントその1 ネットワーク帯域(2/2) Q.回線がいっぱいいっぱいになったらどうしよう? A.中身を減らしましょう 画像データの容量削減 データ圧縮(mod_deflateなど) キャッシュを活用(特に動的サイト) 線を太くする もう1回線引いてみる
いっそ外に出す⇒CDN(値は張ります)
10 制約ポイントその1 同時接続数(1/3) Q.1台でどのくらい同時に接続を受け付けられます か? A.netstatコマンドのstateを見て、TIME_WAITが10000個 に差し掛かると実用上厳しくなってきます (20~30万円クラスのIAサーバの事例) このくらいの数になると、netstatコマンドの出力が終わ りません。。
11 制約ポイントその1 同時接続数(2/3) Q.同時接続が増えてきたらどうしよう? A.チューニングしましょう Linuxのカーネルパラメーターを変更して、ネットワーク ソケットの再利用をはやめます このあたりの話になると途端に日本語の資料が少なくな ります Apacheやプログラムのチューニングも並行してやりまし
ょう 日本語の資料も多いのでがんばりましょう
12 制約ポイントその1 同時接続数(3/3) Q.同時接続が増えてきたらどうしよう?(つづき) あまり同時接続数が増えると、ファイアウォール・ロー ドバランサーなどのネットワーク機器がボトルネック になります いい製品は初期費用がとてもとても高いです Linuxでなんとかする方法もあります ファイアウォール⇒iptables
ロードバランサー⇒LVS(L4) ※製品を買ったほうが幸せになることもありますよ
13 制約ポイントその1 グローバルIPアドレス Q.やっぱりIPv6ですか? A.そういう話ではありません グローバルIPアドレスの割り当てを後から増やすのは大 変なんです!(ネットワーク割り当てなので) 無停止・設定変更なしだと大変。無理な場合も多々あり 停止・設定変更アリであれば大丈夫 1本の上流回線あたりのIPアドレス数は限りがあるので、
みんなが拡縮→移転を繰り返すと。。。。 ⇒ラック内・ラック間のLANケーブルがスパゲッテイに なります。テプラやファイバタグを駆使して回避して
14 制約ポイントその2 ポイント:Apache 同時起動プロセスを増やす ハードウェアリソースをうまく使う メモリ、CPU、ディスク webサーバ Apache dbサーバ MySQL
PHP + フレームワークなどなど インターネット このあたり
15 制約ポイントその2 Apache PHPだとprefork(プロセスモデル)で実行することに 世間に事例も情報も豊富です そしてなぜか事欠かない失敗事例
16 制約ポイントその2 同時起動プロセスを増やす Q.どれだけ同時に起動できますか? A.がんばって増やしてみましょう システムリソース制限を回避 ユーザあたりのファイルディスクリプタの割り当てを増 やす ファイルオープン、Socketオープン、標準入力、標準出力、標準 エラー出力などで個別に消費します
Too many open files を回避します ユーザあたりの起動プロセス数を増やす 最近は無制限になってたりしますが念のため
17 制約ポイントその2 ハードウェアリソースをうまく使う(1/3) メモリをうまく使う 安くなったとはいえ、いっぱい載せると高いです PHPである以上、preforkでの起動になるので個々のプロセ スのサイズが並列数に直結します プロセスあたりのメモリ使用量を減らすのがポイント Apacheのロードモジュールの数を減らしてある程度対応 できます
フレームワークを使ってたりすると、ロードするクラス の数が多くなりがちみたいですね ⇒個々のプロセスサイズが大きくなりがち
18 制約ポイントその2 ハードウェアリソースをうまく使う(2/3) CPUをうまく使う コンパイルキャッシュ(APCなどのアクセラレータ)を使う OpenX(オープンソースの広告配信ソフト)では絶大な効果があり ました ロードアベレージ60→0.6 無駄なディスクI/Oをしない ご存じの方も多いと思いますが、ディスクI/Oって重いんです
ディスクI/Oが重いので、アクセスが多いサイトでは画像のアク セスログはとらないようにします ちなみに、LoadAverage=CPU(コア)数だったら過負荷では ないです
19 制約ポイントその2 ハードウェアリソースをうまく使う(3/3) ディスクをうまく使う 1ファイルのサイズには制限があります (32bit Linuxではだいたい2GB) ログはローテーションしてくださいね daily +
sizeのローテーションが嬉しいです 1ディレクトリのファイル数はほどほどにしてくださいね オペレーション上、3桁くらいまでにしてもらえると嬉しいです
20 制約ポイントその3 ポイント:MySQL ハードウェアリソースをうまく使う メモリ、CPU、ディスク webサーバ Apache dbサーバ MySQL PHP
+ フレームワークなどなど インターネット このあたり
21 制約ポイントその3 MySQL SQLの最適化をしてください! インフラチューニングでは限界があります 基本的にスケールアウトする方向になります、スケール アウトできる設計にしておいてくださいね 更新トランザクションと参照トランザクションの分離、 データソースも分離 遅延レプリケーションを考慮に入れた画面遷移、コーデ
22 制約ポイントその3 も ハードウェアリソースをうまく使う(1/2) メモリもディスクもうまく使う 参照が多いテーブルはできるだけオンメモリで動作する ようにしましょう 32bit Linuxではプロセスサイズの上限が小さいので、足りなくな りそうであれば64bit
Linuxを使いましょう 更新が多いのであれば、対象テーブルの物理データファ イルサイズは小さく保つのがポイントです MySQLは追記型ではないですが、データファイルが大きいと中身 スカスカでもinsertが重くなります 中身がスカスカになったらOPTIMIZE TABLEで縮小できます 1テーブル=1ファイルなMyISAMだと、32bit Linuxでは1フ
23 制約ポイントその3 も ハードウェアリソースをうまく使う(2/2) CPUもうまく使う サブクエリや、JOINの時に一時テーブルがメモリに収ま らないサイズだとディスクを利用します。ディスクI/O は重いので(以下略 一時テーブルのサイズは設定で変更できます 単位時間の処理数を増やすためにコネクトを高速化しま
しょう localhostへのTCP接続は、UNIXソケットより7.5%遅い 別サーバへのTCP接続は、localhostへのTCP接続より8~ 11%遅い(100Mイーサの場合)
24 システムを監視する 一般ユーザ視点でのチェック ビジネス視点でのチェック 障害を素早く検知(して、対応)←会社のお仕事 webサーバ Apache dbサーバ MySQL PHP
+ フレームワークなどなど インターネット
25 システムを監視する ちょっとしたコツ インターネット越しの監視は、結果のブレが大きいです 何度かのリトライは折り込み済み。 2回リトライが一般的? 監視ポイントの最適化が、システム安定化のカギです
26 システムを監視する 一般ユーザ視点でのチェック サイト表示、メールなどの各種サービスの応答速度を監 視します 例えば、サイトのトップページの応答が 3秒以内 ⇒OK 3~5秒 ⇒Warning
5秒~ ⇒Critical 文字列検知なんかもやってます 他にも、リソース監視もやってます LoadAverage、総プロセス数、ログインユーザ数、ゾンビ プロセス数、プロセス有無・・・
27 システムを監視する ビジネス視点でのチェック システムの稼働状況を、実績データを元に判定します 現在のログインユーザ数、直近の売上、メール配信数な どを元に、システムの稼働状況を判定します システム個別の判定基準になるので、チェックプラグイ ンは全て自作です
28 システムを監視する 障害を素早く検知(して、対応) ハートビーツの事務所では、24時間誰かが働いています アラートが発生したら「人が」すぐに対応します 「最近リトライが多いな~」など、障害の予兆を素早く 察知することで、大火事を予防します 「継続は力なり」ということで、何よりも続けることが 大事です
29 ご静聴ありがとうございました 馬場 俊彰
[email protected]
http://netmark.jp from heartbeats (http://heartbeats.jp)