CPUの性能を調べる方法を紹介、というかメモです。 次の記事が長くなりすぎないように分割したやつ。 CPU Benchmark Charts 最も手軽にCPU性能を調べられるのが、このサイトです。 PassMark Software – CPU Benchmark Charts 私の場合は、サイドバーの『Single Thread』を眺めたり、ヘッダの検索から型番のページに行って、Single Thread の値を確認したりします。 マルチコアでの総合力も大事なんですが、個人的には Single での性能がレスポンスタイムなどに直結するので、重要視しています。 CPU情報 /proc/cpuinfo Linux なら、これで大体の情報を確認できます。 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
この前、若手に聞かれたので、ここにも書いておく。 好みでは有るが、可能な限り数字のみで標準出力に出せるようにしておくと、スクリプトの中などで並列実行数を動的に定義しやすい。 ちなみに下記の前提は、CentOS 6.6 & 56コア(！)のサーバで確認している。 nproc # nproc 56一番簡単なやつ。 getconf # getconf _NPROCESSORS_ONLN 56getconfでも拾える。 /proc/cpuinfo # cat /proc/cpuinfo | grep -c "processor" 56皆さん、ご存知の通り、 /proc/cpuinfo は多くのCPU情報を取得することが出来る。 余談だけど、 /proc/cpuinfo に含まれる"physical id"はどの物理ソケットか、とか、"core id"を見ると物理コア(HT関連などで論理コアの紐付き
某所で話題になってたので。3.17.1 kernel で試してます (Plamo Linux 5.2) docker でも何でもなくて単に Linux kernel の cgroup がちゃんと動いてるかって話なんですが。:-) (2014-10-29 追記) なんか docker ってキーワード入ってるからかわかりませんが、多数アクセスいただいていますね。CFS Throttle の機能自体はもう 3 年近く前に試してちゃんと動いていたテストそのままです。dockerを使って試してるか、直接 cgroup と普通のプロセスで試してるかの違い。gihyo.jp での連載でもそのまま載ってます :-) Linux 3.2 の CFS bandwidth control (2) - TenForwardの日記 第4回 Linuxカーネルのコンテナ機能［3］ ─cgroupとは？（その2）：LX
以前(2010年)に「アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件」というエントリにてCPUのコアが増えても割り込み処理が分散されないのでスケールされないと書いたけど、その後Linux KernelにRPS/RFSなる機能が追加され、割り込み処理が分散できるようになり、CentOS 6.2 でも使えるらしいので試してみました。 RPS/RFSについての紹介は VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました http://d.hatena.ne.jp/syuu1228/20110722/1311322653 Linux内核 RPS/RFS功能详细测试分析 http://www.igigo.net/archives/204 が詳しい。2番目のはほぼ読めないけど、性能比較のグラフが分かりやすい。 今回試したサーバは、 OS: C
Kernel/VM Advent Calendar ４日目: Linuxのネットワークスタックのスケーラビリティについて - かーねる・う゛いえむにっきで書いたReceive-Side Scalingの記述が未だ理解が足りず不正確だと思ったので、調べ直してみてる所。 Multi-queueなNICってなに RPS提案のメールにこんな事が書いてある： This effectively emulates in software what a multi-queue NIC can provide, but is generic requiring no device support. 要約すると「multi-queue NICが提供している機能をソフトウェアエミュレートするのがRPS」 →じゃあmulti-queueなNICってどれで、どんな機能を提供してるんだろう？ それらしいNICを探して
この記事の続きになる訳だが、いくらSolaris最強って言っても、大手メーカーがこぞってつつき回して性能改善したり機能追加したりしてるはずのLinuxで何も対策が打たれてない訳が無いよね。じゃあどうなってるんだろう、って話。 例によって、Linuxとか全ッ然知らないので、間違ってたらツッコミ下さい。 ポーリングとパケット処理のパス 殆どここで解説し尽くされてる。 Linuxにも動的ポーリングの実装（Solarisで言ってる動的ポーリングと同じものとは限らないが…）があって、NAPIとか呼ばれてるらしい。 NAPIを実装するドライバでは、こんな手順で受信処理を行ってる。 ハードウェア割り込みを受け、割り込みハンドラを起動 ハードウェア割り込みを禁止、ポーリングをスケジュール ソフトウェア割り込み経由でNAPIのポーリングルーチンを起動 ドライバにポーリングを指示 この時、適切な性能を確保する
【お願い】私はLinuxカーネルもネットワーク周りも素人です。ここに書いてある事は間違えている可能性もあるのでおかしいなと思ったらすかさず突っ込んでください。宜しくお願い致します。 今回は、この記事の内容を全面的に見直して、再度Linuxのネットワークスタックのスケーラビリティについてまとめようと思います。 従来のLinuxネットワークスタック＋従来のシングルキューNIC 以下の図は従来のLinuxネットワークスタック＋従来のシングルキューNICで、あるプロセス宛のパケットを受信している時の処理の流れを表している。フォワーディングの場合やプロトコルスタック内の処理は割愛した。 プロセスがシステムコールを発行してからスリープするまで プロセスは、システムコールを通してカーネルにパケットを取りに行く。 パケットはソケット毎のバッファに貯まるようになっているが、バッファが空だったらプロセスはパケ
Linuxカーネル*1には、CPUが持っている動的なクロック周波数や電圧(対応している場合)の変更機能を利用するためのcpufreqという仕組みがある。 (2014/11/14)本記事の内容は最新ではないため、まとめドキュメントの各セクションを参照。 CPUドライバ カーネルの設定 クロック周波数の決定 governorの手動変更 cpufreqに関する現在の各種状態の取得 ondemand governorでの動作時において、CPUクロックを上げるCPU使用率のしきい値 cpufreqdで実用的な動的クロック変更を行う 設定 設定のテスト プロファイルの手動変更 CPUドライバクロックや電圧の変更をする方法はCPUによって違うため、CPUの種類ごとにデバイスドライバが用意されている。cpufreqを使用するには、 使用しているCPUがクロックや電圧の変更をする機能を持っていて、BIOSで
ここ最近ロードアベレージについて調べています。本業の Oracle サーバのロードアベレージが最近高いのです。本日の夜はまだまだ安定した値。下のグラフは loadavg x 100 のグラフ。 Dual Core Xeon が２枚のサーバなので一般的なロードアベレージの解釈からすると４以下なら安全圏。ここ最近は６〜８という数値が多いわけですが、実際の体感的なパフォーマンスがそれほど悪いるわけではなくと言うか全然重く無くってイマイチ良く判らない。CPU とか他の数値は至って安全圏のものばかり。仕方がないので kernel 2.6 のソースを眺める日々がここ数日。とにかく kernel まわりの記事を手当たり次第読んでみました。 マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
