I/Oの「レスポンス」と「スループット」とは？ 連載第1回でご紹介したように、大規模データ処理を行うデータベースで一番大きな課題となるのは、ディスクI/O（以降、単にI/Oと表記します）のボトルネックです。数百GBやTBクラスの巨大データウェアハウスの場合、SQLが実行される時間のほとんどがI/Oを待つ時間となっているケースが多々あります。 ここでは、I/Oボトルネックが発生するおもな原因を、「レスポンス」と「スループット」という概念から見ていきましょう。それぞれ、広義では以下の定義となります。 I/Oレスポンス＝I/O要求処理にかかる応答時間 I/Oスループット＝単位時間当たりのI/O処理量 Oracle Databaseに当てはめると、以下のように定義できます。 I/Oレスポンス＝1データブロックの読み出しや書き込みにかかる時間 I/Oスループット＝単位時間あたりの読み出しや書き込み
スマートフォンサイトに向けての最適化だったり、 Webページのレイアウトの変更だったりで、 同じ画像でも様々なサイズを利用することがある。 サイトの運用を続けていると、 同じ画像でも数通りのファイルを保存していて、 ファイル数が大量になってIOがキツくなってきた。 数多くなるとIO辛いから、 ファイル増やさないように気をつけてね、 と社内で言い続けていたら… Webサイトでは、本来小さい画像で良いところに 大きい画像を使用して、 JavaScriptでリサイズする処理が多用されはじめ、 今度は転送量が増加しはじめて、 これ以上増えるとデータセンターの月額費用が 増加してしまいそうに…。 なんとかせねば！と対応をはじめるわけです。 そこでまず最初にやったのが、 本当は速いImageMagick と同じように、Apacheモジュールを自作して、 ImageMagic
10月30日にPythonを突発的に始めて1ヶ月がたった。 始めて2週間で学校の課題(Webアプリ)を書いたりした。 技術的にためになる話はないけど、まあ日々のログとして書いておく。 経緯 以前からPythonはやろうと思ってた 学校の教養科目でPythonを書く科目をとってみた 以下は時期的な話。 学科の演習(https://www.db.soc.i.kyoto-u.ac.jp/lec/le4db/)でWebアプリをJavaで書いていたが、Javaプログラム中にhtmlとかSQLとか書いてたらやる気がなくなってきた ちょうどそのころPython始めるならまず何を読むべきかなどを情報収集していたら、みんなのPython Webアプリ編がHTML版として無料公開された(みんなのPython Webアプリ編をHTMLで読めるようにしました | TRIVIAL TECHNOLOGIES 4 @a
「インターネットサーバでのPthreadとepoll」の記事（以下、前記事と呼びます）を書いた時点では、手元の環境がプアなためマルチプロセス/マルチスレッドを採用したサンプルプログラムの真価を発揮させられず、適切に比較できませんでしたが、その後デュアルコアマシンを借りることができたので、改めて比較してみました。 また、比較の際にサンプルプログラムに追加したダミー処理ではシグナルも使用したので、やはりLinuxに追加された signalfd(2) もepollによるイベントループで処理してみました。 本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。 [ サンプルコード ] 前記事のサンプルプログラム 前記事 ではHTTPサーバを例に並列性/多重性のサンプル実装を5種類提示しました。簡単に振り返ります。サンプルプログラムがデュアルコアシス
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
プロセスがブロックする要因の一つにファイルI/Oがあります。これを同期I/Oと言いますが、POSIXではAIO（非同期 I/O、Asynchronous I/O）も定義しており、I/O中でもプロセスがブロックせず他の処理を進められるようになります。 本記事ではバッファキャッシュからファイル I/Oを解説し、Linuxのio_submit(2)を用いたPOSIX準拠のAIOライブラリを試作してみます。 ファイルI/Oとバッファキャッシュ io_submit(2)ではDirect I/Oを用いますが、ライブラリの試作へ進む前にまずファイルI/Oのバッファ（バッファキャッシュ）について整理します。実は単にバッファと言ってしまうと誤解される場面が多くあり、例えばプログラミング入門一般としてファイルI/Oを取り上げる際には、 CPUの動作は速い。ディスクの動作は遅い。 両者の間に速度差を緩和する緩衝
PCIe接続のフラッシュストレージベンダとして急成長してきたFusion-ioを、フラッシュメモリ関連製品で知られる米SanDiskが買収することが発表されました。 買収価格は1.1ビリオンドル（約1100億円）。 News Release : SanDisk Signs Definitive Agreement to Acquire Fusion-io Fusion-ioは今月、新世代製品となるPCIeフラッシュストレージの新シリーズ「ioMemory Atomic Series」の発表と、「アプリケーションを速くすることにフォーカスする」という戦略を明確にしたばかりでした。 Fusion-ioは2005年にDavid Flynn氏とRick White氏が創業、2009年にはチーフサイエンティストとしてSteve Wozniac（スティーブ・ウォズニアック）氏が入社し、2011年にニュ
golang が提供するインタフェースの中で代表的な物の使い方をまとめてみる。 io.Reader type Reader interface { Read(p []byte) (n int, err error) } ご存じ io.Reader。このシグネチャの Read を実装しておけば golang のありとあらゆる入力機能に対して自分のコードを提供する事が出来る。 例えば永遠に「おっぱい」と言い続ける Reader だと以下の様な実装になる。 package main import ( "io" "os" ) var text = []rune("おっぱい") type OppaiReader struct { n int } func (r *OppaiReader) Read(p []byte) (int, error) { in := len(p) nw := 0 for i
「働き方」を取り巻く環境には、科学技術の発展も大きく関わります。数十年前までなかったPCとインターネットが世界を、そして仕事の様相を変えました。次に来たるはロボットや機械の進化なのでしょうか。Kotaku JAPANのこちらの記事より、「機械化が進んだ未来でも働き口はある」という考察をお届けします。 工場の働き手がロボットに職を奪われ始めたのは20年、30年前の話。今やあらゆる分野で機械化が進み、専門的な仕事につく人々でさえ、のんびりとはしていられなくなってきました。 今この記事を書いている訳者も、機械翻訳がどうかこのままキテレツな翻訳文を作り続けてくれますようにと願うばかりです。 しかし「io9」によると、機械化が進んでも働き口の心配はいらないのだそう。今回はこれからの時代にぴったりな、人間にしかできない仕事をご紹介します。 ガイド／アドバイザー／コンサルタント 呼び方はいろいろあります
GMOさんのところで、ioDrive＋MySQLの発表をしてまいりました。 前回のFluentdから中4日で登壇という恐ロシアなスケジュールに真っ白な灰となっております。 １番手だったので基本を抑えつつ尖り気味のところまで入れてしまったせいで、40分のところを53分使い、さらに質疑応答で1時間以上になり、他の発表者や参加者にご迷惑を、そしてピザを冷えさせて申し訳ありませんでした。が、資料自体はぼちぼちな出来になったと思いますのでサクッと公開しておきます。 事前にページを削りとってしまったり、早送りで説明してしまった部分があるので補足したいところなのですが、燃え尽き症候群中なのでMySQL関連は後で少しずつ書いていけたらと思います。 戦利品 Fusion-IO社のサンタクロースと言われる例の方が、登壇者にプレゼントをしてくれました。 ゴルフシャツですが Mサイズ Woman用で、微妙に形が女
Fusion-ioは単なる高速ドライブではない。フラッシュを拡張メモリ領域として利用できるSDK公開。内部へネイティブアクセス可能に ioDrive製品は、サーバのPCIeインターフェイスに接続するフラッシュドライブで、その桁外れな高速性ゆえに注目されてきました。 今回発表されたSDKは、アプリケーションから内部のフラッシュメモリ空間（同社の呼称でioMemory）に直接アクセス可能にするものです。不揮発性であるフラッシュメモリの特性を活かし、API経由で主に以下の機能を提供します。 アプリケーションからioMemoryを拡張メモリ空間として利用可能 アプリケーションからioMemoryを不揮発性のメモリ領域として利用可能 超高速なキーバリュー型データストアとして利用可能 ioMemoryの状態をアプリケーションが取得可能 これによりアプリケーション自体が高速で実行可能になるほか、アプリケ
サーバ周りの勉強していると、たまにselectとかepollとか言葉が出てきて、理解できてなかったので調べてみた。 I/Oの多重化 例えばサーバ周りの実装を、特に何も考えずにやると、I/Oでブロッキングが発生し、一つのクライアントとしか通信できないということが起こります。これを解決するために fork threads I/Oの多重化 非同期I/O といった方法があります。 この中のI/Oの多重化を実装するためのシステムコールとして、select, poll, epoll, kqueueなどは実装されているようです。 少し調べてみると、次のような記述のような機能をそれぞれが実装するようです。 プログラムで複数のファイルディスクリプタを監視し、 一つ以上のファイルディスクリプタがある種の I/O 操作の 「ready (準備ができた)」状態 (例えば、読み込み可能になった状態) になるまで待つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger