Http://www0.info.kanagawa-u.ac.jp/~kaiya/os/
This presentation is the property of its rightful owner.
Sponsored Links
1 / 57

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


  • 64 Views
  • Uploaded on
  • Presentation posted in: General

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 の仕様と標準化 若干のエピローグ 感想へのフィードバック.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


2014 5128517

http://www0.info.kanagawa-u.ac.jp/~kaiya/os/

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

2014/7/17 木曜

2限 2年前期

海谷 治彦

永松 礼夫


2014 5128517

目次

  • 14章 性能

    • 14.1 性能の要素

    • 14.2 システムの性能

    • 14.3 資源の利用率とスループット

    • 14.4 スケジューリング,応答時間

    • 14.5 スループット

    • 14.6 オーバーヘッド

  • 15章 標準化

    • 15.1 日本語サポート

    • 15.2 国際化

    • 15.3 OSの仕様と標準化

  • 若干のエピローグ

  • 感想へのフィードバック


2014 5128517

基本的な考え方

  • システムの性能を決める要因

    • どんな処理(ジョブ)を行うのか?

    • どのくらいの量や頻度で行うのか?

    • どんなハードウェアで行うのか?

    • どのように処理群をスケジュールするのか?

  • 処理の特徴や量

    • 単純な計算を逐次的に行う,いわゆるバッチ処理

    • 対話的な処理が複数同時に動作する.


2014 5128517

誰が性能を計測する?

  • システム全体の性能を横目に見ながらOSは資源割り当てやスケジュールを変える必要がある.

  • その意味からは,性能計測はOSの役割ともいえる.

  • しかし,今日では,専用の性能計測ツール(ベンチマークツール)で計測するのが一般的.


2014 5128517

ハードウェアの能力 1/2

  • プロセッサの性能

    • 単位時間辺りの命令実行数が一般的

      • MIPS Mega Instruction per second 秒あたり何メガ命令を実行できるかという指標

    • とはいえ,プロセッサによって個々の命令の能力が違うので,異なるシリーズ間では比較が困難.

      • 単純な四則演算しか命令として持たないCPUもあれば,命令一発で配列の計算とかできるCPUもある.

    • CPUのクロック数も用いられる.

    • レジスタの数と大きさ

    • バス幅 32bit 64bit


2014 5128517

ハードウェアの能力 2/2

  • メモリ量

    • GB 等.

  • 入出力性能

    • ディスクやネットワークの速度.

  • ディスクの容量

    • GB, TB等


2014 5128517

処理の特性

  • 実行命令数

    • システムコール,数値計算,グラフィクスに特化した数え方もある

  • 利用メモリ量

  • 入出力回数

  • 入出力量

  • ベンチマーク (詳細は後述)

    • システムの性能を測定するための指標.


2014 5128517

システムの性能

  • 教科書での論調は処理(ジョブ)は明確な終わりがあることを仮定している.

    • 昼間の銀行窓口業務を夜間処理する.

    • センーター試験の結果を期日までに出す.

  • しかし,昨今は対話型処理や常時稼働のものが多い.

    • ツイッターやライン等のクライアント通信ソフト

    • ウエブサーバーやプリンタサーバー等

    • オンラインゲーム

  • とはいえ,前者にフォーカスした性能の議論をちょっとみていきます.


2014 5128517

スループット

  • 単位時間あたりの処理数

  • 最も直観的な「システムの速さ」

  • 処理の種類によって当然スループットは変わる.

    • 具体的な処理例はベンチマークのところで.

    • 処理に明確な終わりがないとスループットは出しにくい.

  • 処理によっては資源を100%まで使い切る場合あり,その資源の空き具合がスループットを左右する.

    • このような資源をボトルネック資源と呼ぶ.

    • 通信回線のバンド幅,データバスの転送速度等が現実的な例.


2014 5128517

資源の利用率

  • 順次使用資源

    • プロセッサ,入出力装置等

    • 時間帯を区切り,利用している時間の割合を計算する.

  • 空間資源

    • メモリ,ディスク等

    • 全容量に対して,利用している部分の割合を計算する.


2014 5128517

