Debianにmediawiki 1.24.1をインストール

WikipediaのCMSであるMediaWikiを使ってみようと思いました。入れてみた感想としては微妙な感じですが。。。

– デザインが古臭い
– ファイルのアップロードが編集中の画面で完結せず、ファイル名のコピーアンドペーストなどが必要で煩雑
– もっさりしていて遅い

などなどです。どうやったらこんなに遅くなるのかってぐらい遅いですね。wrkでベンチマークしてみますとOpteron 3280マシンで5~10req/secという遅さです。1reqに1sec近くも掛かっています。。。単なるHello, PHPと返すPHPスクリプトは平均16.78msで応答するのですが(一番下にベンチマーク結果を置いておきます)。

想定環境は

– Debian系
– Apache

です。まあともかく入れてみます。MediaWikiはPHPとMySQLに依存するので、それらをまず入れます。以下はrootでやってください。

必要なライブラリやソフトウェアのインストール↓

$ sudo aptitude install mysql-server php5 imagemagick php5-imagick php5-mysql php-apc php5-intl
$ cd /var/www/
$ wget http://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.1.tar.gz
$ tar zxvf mediawiki-1.24.1.tar.gz
$ mv mediawiki-1.24.1 wiki

MySQLの設定(username=wikiuser, password=wikipassword, database name = wikidbとします)↓
$ service mysql start
$ mysql -uroot -p
mysql> GRANT ALL PRIVILEGES ON *.* TO wikiuser@'localhost' IDENTIFIED BY 'wikipassword' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE DATABASE wikidb CHARACTER SET utf8;
Query OK, 1 row affected (0.00 sec)

ブラウザで、http://<マシンのIPアドレス>/wiki/にアクセスして、「Please set up the wiki first.」をクリック

Your language (インストール時に使う言語)とWiki languageを選択、ひとまず英語で良いと思う

右下のcontinueをクリック

MySQLのセッテイングで、Database host→127.0.0.1、Database name→wikidb、Database table prefixは何も入力しない、Database username→wikiuser、Database password→wikipassword として右下のcontinueをクリック

Storage engineはInnoDBを選択、Database character setはBinaryを選択 (utf-8でもいいかも)して右下のcontinueをクリック

Name of wikiを適当に入力、たとえば Group Wiki など。Project namespaceはよく分からないので Same as the wiki nameを選択、Your Username、Passwordを適当に入力、email addressは自由、そして右下のcontinueをクリック

User rights profileはAccount creation requiredが良いかと。その他いろいろと見て設定してcontinue

Installと出るのでcontinue(ちょっと時間が掛かります)

LocalSettings.phpというファイルがダウンロードされる。その内容をコピーして、/var/www/wikiに、vi LocalSettings.phpとして貼り付ける。

再度ブラウザでアクセス

右上のLog inをクリックしてログイン

以上です。

蛇足

ベンチマークしてみます。今回簡単のため、一台のマシン(Opteron 3280)でサーバーも計測も行っています。MediaWikiの入っているマシンのIPアドレスを192.168.1.2とします。

