1 / 57

オペレーティングシステム 2014

http://www0.info.kanagawa-u.ac.jp/~kaiya/os/. オペレーティングシステム 2014. 2014/7/17 木曜 2 限 2 年前期 海谷 治彦 永松 礼夫. 目次. 14 章 性能 14.1 性能の要素 14.2 システムの性能 14.3 資源の利用率とスループット 14.4 スケジューリング，応答時間 14.5 スループット 14.6 オーバーヘッド 15 章 標準化 15.1 日本語サポート 15.2 国際化 15.3 OS の仕様と標準化 若干のエピローグ 感想へのフィードバック.

kellsie
Download Presentation

オペレーティングシステム 2014

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. http://www0.info.kanagawa-u.ac.jp/~kaiya/os/ オペレーティングシステム 2014 2014/7/17 木曜 2限 2年前期 海谷 治彦 永松 礼夫

  2. 目次 • 14章 性能 • 14.1 性能の要素 • 14.2 システムの性能 • 14.3 資源の利用率とスループット • 14.4 スケジューリング，応答時間 • 14.5 スループット • 14.6 オーバーヘッド • 15章 標準化 • 15.1 日本語サポート • 15.2 国際化 • 15.3 OSの仕様と標準化 • 若干のエピローグ • 感想へのフィードバック

  3. 基本的な考え方 • システムの性能を決める要因 • どんな処理(ジョブ)を行うのか？ • どのくらいの量や頻度で行うのか？ • どんなハードウェアで行うのか？ • どのように処理群をスケジュールするのか？ • 処理の特徴や量 • 単純な計算を逐次的に行う，いわゆるバッチ処理 • 対話的な処理が複数同時に動作する．

  4. 誰が性能を計測する？ • システム全体の性能を横目に見ながらOSは資源割り当てやスケジュールを変える必要がある． • その意味からは，性能計測はOSの役割ともいえる． • しかし，今日では，専用の性能計測ツール(ベンチマークツール)で計測するのが一般的．

  5. ハードウェアの能力 1/2 • プロセッサの性能 • 単位時間辺りの命令実行数が一般的 • MIPS Mega Instruction per second 秒あたり何メガ命令を実行できるかという指標 • とはいえ，プロセッサによって個々の命令の能力が違うので，異なるシリーズ間では比較が困難． • 単純な四則演算しか命令として持たないCPUもあれば，命令一発で配列の計算とかできるCPUもある． • CPUのクロック数も用いられる． • レジスタの数と大きさ • バス幅 32bit 64bit

  6. ハードウェアの能力 2/2 • メモリ量 • GB 等． • 入出力性能 • ディスクやネットワークの速度． • ディスクの容量 • GB, TB等

  7. 処理の特性 • 実行命令数 • システムコール，数値計算，グラフィクスに特化した数え方もある • 利用メモリ量 • 入出力回数 • 入出力量 • ベンチマーク (詳細は後述) • システムの性能を測定するための指標．

  8. システムの性能 • 教科書での論調は処理(ジョブ)は明確な終わりがあることを仮定している． • 昼間の銀行窓口業務を夜間処理する． • センーター試験の結果を期日までに出す． • しかし，昨今は対話型処理や常時稼働のものが多い． • ツイッターやライン等のクライアント通信ソフト • ウエブサーバーやプリンタサーバー等 • オンラインゲーム • とはいえ，前者にフォーカスした性能の議論をちょっとみていきます．

  9. スループット • 単位時間あたりの処理数 • 最も直観的な「システムの速さ」 • 処理の種類によって当然スループットは変わる． • 具体的な処理例はベンチマークのところで． • 処理に明確な終わりがないとスループットは出しにくい． • 処理によっては資源を100%まで使い切る場合あり，その資源の空き具合がスループットを左右する． • このような資源をボトルネック資源と呼ぶ． • 通信回線のバンド幅，データバスの転送速度等が現実的な例．

  10. 資源の利用率 • 順次使用資源 • プロセッサ，入出力装置等 • 時間帯を区切り，利用している時間の割合を計算する． • 空間資源 • メモリ，ディスク等 • 全容量に対して，利用している部分の割合を計算する．

  11. 処理の時間 • 処理時間の分類1 • CPU実行時間 • 入出力時間 • 待ち時間 (通常はマルチタスクなので) • 処理時間の分類2 • システム時間 • カーネルモードでの実行時間，要はシステムコール実行時間． • ユーザー時間 • ユーザーモードでの実行時間． • 待ち時間 • 注: 「マルチプログラミング」という用語はOSでは確かに使われるがお勧めしない．(伝統的にこう呼んでるだけ) • 処理の実行は「プログラミング」では無いため． • プログラミングは「プログラムを書く」こと．

  12. timeコマンド 中略 合計時間 0.1秒 経過時間 0.22秒 48+47回 プロセスは 停止している

  13. 復習 時分割の考え方 (図7.4改) 時間の流れ プロセス1 プロセス2 CPU利用時間 プロセス3 プロセス4 数ナノ秒程度

  14. コンテクスト スイッチ • Context Switch • TSS等で，あるプロセスから他のプロセスへCPU利用権が移動する際，レジスタの内容等を更新すること． • Context • あるプロセスが計算を行うためのCPUが持つ状態変数群． • 主にレジスタの内容． • 本来，プロセスの章で話すべきでした orz

  15. 復習 時分割の考え方 (図7.4改) 時間の流れ プロセス1 プロセス2 CPU利用時間 プロセス3 プロセス4 コンテクスト スイッチ 数ナノ秒程度

  16. 端末の応答時間 • 一般人が直接ふれるプログラムのほとんどは対話型プログラムである． • その意味で応答時間は性能を示す重要な指標である． • とはいえ，「定番」といえる性能調査法やツールは無いようだ．

  17. 応答時間の簡易モデル • 平均応答時間を予測するための計算式 • 入力としては以下の情報を使う • N: 対話するプロセス(人)の数 • W: 対話中，対話者が考える時間の平均 • S: 一回の入力を処理するための時間 • R: サーバー利用率 (0～1) Nが増えれば1に近づく．

  18. 単一の対話者のモデル • 以下のように，考えて，処理してを繰り返すと仮定する．

  19. 複数対話者の振る舞いモデル • 以下のように思考が終わったらマシンに処理をしてもらう「待ち行列」に並ぶことを想定する．

  20. 処理数と応答時間の関係

  21. 復習 プロセススケジュール • プロセスはそれぞれの事情で休止したり停止したりしているが，いつかは条件がそろい実行可能となる． • 複数の実行可能プロセスがあった場合，どれから実行するかを決めるのはOSである． • この決め方のアルゴリズムがいくつかあり，OSの授業では定番のネタとなっている．

  22. 復習 アルゴリズム紹介 1/2 • First Come First Served (FCFS) • 生成された順番にCPUを割り当てる． • Shortest Processing Time First • 短いものから片づける • Priority Scheduling • 予めプロセスに優先度をつける • UNIXでも一部採用されている • Round Robin • 短いタイムスパンで公平に切り替える，TSS的． • 今時のOSの定番．

  23. 復習 アルゴリズム紹介 2/2 • PriorityとRound Robinの組み合わせ • Dynamic Dispatching • I/Oの利用頻度に基づき，優先度を変更する． • 今時のPC等には不向きだが，大型汎用コンピュータでは有効なのかもしれない． • Multilevel Feedback Queue • 優先度の異なる複数の実行待ちの行列を準備する．

  24. 復習 アルゴリズム全体の雰囲気 • 多くのプロセスをトータルで短時間で終わらせることに注視している． • 銀行の夜間一括処理的なものをスコープとしている． • 教科書の図7.7, 7.8等は如実にソレ示している． • 今時の対話的な処理の場合「処理の終わり」が明確でないため，実は Round Robin以外，あまり役に立たない． • プロセスの応答性能を考慮したアルゴリズムが今後は重要となるでしょう．

  25. 応答時間と経過時間の関係 • 個々の応答時間の長さによって，応答時間がどうかわってくるかを，スケジュールアルゴリズムによって比較する． • 正直，コンテクストスイッチのタイミングと，応答・思考の区切りが一致するとは限らないので，ちょっとこの比較に意味があるか疑問． • 応答時間が長い(コンテクストスイッチが長い)と，どのアルゴリズムも不利．

  26. スケジューリングとスループット • 前述のように，処理に明確な終わりが無い場合，スループットの意味はあまりない． • 一般利用者の手元で行われる処理では，スループットを議論しても仕方ない． • ラウンドロビン以外の選択肢はほぼ無い． • 例えば，ビッグデータの解析等では，ラウンドロビンよりもFCFS等のアルゴリズムのほうが良いのかもしれない．

  27. オーバーヘッド • 本来の処理を行う補助のため，OSが行わなければいけない処理をこう呼ぶ． • 具体的には， • コンテクストスイッチ • 仮想記憶からのページの復帰 • 無論，オーバーヘッドは小さくする必要がある． • 前述のtimeの例をみても，経過時間0.22に対して，実際の処理時間は0.1である．

  28. 再掲載 timeコマンド 中略 合計時間 0.1秒 経過時間 0.22秒 48+47回 プロセスは 停止している

  29. ベンチマーク Benchmark • システムの性能を測定するための指標． • 数多くの指標が存在する．(後述) • 実際に指標の値を測定するためのデータとツールが存在する．(後述) • 同じベンチマークを異なるシステムで利用することで，システムの優劣を比較できる．

  30. 実例 UnixBench • 名前の通りUNIX系OS(含むLinux)のベンチマークをするためのツール． • 複数の指標を提供し，システムの性能を数値化する，具体的には， • 整数演算の性能 • 不動小数点演算の性能 • 新規プロセス生成に関する性能 • ファイルコピーの性能 • パイプによる通信の性能 • システムコール呼び出しに関する性能 • グラフィックス表示に関する性能

  31. 15章 OSと標準化

  32. 文字コード • ご存じの通り，コンピュータ内では，(日本語や英語の)個々の文字は，bit列として表現されている． • ある文字をどのようなbit列で表現するかを，文字コードと呼ぶ． • 残念ながら，日本語の文字の文字コードは多種類あり，統一されているとはいえない． • 文字コードによって同じ文字が違うbit列になる．

  33. 日本語の文字コード群 • JIS X 0208 および ISO-2022-JP • シフトJIS • CP932, MS932, Windows-31J とほぼ同じ • Windowsで採用されている • EUC-JP • 昔はUNIXで広く採用されていた • Unicode • 複数言語を同時に表現するのに便利なコード． • UTF-8, UTF-16等，いくつかのバリエーションがある． • UTF-8が広く使われているような気がする．

  34. ソフトやツールの対応

  35. UIについて • User Interfaceも言語に合わせて，カスタマイズされているものが多い． • 日本語訳が残念で意味がわからん場合もある orz • 内部的には英語だが，見た目だけ変えている場合もある．(下図)

  36. OSの国際化 • Internationalization • I18N とも略される • IとNの間の文字が18文字だから(マジ) • LOCALE • 国に依存する言語，通貨記号，日付の書き順等をコンピュータ内で規定するもの． • たとえばドイツでは日月年の順番が一般的． • LANGはLOCALEの一部．

  37. Localeの設定例

  38. Localeの設定例 正確にはlocaleではなくLANGを切り替えているが， 上記にように指定した言語で警告が出る． 日本語訳が怪しいのがよくわかる例． (カナディアンフレンチとフレンチはこのレベルでは一緒ですね)

  39. 参考 エラー，欠陥，障害 • エラー error • ソフトウェア開発中の人間の誤った判断． • 例: プログラムミス，仕様の理解誤り． • 欠陥 fault (もしくは defect) • ソフトウェアが意図した振る舞いをしない原因となったソフトウェアの特性(コードの箇所)． • 所謂，バグと考えてよい． • 障害 failure • ソフトウェアが実行中に意図した振る舞いから逸脱したこと．

  40. OSの外部仕様 • OSが提供するAPIやサービスがある基準に準拠していれば，OSの変更や更新がしやすい． • 例えば，APIの名前と引数が統一されていなければ，OS毎にアプリケーションプログラムを作り直す必要がある． • そういった意味で，OSの仕様を標準化することが重要となる．

  41. そもそも仕様とは何か？ • Specification • 仕様を書類にしたものが仕様書と呼ばれる． • 「あるシステムやプログラムが，どのような環境下で，何をするのかの記述」 • 機能仕様 • 狭い意味の仕様． • 大まかにいうと，何を入れると何が出てくるか定めたもの． • 例: 「read関数はファイル名を与えると，ファイルの中身のデータを得られる」 • 非機能仕様 • 機能仕様に加えて，応答の速さや，信頼性を定めたもの． • 例：「read関数は1ms以内に必ず応答し，99.99%の精度で正しいデータを返す」 (実際のreadはこんな仕様はありません)

  42. OSの仕様の例 • POSIX • UNIX系OSをベースとしたAPIの仕様． • Windows NTも POSIX 1.0 に準拠している． • X/OpenのUNIX • Single UNIX Specification (SUS) • UNIX98, UNIX03等の呼称で呼ばれる． • 商用の仕様なので正式登録にお金がかかると思われる． • 登録量が無料としても，登録にかかる作業には費用も時間もかかる． • 結果，フリーのもの(Linux, Free BSD)はUNIX仕様にはオフィシャルには準拠していない．

  43. 簡単なエピローグ

  44. 本授業で理解してほしいこと • プロセス管理 • メモリ管理 • ファイルシステム管理 • デバイス管理 • その他，細かいことは，まぁ関心があったら覚えておいてください． ハードウェアの上で， 複数のプロセスが同時に動き， 時には入出力をしつつ 処理を進めるイメージを頭に描けるようにしてください．

  45. アンケート: 授業等について • 現時点の得点は各自なにを提出したかである程度予測可能と思いますが． • 以前にも申し上げましたが，試験は紙媒体のみ持ち込み可能(無論，教科書も)で，電子機器はダメです． • 個別のアプリ開発というより，情報システムの管理運用や開発を行う仕事をするなら，この授業でやった程度のことは知って無いとまずいことになると思います． • そして，作る仕事より運用管理の仕事のほうが多いような気もします．

  46. アンケート: セキュリティ一般 • 被害を100%防ぐ方法は無いと思います． • 情報セキュリティは例えば会社に忍び込んで書類を盗むなんていう物理的な攻撃も想定してますが，ネットワークセキュリティでは，そういったことは想定してないかと思います． • 入手したプログラムが不正なプログラムであることを完全にチェックする方法は無い． • 例えば「占いのプログラム」だと信じてDLしたものに，他の処理が入っていたとしても，占いだと信じた利用者の思い込み(頭の中)と，実際の処理(プログラム)とをすり合わせる方法など存在しないから．

  47. アンケート: 具体的な事前対策 • 信頼できる相手(会社や組織)からDLするしかない． • 何かDLするついでに他もDLさせられる(たしかBaidu IMEとかそうだったかも)ってのは，確かに悪質ですね． • 良く見ると許諾のチェックとかが入っているので，法的にはDLした人が合意したことになるんでしょう・・・ • 不正プログラムをインストールした場合，その影響を追跡するのは極めて困難な場合が多いため，OSの入れなおし等が必要な場合がある． • 一般の人がPCを利用する際に注意することは，怪しげなサイトのプログラムを入れないこと，怪しげなサイトにアクセスしないことじゃないでしょうか． • セキュリティ上の損害をこうむった場合，なんらかの法的措置にでることは可能と思いますが，詳細はセキュリティの授業で聞いてください．

  48. アンケート: 対策ソフト • 市販のウイルス対策ソフトはファイルや通信内容のデータパターンを見て，悪意あるものか否か予測しています． • パターンは既知のものから作られているため，全く新しい攻撃には無力です． • 最近はブラウザのアクセスも監視しているものもあるはずです． • 個々の対策ソフトがどんなタスクやサービスとして動作しているのかは，ちょっとわかりせん． • 攻撃が増えれば検査するパターンも増えるのでウイルス対策ソフトは重くなる一方でしょう．

  49. アンケート: 対策ソフト • ウイルス対策ソフトはファイルや通信内容を監視していますが，その行為自体がウイルスの行う典型的な行動といえます． • そこで，異なる対策ソフト同士は他者を「ウイルスだ！」と判定する場合が多いです． • Linuxでも対策ソフトはあったほうが良いとおもいますが，やはり利用者が圧倒的に少ないため，攻撃者もあまりターゲットにしてないので問題があまり起きないのだと思います． • また，一応，標準でそれなりにセキュリティ対策がされています． • 手軽？に攻撃を行うソフトも存在するようですので，全くの素人が悪戯することも十分にありえます．

More Related