処理の時間

  • 処理時間の分類1

    • CPU実行時間

    • 入出力時間

    • 待ち時間 (通常はマルチタスクなので)

  • 処理時間の分類2

    • システム時間

      • カーネルモードでの実行時間,要はシステムコール実行時間.

    • ユーザー時間

      • ユーザーモードでの実行時間.

    • 待ち時間

  • 注: 「マルチプログラミング」という用語はOSでは確かに使われるがお勧めしない.(伝統的にこう呼んでるだけ)

    • 処理の実行は「プログラミング」では無いため.

    • プログラミングは「プログラムを書く」こと.


2014 5128517

timeコマンド

中略

合計時間

0.1秒

経過時間

0.22秒

48+47回

プロセスは

停止している


2014 5128517

復習

時分割の考え方 (図7.4改)

時間の流れ

プロセス1

プロセス2

CPU利用時間

プロセス3

プロセス4

数ナノ秒程度


2014 5128517

コンテクスト スイッチ

  • Context Switch

  • TSS等で,あるプロセスから他のプロセスへCPU利用権が移動する際,レジスタの内容等を更新すること.

  • Context

    • あるプロセスが計算を行うためのCPUが持つ状態変数群.

    • 主にレジスタの内容.

  • 本来,プロセスの章で話すべきでした orz


2014 5128517

復習

時分割の考え方 (図7.4改)

時間の流れ

プロセス1

プロセス2

CPU利用時間

プロセス3

プロセス4

コンテクスト

スイッチ

数ナノ秒程度


2014 5128517

端末の応答時間

  • 一般人が直接ふれるプログラムのほとんどは対話型プログラムである.

  • その意味で応答時間は性能を示す重要な指標である.

  • とはいえ,「定番」といえる性能調査法やツールは無いようだ.


2014 5128517

応答時間の簡易モデル

  • 平均応答時間を予測するための計算式

  • 入力としては以下の情報を使う

    • N: 対話するプロセス(人)の数

    • W: 対話中,対話者が考える時間の平均

    • S: 一回の入力を処理するための時間

    • R: サーバー利用率 (0~1) Nが増えれば1に近づく.


2014 5128517

単一の対話者のモデル

  • 以下のように,考えて,処理してを繰り返すと仮定する.


2014 5128517

複数対話者の振る舞いモデル

  • 以下のように思考が終わったらマシンに処理をしてもらう「待ち行列」に並ぶことを想定する.


2014 5128517

処理数と応答時間の関係


2014 5128517

復習

プロセススケジュール

  • プロセスはそれぞれの事情で休止したり停止したりしているが,いつかは条件がそろい実行可能となる.

  • 複数の実行可能プロセスがあった場合,どれから実行するかを決めるのはOSである.

  • この決め方のアルゴリズムがいくつかあり,OSの授業では定番のネタとなっている.


2014 5128517

復習

アルゴリズム紹介 1/2

  • First Come First Served (FCFS)

    • 生成された順番にCPUを割り当てる.

  • Shortest Processing Time First

    • 短いものから片づける

  • Priority Scheduling

    • 予めプロセスに優先度をつける

    • UNIXでも一部採用されている

  • Round Robin

    • 短いタイムスパンで公平に切り替える,TSS的.

    • 今時のOSの定番.


2014 5128517

復習

アルゴリズム紹介 2/2

  • PriorityとRound Robinの組み合わせ

  • Dynamic Dispatching

    • I/Oの利用頻度に基づき,優先度を変更する.

    • 今時のPC等には不向きだが,大型汎用コンピュータでは有効なのかもしれない.

  • Multilevel Feedback Queue

    • 優先度の異なる複数の実行待ちの行列を準備する.


2014 5128517

復習

アルゴリズム全体の雰囲気

  • 多くのプロセスをトータルで短時間で終わらせることに注視している.

    • 銀行の夜間一括処理的なものをスコープとしている.

    • 教科書の図7.7, 7.8等は如実にソレ示している.

  • 今時の対話的な処理の場合「処理の終わり」が明確でないため,実は Round Robin以外,あまり役に立たない.

  • プロセスの応答性能を考慮したアルゴリズムが今後は重要となるでしょう.


2014 5128517

応答時間と経過時間の関係

  • 個々の応答時間の長さによって,応答時間がどうかわってくるかを,スケジュールアルゴリズムによって比較する.

  • 正直,コンテクストスイッチのタイミングと,応答・思考の区切りが一致するとは限らないので,ちょっとこの比較に意味があるか疑問.

  • 応答時間が長い(コンテクストスイッチが長い)と,どのアルゴリズムも不利.