– Hello, PHP!という文字列を返すだけのhello.php (http://192.168.1.2/hello.php)
– MediaWikiで作ったMemberというページ (http://192.168.1.145/wiki/index.php/Member)

の比較をしてみます。まずはhello.phpの結果↓

$ curl http://192.168.1.2/hello.php
Hello, PHP!

$  ./wrk -c 100 -d 5 -t 3 http://192.168.1.2/hello.php
Running 5s test @ http://192.168.1.2/hello.php
  3 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    16.78ms   86.70ms 532.88ms   96.42%
    Req/Sec    10.28k     3.43k   21.11k    67.19%
  143600 requests in 5.00s, 28.10MB read
Requests/sec:  28717.53
Transfer/sec:      5.62MB

次に、Memberの結果です↓。

$ curl http://192.168.1.145/wiki/index.php/Member
中略
$ ./wrk -c 5 -d 5 -t 1 http://192.168.1.145/wiki/index.php/Member
Running 5s test @ http://192.168.1.145/wiki/index.php/Member
  1 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   902.04ms  135.29ms 997.71ms  100.00%
    Req/Sec     5.00      0.00     5.00    100.00%
  27 requests in 5.22s, 386.31KB read
Requests/sec:      5.17
Transfer/sec:     73.96KB

↑いやあ、酷いですね。APCが有効になっているはずなのですが。。。

【Redis】Raspberry Pi 2 Model Bのベンチマーク【UnixBench】

大幅に性能が向上したラズパイ2,さっそくベンチマークしてみます。ひとまず、

– メモリ帯域
– ディスク帯域
– Redis
– UnixBench

です。

– ラズパイ2のセットアップは前回の記事にあります→ Raspberry Pi 2 Model Bのセットアップ
– ラズパイ2とH2Oを使って毎秒2万リクエストを達成した記事は→ Raspberry Pi 2 Model B と 高速HTTPサーバーH2Oで毎秒2万リクエスト

まずは帯域系を計測してみます。

$ uname -a
Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux

$ dd if=/dev/zero of=/dev/null bs=1024K count=100000
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 100.467 s, 1.0 GB/s

$  dd if=/dev/zero of=deleteme bs=32M count=100
100+0 records in
100+0 records out
3355443200 bytes (3.4 GB) copied, 288.803 s, 11.6 MB/s

↑帯域等は旧版とさほど変わりがない印象です。microSDカードは、東芝のSD-C016GR7AR040Aです。16GBで、パッケージにはclass10、Read 40MB/sと書いてあります。たしか900円ぐらいでした。ただし、ラズパイ2はUHS-Iに対応していない感じで、40MB/sも出ませんね。というわけで、class10のmicroSDカードで十分だと思います。お店によっては32GBを1000円以下で購入できるのではないでしょうか。

次はRedisです。

$ wget http://download.redis.io/releases/redis-2.8.19.tar.gz
$ tar zxvf redis-2.8.19.tar.gz
$ cd redis
$ make
$ ./src/redis-server
$ ./src/redis-benchmark -q
PING_INLINE: 13993.84 requests per second
PING_BULK: 13943.11 requests per second
SET: 13133.70 requests per second
GET: 14062.72 requests per second
INCR: 12559.66 requests per second
LPUSH: 12680.70 requests per second
LPOP: 13054.83 requests per second
SADD: 13419.22 requests per second
SPOP: 13823.61 requests per second
LPUSH (needed to benchmark LRANGE): 12768.13 requests per second
LRANGE_100 (first 100 elements): 4423.60 requests per second
LRANGE_300 (first 300 elements): 1672.35 requests per second
LRANGE_500 (first 450 elements): 1155.72 requests per second
LRANGE_600 (first 600 elements): 871.10 requests per second
MSET (10 keys): 7089.68 requests per second

↑旧版ラズパイでは、GETは約2000req/secでした。だいぶ向上していますね。ただし注意点として、旧版ラズパイは1コアであり、1コアでベンチマークのserver/clientの両方を動かしていたわけでその影響でより遅く見えるのもあるかと思います。ラズパイ2のRedisベンチマークでは、Redis自体はマルチコア非対応で1コアで動くこと、さらにラズパイ2は4コアあるので、server/clientにそれぞれ1コアずつ割り当てられて、正確な計測が出来たという可能性があります。

次はUnixBenchです。

$ wget http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz
$ tar zxvf UnixBench5.1.3.tgz 
$ cd UnixBench
$ ./Run
========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: raspberrypi: GNU/Linux
   OS: GNU/Linux -- 3.18.7-v7+ -- #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015
   Machine: armv7l (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   CPU 1: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   CPU 2: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   CPU 3: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   10:27:40 up  1:03,  2 users,  load average: 0.19, 1.35, 1.49; runlevel 2

------------------------------------------------------------------------
Benchmark Run: Sat Feb 14 2015 10:27:40 - 10:55:53
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        2956973.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      498.2 MWIPS (9.9 s, 7 samples)
Execl Throughput                                360.6 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         72541.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           20956.4 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        189365.6 KBps  (30.0 s, 2 samples)
Pipe Throughput                              175922.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  31694.4 lps   (10.0 s, 7 samples)
Process Creation                               1234.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1107.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    316.1 lpm   (60.1 s, 2 samples)
System Call Overhead                         410678.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    2956973.9    253.4
Double-Precision Whetstone                       55.0        498.2     90.6
Execl Throughput                                 43.0        360.6     83.9
File Copy 1024 bufsize 2000 maxblocks          3960.0      72541.4    183.2
File Copy 256 bufsize 500 maxblocks            1655.0      20956.4    126.6
File Copy 4096 bufsize 8000 maxblocks          5800.0     189365.6    326.5
Pipe Throughput                               12440.0     175922.0    141.4
Pipe-based Context Switching                   4000.0      31694.4     79.2
Process Creation                                126.0       1234.8     98.0
Shell Scripts (1 concurrent)                     42.4       1107.6    261.2
Shell Scripts (8 concurrent)                      6.0        316.1    526.8
System Call Overhead                          15000.0     410678.3    273.8
                                                                   ========
System Benchmarks Index Score                                         170.5

------------------------------------------------------------------------
Benchmark Run: Sat Feb 14 2015 10:55:53 - 11:24:12
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       11802735.6 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1988.5 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1359.5 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        115667.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           32669.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        313050.3 KBps  (30.0 s, 2 samples)
Pipe Throughput                              698307.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 122975.8 lps   (10.0 s, 7 samples)
Process Creation                               2890.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2536.4 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    333.3 lpm   (60.3 s, 2 samples)
System Call Overhead                        1579952.2 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   11802735.6   1011.4
Double-Precision Whetstone                       55.0       1988.5    361.5
Execl Throughput                                 43.0       1359.5    316.2
File Copy 1024 bufsize 2000 maxblocks          3960.0     115667.5    292.1
File Copy 256 bufsize 500 maxblocks            1655.0      32669.0    197.4
File Copy 4096 bufsize 8000 maxblocks          5800.0     313050.3    539.7
Pipe Throughput                               12440.0     698307.4    561.3
Pipe-based Context Switching                   4000.0     122975.8    307.4
Process Creation                                126.0       2890.8    229.4
Shell Scripts (1 concurrent)                     42.4       2536.4    598.2
Shell Scripts (8 concurrent)                      6.0        333.3    555.6
System Call Overhead                          15000.0    1579952.2   1053.3
                                                                   ========
System Benchmarks Index Score                                         438.0

旧版ラズパイのSystem Benchmarks Index Scoreは72.9〜104.7だったので、4〜6倍程度ですね。もちろん、UnixBenchがコンピュータの性能指標の全てではありませんが。。。

Raspberry Pi 2 Model Bのセットアップ

覚書です。ひとまず使える状態に持っていく方法です。

http://www.raspberrypi.org/downloads/ のNOOBSをダウンロード

NOOBSを解凍してその中身を、microSDカードのルートディレクトリに入れる

ラズパイにmicroSDカードとHDMIケーブルとキーボードとマウスを挿して、microUSBケーブルを電源につないで起動

GUIが出るので、Raspbianをインストール

しばらく待つと終了

Raspbianが起動する。コンソール上にGUIがでるが、特に設定せずにtabを押してfinishを選択してenter。

コンソールで、$ sudo su として、次に# passwdとしてルートパスワードを変更

コンソールで、$ aptitude update; aptitude upgrade -y

コンソールで、$ aptitude install vim

コンソールで、ネットワークを設定する (静的に割り当てる場合。DHCPならば何もしなくてよい)

– 割り当てるIPアドレス: 192.168.1.146
– ネットワーク: 192.168.1.0
– ネットマスク: 255.255.255.0
– ブロードキャスト: 192.168.1.255
– ゲートウェイ(ルーター): 192.168.1.1
– DNSサーバー: 192.168.0.1
としたい場合は、

$ vi /etc/network/interfaces 
$ cat /etc/network/interfaces 
auto lo

iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.146
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 192.168.0.1

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

$ service networking restart

とする。

おわり

【LAN】ローカルで好きな名前を使う【Unbound、DNS】

追記@2015-01-04

こういった用途には、DNSMasqというフリーのソフトウェアがあることを知りました。
主にLocalのDNSとDHCPサーバの役割のようです。LinuxやBSDで動くそうです。
オープンソースのwifiルーターのファームウェア、dd-wrtには標準で付属していますのでこれを使うのが最も容易かもしれません。

dnsmasq でDNSのキャッシュサービスを気軽に動かす
http://www.usupi.org/sysad/225.html
↑とても分かりやすい記事ですので挙げておきます


管理出来るローカルエリアネットワークで、好きな名前を使いたくなる時があります。たとえば、「wiki.lo」でwikiが動いているサーバーに飛んだり(lo=localです)、「gitlab.lo」でgitlabが動いているサーバーに飛んだりできれば楽ですね。

こういったことを実現するのに適した、Unboundというソフトがあります。

ローカル内のサーバを名前解決してアクセスするためにunboundを使う


↑この方のを参考にして自分でやってみました。ほとんど↑と同様です。差分は、

– IPV6を無効にした
– unboundへアクセスしてよいものを追加した
– wiki.loとgitlab.loの2つを登録した
– macでこのunboundへ聞きに行く方法を書いた
– NECルーターの設定方法を書いた

程度の僅かなものです。以下作業ログです。

想定しているサーバーはubuntuです。

# unboundをインストール
$ sudo aptitude install unbound -y

# unbound.confを編集 (このページの下に設定例があります)
$ sudo vi /etc/unbound/unbound.conf

# unbound.confが正しい設定が確認 (以下のような出力があればOK)
$ unbound-checkconf 
unbound-checkconf: no errors in /etc/unbound/unbound.conf

# unboundを起動
$ /etc/init.d/unbound start
 * Starting recursive DNS server unbound

# digで確かめてみる
$ dig wiki.lo @localhost

; <<>> DiG 9.8.1-P1 <<>> wiki.lo @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wiki.lo.			IN	A

;; ANSWER SECTION:
wiki.lo.		3600	IN	A	192.168.1.118

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 29 21:07:44 2014
;; MSG SIZE  rcvd: 41

$ dig gitlab.lo @localhost

; <<>> DiG 9.8.1-P1 <<>> gitlab.lo @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4415
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gitlab.lo.			IN	A

;; ANSWER SECTION:
gitlab.lo.		3600	IN	A	192.168.1.118

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 29 21:07:51 2014
;; MSG SIZE  rcvd: 43

そして、他のマシンから↑のunboundに名前解決しに行くには、/etc/resolv.confを↑のサーバーに指定してやる必要があります。DHCPで自動設定される場合もありますので、その場合はDHCPサーバーの設定に↑のマシンのIPアドレスを書きましょう。

– Linuxでの設定例 (↑のunboundのサーバーのIPアドレスを192.168.1.2とします。↓のように編集してやればよいという意味です)

$ cat /etc/resolv.conf 
nameserver 192.168.1.2

– Macでの設定例

Macの場合、resolv.confを書き換えても有効ならないようです。digは可能でしたがcurlやブラウザなどでは名前を引いてくるのに失敗します。どうやらシステム環境設定から行うようです。

システム環境設定→ネットワーク→詳細→DNS→DNSサーバーで-ボタンを押して既存のものを消して+ボタンを押して「192.168.1.2」を追加→OK→適用をクリック

です。

– NECのルーター(DHCPサーバー)の設定

Aterm WR8700Nの設定方法です。
「基本設定」→「接続先設定」→「高度な設定を表示」→ネームサーバ→「サーバから割り当てられたアドレス」のチェックをはずす→プライマリDNSに「192.168.1.2」と追加→「設定」をクリック→「保存」をクリック

unbound.conf
server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
#    auto-trust-anchor-file: "/var/lib/unbound/root.key"
 
#ログのエラーレベルの設定 0~5まで指定可能。数字が大きいほど詳細なエラーを出力
verbosity: 2                                    

# ipv6を使用しない
do-ip6: no   
 
# unboundが動作するディレクトリ
directory: "/etc/unbound"
 
# 使用するインターフェース。以下ではデフォルトルートを指定
interface: 0.0.0.0
 
# unboundへのアクセスを許可するIPアドレス範囲
access-control: 127.0.0.1/32 allow              
access-control: 192.168.1.0/24 allow
access-control: 192.168.0.0/24 allow
 
username: "root"
 
# unboundのログファイルの出力先
logfile: "/var/log/unbound.log"
use-syslog: no
 
# ローカルのサーバの名前とIPアドレスの対応を登録
local-data: "wiki.lo. IN A 192.168.1.118"
local-data-ptr: "192.168.1.118 wiki.lo."

local-data: "gitlab.lo. IN A 192.168.1.118"
local-data-ptr: "192.168.1.118 gitlab.lo."

# 再帰的に問い合わせるためのローカル内の他のDNSサーバの指定。ない場合は省略。
forward-zone:
name: "."
forward-addr: 192.168.0.1

Linuxマシンのメモリ帯域を測定する、Streamの使い方+α

Linuxマシンのメモリ帯域を測定したくなりました。いつもはddコマンドでやっているのですが、どの程度正確なのかいまいち分からないので。。。

メモリ帯域を測定するツールにStreamというものがあります。今回はこれを使います。このエントリにはその使い方と測定結果と考察を書きました。

デフォルトのstreamですと、昨今のコンピュータの性能を鑑みるに測定サイズが小さすぎるので一桁あげています。あげるために、コンパイル方法が少し異なります。具体的には、

gcc -O -mcmodel=large -DSTREAM_ARRAY_SIZE=100000000 stream.c -o stream.100M

と、「-mcmodel=large -DSTREAM_ARRAY_SIZE=100000000」を付加します。

以下、具体的な方法です↓。ちなみに、最適化オプションですが-Oで行いました。-O2ではありません。推奨が-Oだったので、それに準拠した感じです。
# ソースを落としてくる
$ wget http://www.cs.virginia.edu/stream/FTP/Code/stream.c
--2013-07-21 02:56:53--  http://www.cs.virginia.edu/stream/FTP/Code/stream.c
Resolving www.cs.virginia.edu (www.cs.virginia.edu)... 128.143.137.29
Connecting to www.cs.virginia.edu (www.cs.virginia.edu)|128.143.137.29|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19967 (19K) 
Saving to: `stream.c'

100%[===========================================================================================================================================>] 19,967      52.5K/s   in 0.4s    

2013-07-21 02:56:55 (52.5 KB/s) - `stream.c' saved [19967/19967]

# コンパイルする
$ gcc -O -mcmodel=large -DSTREAM_ARRAY_SIZE=100000000 stream.c -o stream.100M

# 測定する
$ ./stream.100M 
-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 100000000 (elements), Offset = 0 (elements)
Memory per array = 762.9 MiB (= 0.7 GiB).
Total memory required = 2288.8 MiB (= 2.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 120877 microseconds.
   (= 120877 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:            9542.1     0.167732     0.167678     0.167769
Scale:           9818.7     0.162996     0.162954     0.163030
Add:            11098.8     0.216290     0.216239     0.216334
Triad:          11003.0     0.218197     0.218123     0.218254
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

ちなみに↑と同じマシンでddコマンドで測定してみた例↓です。
$ dd if=/dev/zero of=/dev/null bs=100K count=100000
100000+0 records in
100000+0 records out
10240000000 bytes (10 GB) copied, 0.692448 s, 14.8 GB/s

評価:
Streamで10GB/s程度、ddコマンドで14.8GB/sということで、まあおおよそ一致、と言えるのでしょうかね?シングルプロセスによる測定なので、2コアのマシンなら実質この倍使えるということなのでしょう。

↑のマシンのスペックは、
– G540
– Intel(R) Celeron(R) CPU G540 @ 2.50GHz
– DDR3-1600 のDRAM 8GB * 2 (ただし、$ lshw で見てみると、1067MHz駆動のようです)
– Ubuntu 12.04.2 Server AMD64
– Linux Kernel 3.2.0-49-generic #75-Ubuntu SMP
– gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
です。

加えて、手持ちの富士通マシンでも測定してみました。
– Opteron 3280
– DDR3-1333 4GB * 2
– Ubuntu 12.04.2 Server AMD64
– Linux Kernel 3.5.0-36-generic #57~precise1-Ubuntu SMP
– gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

$ gcc -O -mcmodel=large -DSTREAM_ARRAY_SIZE=100000000 stream.c -o stream.100M

$ ./stream.100M 
-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 100000000 (elements), Offset = 0 (elements)
Memory per array = 762.9 MiB (= 0.7 GiB).
Total memory required = 2288.8 MiB (= 2.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 183660 microseconds.
   (= 183660 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:            6385.6     0.251072     0.250563     0.251651
Scale:           6222.1     0.257535     0.257150     0.257991
Add:             7221.6     0.332633     0.332334     0.332919
Triad:           7058.7     0.340359     0.340005     0.340577
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

$ dd if=/dev/zero of=/dev/null bs=100K count=100000
100000+0 records in
100000+0 records out
10240000000 bytes (10 GB) copied, 1.42714 s, 7.2 GB/s

あまり7GB/s程度ですか。まあ8coresあるので、もっと行けるかもですが。

ちなみに結論としては、
$ dd if=/dev/zero of=/dev/null bs=100K count=100000
はそこそこ精度が良さそうという感じです。Streamをコンパイルするのは面倒ですのでこれで十分感がありますね。