Rootlinux17: Hypervisors on ARM - Overview and Design Choices by Julien Grall...The Linux Foundation
おまけ話として、mdbmはLinear Hashingと呼ばれるハッシュアルゴリズムの影響を強く受けています。 Linear Hashingの詳細はwikipediaをご覧ください。 http://en.wikipedia.org/wiki/Linear_hashing このアルゴリズムによりmdbmは、扱うデータサイズが大きくなれば、動的にHashTableを拡大することができる非常に便利な特性を持っています。 しかし、冷静になって考えてみてみましょう。このLinear Hasingの管理用のテーブルを走査する計算コストは可能なら避けるべきです。 mdbmをはじめ、多くのKVSでは最終的なデータのサイズの予想がつくのであれば、あらかじめ大きめのサイズでデータベースファイルを作成する方が好ましいでしょう。 この辺の話に興味がありましたら、コードの「hashval_to_pagenum()」
わけあって、 Linux カーネルと FreeBSD カーネルの双方で仕事をした結果、 二つのカーネルで割り込み処理の実装方法が大きく異なっていることに気づきました。 ここでは、それぞれの割り込み処理の仕組みについて、 調べたことを書いてみたいと思います。 割り込みとは、主に入出力ハードウェアによって CPU に送られる処理要求のことです。 一般に、 CPU は入出力ハードウェアよりもずっと高速に動作するので、 入出力処理を行う際に、ハードウェアの動作を待つよりも、 CPU では別の処理を行なっておき、 必要になった時にハードウェア側からの通知を受けて対応する処理を行う方が、 CPU を有効に活用できます。この入出力ハードウェア側からの通知が、割り込みと呼ばれます。 割り込みは、 CPU で動作するカーネルによって処理されることとなります。 ここで、一つの割り込み処理に時間がかかると、他の
先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると: ファイルシステム上に書き込み可能な状態でファイルをオープンする。 一定ペースで、ファイルへ Buffered I/O で書き込み。 ファイルをクローズする。 このとき、特定条件下のXFSでは、(2)の段階では全然フラッシュが発生せず、(3)の段階でまとまったフラッシュが発生するのだそうです。 ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション(ミドルウェア)からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linux
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど1年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
Translation(s): none This page is about optimal set up of an SSD (Solid State Drive). This page should be kept clean enough for beginners to get the most basic idea. Note that some of the configuration improvements listed below happen automatically today for new installations. WARNING Some firmware versions on some SSD models have bugs that result in data corruption when used in certain ways. For
CPUの使用率のグラフからSoftIRQ(Software interrupts)が抜けてしまっていたので追加して、いくつか修正を加えた。 ↑午前2時ぐらいからちゃんとでるようになってる。通信が多いサーバではインパクトがある変更かもしれません。 Net-SNMP(UCD-SNMP-MIB)のCPU使用率に関する項目は UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 428160510 UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 381268 UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 95049839 UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 1753791119 UCD-SNMP-MIB::ssCpuRawWait.0 = Co
Xen Project PVHVM drivers for Linux HVM guests This page lists some resources about using optimized paravirtualized PVHVM drivers (also called PV-on-HVM drivers) with Xen Project fully virtualized HVM guests running (unmodified) Linux kernels. Xen Project PVHVM drivers completely bypass the Qemu emulation and provide much faster disk and network IO performance. Note that Xen Project PV (paravirtua
What is the Xen Project Hypervisor? The Xen Project hypervisor is an open-source type-1 or baremetal hypervisor, which makes it possible to run many instances of an operating system or indeed different operating systems in parallel on a single machine (or host). The Xen Project hypervisor is the only type-1 hypervisor that is available as open source. It is used as the basis for a number of differ
Xen PVHVM drivers for Linux HVM guests This page lists some resources about using optimized paravirtualized PVHVM drivers (also called PV-on-HVM drivers) with Xen fully virtualized HVM guests running (unmodified) Linux kernels. Xen PVHVM drivers completely bypass the Qemu emulation and provide much faster disk- and network IO performance. Note that Xen PV (paravirtual) guests automatically use PV
In this session we examined the Xen PV performance on the latest platforms in a few cases that covers CPU/memory intensive, disk intensive and network intensive workloads. We compared Xen PV guest vs. HVM/PVOPS to see whether PV guest still have advantage over HVM on a system with state-of-the-art VT features. KVM was also compared as a reference. We also compared PV driver performance against bar
Linux には複数のファイルシステムがあります.これらには,仕様としての機能差の他に,品質・安定度に関して大きな差があると考えられています. 今回は,そのあたりを定量的に分析した論文をご紹介. A Study of Linux File System Evolution [キャッシュ] https://www.usenix.org/conference/fast13/study-linux-file-system-evolution 調査の対象は,XFS/Ext4/Btrfs/Ext3/Reiser/JFS の 6 つのファイルシステム.これらについて,Linux 2.6.0 (Dec ’03) から 2.6.39 (May ’11) の間に取り込まれた 5,079 個のパッチを分析しています. パッチの種類 まず,パッチを次の 5 種類に分類しています. Bug バグの修正. Reli
ミリ秒 北海道(さくらインターネットVPS 石狩リージョン)から沖縄(www.ii-okinawa.ad.jp)まで、pingで45ms前後です。 米国カリフォルニア(lg.he.net)から東京(OCN フレッツ光)まで、pingで190ms前後です。 計算結果 BDP(帯域遅延積) = /etc/sysctl.conf # ソケット用バッファメモリ # MAXサイズは、帯域遅延積の2倍 net.core.rmem_max = net.core.wmem_max = net.ipv4.tcp_rmem = net.ipv4.tcp_wmem = # ----- 以下、決めうち ----- # default: 128 net.core.somaxconn = 1024 # default: 32768 61000 net.ipv4.ip_local_port_range= 1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く