2014 5128517

スケジューリングとスループット

  • 前述のように,処理に明確な終わりが無い場合,スループットの意味はあまりない.

  • 一般利用者の手元で行われる処理では,スループットを議論しても仕方ない.

    • ラウンドロビン以外の選択肢はほぼ無い.

  • 例えば,ビッグデータの解析等では,ラウンドロビンよりもFCFS等のアルゴリズムのほうが良いのかもしれない.


2014 5128517

オーバーヘッド

  • 本来の処理を行う補助のため,OSが行わなければいけない処理をこう呼ぶ.

  • 具体的には,

    • コンテクストスイッチ

    • 仮想記憶からのページの復帰

  • 無論,オーバーヘッドは小さくする必要がある.

    • 前述のtimeの例をみても,経過時間0.22に対して,実際の処理時間は0.1である.


2014 5128517

再掲載

timeコマンド

中略

合計時間

0.1秒

経過時間

0.22秒

48+47回

プロセスは

停止している


Benchmark

ベンチマーク Benchmark

  • システムの性能を測定するための指標.

  • 数多くの指標が存在する.(後述)

  • 実際に指標の値を測定するためのデータとツールが存在する.(後述)

  • 同じベンチマークを異なるシステムで利用することで,システムの優劣を比較できる.


Unixbench

実例 UnixBench

  • 名前の通りUNIX系OS(含むLinux)のベンチマークをするためのツール.

  • 複数の指標を提供し,システムの性能を数値化する,具体的には,

    • 整数演算の性能

    • 不動小数点演算の性能

    • 新規プロセス生成に関する性能

    • ファイルコピーの性能

    • パイプによる通信の性能

    • システムコール呼び出しに関する性能

    • グラフィックス表示に関する性能


15 os

15章 OSと標準化


2014 5128517

文字コード

  • ご存じの通り,コンピュータ内では,(日本語や英語の)個々の文字は,bit列として表現されている.

  • ある文字をどのようなbit列で表現するかを,文字コードと呼ぶ.

  • 残念ながら,日本語の文字の文字コードは多種類あり,統一されているとはいえない.

    • 文字コードによって同じ文字が違うbit列になる.


2014 5128517

日本語の文字コード群

  • JIS X 0208 および ISO-2022-JP

  • シフトJIS

    • CP932, MS932, Windows-31J とほぼ同じ

    • Windowsで採用されている

  • EUC-JP

    • 昔はUNIXで広く採用されていた

  • Unicode

    • 複数言語を同時に表現するのに便利なコード.

    • UTF-8, UTF-16等,いくつかのバリエーションがある.

    • UTF-8が広く使われているような気がする.


2014 5128517

ソフトやツールの対応


2014 5128517

UIについて

  • User Interfaceも言語に合わせて,カスタマイズされているものが多い.

  • 日本語訳が残念で意味がわからん場合もある orz

  • 内部的には英語だが,見た目だけ変えている場合もある.(下図)


2014 5128517

OSの国際化

  • Internationalization

  • I18N とも略される

    • IとNの間の文字が18文字だから(マジ)

  • LOCALE

    • 国に依存する言語,通貨記号,日付の書き順等をコンピュータ内で規定するもの.

      • たとえばドイツでは日月年の順番が一般的.

    • LANGはLOCALEの一部.


Locale

Localeの設定例


Locale1

Localeの設定例

正確にはlocaleではなくLANGを切り替えているが,

上記にように指定した言語で警告が出る.

日本語訳が怪しいのがよくわかる例.

(カナディアンフレンチとフレンチはこのレベルでは一緒ですね)


2014 5128517

参考

エラー,欠陥,障害

  • エラー error

    • ソフトウェア開発中の人間の誤った判断.

    • 例: プログラムミス,仕様の理解誤り.

  • 欠陥 fault (もしくは defect)

    • ソフトウェアが意図した振る舞いをしない原因となったソフトウェアの特性(コードの箇所).

    • 所謂,バグと考えてよい.

  • 障害 failure

    • ソフトウェアが実行中に意図した振る舞いから逸脱したこと.


2014 5128517

OSの外部仕様

  • OSが提供するAPIやサービスがある基準に準拠していれば,OSの変更や更新がしやすい.

    • 例えば,APIの名前と引数が統一されていなければ,OS毎にアプリケーションプログラムを作り直す必要がある.

  • そういった意味で,OSの仕様を標準化することが重要となる.


2014 5128517

そもそも仕様とは何か?

  • Specification

  • 仕様を書類にしたものが仕様書と呼ばれる.

  • 「あるシステムやプログラムが,どのような環境下で,何をするのかの記述」

  • 機能仕様

    • 狭い意味の仕様.

    • 大まかにいうと,何を入れると何が出てくるか定めたもの.

    • 例: 「read関数はファイル名を与えると,ファイルの中身のデータを得られる」

  • 非機能仕様

    • 機能仕様に加えて,応答の速さや,信頼性を定めたもの.

    • 例:「read関数は1ms以内に必ず応答し,99.99%の精度で正しいデータを返す」 (実際のreadはこんな仕様はありません)


2014 5128517

OSの仕様の例

  • POSIX

    • UNIX系OSをベースとしたAPIの仕様.

    • Windows NTも POSIX 1.0 に準拠している.

  • X/OpenのUNIX

    • Single UNIX Specification (SUS)

    • UNIX98, UNIX03等の呼称で呼ばれる.

    • 商用の仕様なので正式登録にお金がかかると思われる.

      • 登録量が無料としても,登録にかかる作業には費用も時間もかかる.

    • 結果,フリーのもの(Linux, Free BSD)はUNIX仕様にはオフィシャルには準拠していない.


2014 5128517

簡単なエピローグ


2014 5128517

本授業で理解してほしいこと

  • プロセス管理

  • メモリ管理

  • ファイルシステム管理

  • デバイス管理

  • その他,細かいことは,まぁ関心があったら覚えておいてください.

ハードウェアの上で,

複数のプロセスが同時に動き,

時には入出力をしつつ

処理を進めるイメージを頭に描けるようにしてください.


2014 5128517

アンケート: 授業等について

  • 現時点の得点は各自なにを提出したかである程度予測可能と思いますが.

  • 以前にも申し上げましたが,試験は紙媒体のみ持ち込み可能(無論,教科書も)で,電子機器はダメです.

  • 個別のアプリ開発というより,情報システムの管理運用や開発を行う仕事をするなら,この授業でやった程度のことは知って無いとまずいことになると思います.

    • そして,作る仕事より運用管理の仕事のほうが多いような気もします.


2014 5128517

アンケート: セキュリティ一般

  • 被害を100%防ぐ方法は無いと思います.

  • 情報セキュリティは例えば会社に忍び込んで書類を盗むなんていう物理的な攻撃も想定してますが,ネットワークセキュリティでは,そういったことは想定してないかと思います.

  • 入手したプログラムが不正なプログラムであることを完全にチェックする方法は無い.

    • 例えば「占いのプログラム」だと信じてDLしたものに,他の処理が入っていたとしても,占いだと信じた利用者の思い込み(頭の中)と,実際の処理(プログラム)とをすり合わせる方法など存在しないから.


2014 5128517

アンケート: 具体的な事前対策

  • 信頼できる相手(会社や組織)からDLするしかない.

  • 何かDLするついでに他もDLさせられる(たしかBaidu IMEとかそうだったかも)ってのは,確かに悪質ですね.

    • 良く見ると許諾のチェックとかが入っているので,法的にはDLした人が合意したことになるんでしょう・・・

  • 不正プログラムをインストールした場合,その影響を追跡するのは極めて困難な場合が多いため,OSの入れなおし等が必要な場合がある.

  • 一般の人がPCを利用する際に注意することは,怪しげなサイトのプログラムを入れないこと,怪しげなサイトにアクセスしないことじゃないでしょうか.

  • セキュリティ上の損害をこうむった場合,なんらかの法的措置にでることは可能と思いますが,詳細はセキュリティの授業で聞いてください.


2014 5128517

アンケート: 対策ソフト

  • 市販のウイルス対策ソフトはファイルや通信内容のデータパターンを見て,悪意あるものか否か予測しています.

  • パターンは既知のものから作られているため,全く新しい攻撃には無力です.

  • 最近はブラウザのアクセスも監視しているものもあるはずです.

  • 個々の対策ソフトがどんなタスクやサービスとして動作しているのかは,ちょっとわかりせん.

  • 攻撃が増えれば検査するパターンも増えるのでウイルス対策ソフトは重くなる一方でしょう.


2014 5128517

アンケート: 対策ソフト

  • ウイルス対策ソフトはファイルや通信内容を監視していますが,その行為自体がウイルスの行う典型的な行動といえます.

    • そこで,異なる対策ソフト同士は他者を「ウイルスだ!」と判定する場合が多いです.

  • Linuxでも対策ソフトはあったほうが良いとおもいますが,やはり利用者が圧倒的に少ないため,攻撃者もあまりターゲットにしてないので問題があまり起きないのだと思います.

    • また,一応,標準でそれなりにセキュリティ対策がされています.

  • 手軽?に攻撃を行うソフトも存在するようですので,全くの素人が悪戯することも十分にありえます.


2014 5128517

アンケート: モバイルコード

  • モバイルコード(javascript等)のうま味は,

    • 一々インストールする必要が無いこと,ネカフェやホテルでもOK

    • 手元のパソコンのディスクを圧迫しないこと,

    • バージョンアップが楽(というか自動)なこと

      等だと思います.

  • Javascriptはコンパイル不要なことが問題ではなく,ページを見た時点で実行されているという危うさ(たまたま怪しいサイトをクリックした程度でも)が問題となります.

  • 今日のWebアプリケーションはブラウザを動かしている自身の権限でファイルシステムに対してアクセス可能なため,その場でダウンロードして実行されたプログラム(Javascript等)に悪意があると,自分で自分の首を絞めるのと同じことになります.


2014 5128517

アンケート: 認証関係

  • 認証方式の詳しい話はセキュリティの授業で聞いてください.

  • iphoneは知りませんが,andoridは利用前に利用者登録しましたよね?

    • 当然,貴方の端末は貴方を認証してます.

  • Vistaは一瞬しか使いませんでしたが,無駄に重いことに加え,何かする毎に利用者に確認を行うDAC的な振る舞いが面倒なことも起因したと思います.


2014 5128517

アンケート: 公開鍵暗号

  • 公開鍵暗号では,データを受け取る人間だけが秘密鍵をもっており,それを外部にもらす必要は一切ありません.

  • 公開鍵は,第三者に見られてもよいものなので,普通にメール等で送っても平気ですし,自分のWebサイトにおいておいても平気です.

  • スライドでは公開鍵は第三者が配布するように書いてありますが,実際には,受け手の組織・会社のサイトから配布していることが多いと思います.

  • 秘密鍵は開ける当人しか知らないことになってます.

    • そーじゃないと機能しない.

  • 公開鍵暗号が安全に機能しているかどうかはウイルス対策ソフトはチェックしてくれません.


2014 5128517

アンケート: 公開鍵暗号

  • SSLの通信では公開鍵暗号が使われているみたいなので,ごく普通の利用者でもhttpsのアクセスを通して公開鍵暗号を日常的に使っていることになります.

  • dropboxではSSLを使ってるみたいなので,公開鍵暗号が利用されていることになりますね.

  • パスワード付きファイルは共通鍵による暗号化が普通ではないかと思います.


2014 5128517

アンケート: アクセス制御

  • MACは所有者がACLを事前に決めてその適用をシステムに委ねるのに対して,DACはアクセス毎に所有者がその可否が判断するという感じの違いです.

  • Access Control Matrix は,空白のセルが多い行列になりやすいので,保存データ形式としては非効率的といわれています.


2014 5128517

アンケート: その他

  • ワンクリック詐欺も典型的な自分で自分の首を絞める例ですね.

  • セキュアなコードを書くためのガイドライン的な本はたくさんでてますので,興味がある方は読んでみてください.

  • WindowsやLinux等,個々のOSに熟知していない人は,用途不明のファイルを消したりすることはしないようにしてください.

  • Windows Media Player を含むアプリを作りたいなら,MSの提供する言語系(VC++やC#)でないと厳しいんじゃないでしょうか.

  • ハードウェアRAIDは使ったことなないのでわかりませんが,確かに負荷は少ないと思います.


2014 5128517

半年間,ご苦労さま

アンケートのほう,

よろしくご提出ください


  • Login