April 2017  |  01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

BoW(Bash on Windows)でPostgreSQL没

JUGEMテーマ:コンピュータ

 

Bash on WindowsでPostgreSQLをインストールしてみた。

 

まず、開発者モードにする。

https://docs.microsoft.com/ja-jp/windows/uwp/get-started/enable-your-device-for-development#a-namedeveloper-mode-featuresa開発者モードの機能

次に、BoWのインストール。

http://kkamegawa.hatenablog.jp/entry/2016/04/07/055830

そして、PostgreSQLをインストールしてみた。まずは、エラー。共有メモリーがありませぬ(がっかり)。

pgbenchで自宅サーバ徒競走(つづき)

JUGEMテーマ:コンピュータ

先日のベンチマークの続きで、Raspberry Pi2 のストレージに遅いマイクロSDを使うのはもったいないという気になったので、実際どのくらい違うものか試してみた。先日は8GB 500円くらいの最大読み出し 30MB/sec というのを使ったが、今回は 16GB 1000円くらいの最大読み出し 80MB/sec というのを使った。

結果は期待どおり(あたりまえか)速くなった。
 
» read more

pgbenchで自宅サーバ徒競走

JUGEMテーマ:コンピュータ

 
体育の日ということで、自宅マシンの性能比較をやってみた。
先日、自宅にクアッドコアのなんちゃってXonサーバを入れたけど、どのくらい早いのかが気になってた。

ベンチマークのプログラムには、普段から使っているアプリからPostgreSQLの pgbench を使うことに。
サーバといっても開発用にLinuxをインストールしたもので、普段の状態が知りたいのでディストリビューションもさまざま、ベンチマークのために再起動したりはしない。
PostgreSQLのチューニングはPgTune を使って簡易的に行ってあるが、インストールしたてと比べると1割か2割の性能向上と思われる(ここでは比較しない)。

ここで、対象としたサーバは次のとおり、比較の際はCPU名で示すことにする。Raspberry Piとの比較用にWindows XPからUbuntu Linuxに載せ替えたEeePCも含めてみた。
CPUとPCモデル(導入時期)は次のとおり。
E3-1275L-v3: Shuttle D81/PC3-12800 (2015/08)
ARMv7l        : Raspberry Pi 2 Model B/LPDDR2 (2015/02)
Celeron-847 : Shuttle DS47/PC3-10600 (2013/12)
Atom-D2550 : Shuttle XS36VL/PC3-8500 (2013/11)
AMDE-350    : ZBOX-AD03BR/PC3-8500 (2012/05)
Atom-330    : Shutle X27D/PC2-4200(2009/06)         ※
Atom-N270   : EeePC 901/PC2-3200(2008/07)

※ ストレージの Read, Write Speed に関して計測しなおしました。(コマンドとオプションについては、http://a98.jugem.jp/?eid=432 を参照 )
※ Atom-330を追加 (2015-10-28)
» read more

Raspberry Pi でPostgreSQLは桁違いに遅かった

JUGEMテーマ:コンピュータ

Raspberry Pi Model A で、ちっちゃなリレーション(10カラム未満)のベンチマークをしてみたところ、PostgreSQLが桁違いに遅い結果となってしまった。Debian系のPostgreSQLパッケージはpsqlがperlのラッパーから起動されるためプロセス起動のオーバーヘッドはあるものの、それを大きく上回る遅さであった。

BerkeleyDBは、SQLite互換モードで使ったが、SQLiteより速かった。SQLiteは競合した場合にエラーとなるため、実行プログラム側でWAITとリトライを行う必要があるが、BerkeleyDBはキューを持つためその必要はなかった。

ベンチマークをするテーブルは10カラム未満のもので、1000回(10クエリを100セット)のINSERTの間、別プロセスで定期的に6または8クエリの1セットのSELECTを行うもので、DBMSはBerkeleyDB, MySQL, PostgreSQL そして、SQLite を対象とした。ベンチマーク用のプログラムはBashシェルスクリプトで記述した。

以下は、INSERT100セットを行ったときの結果で、{同時実行セット数、経過時間[sec]、1セットあたりの所要時間[sec]}を、INSERTとSELECTについてそれぞれのDBMSで測った結果である。なお、インデックスは作成していない。
SQLiteについては、INSERT時にはロックファイルを作成して、SELECTクエリ側ではロックファイルがなくなるまでWAITとリトライをするようスクリプトに記述した。
※WAIT時間のチューニングについてはここでは触れない。

1. Raspbery Pi A+ の結果
Raspberry Pi A+(ARM 700MHz)、RAM 256MB、MicroSDでOSはRaspbian(Wheezy)での、Insert/Select同時ベンチマーク実行結果である。
MySQL 5.5:
::::::::::
Result Times and Averages:
        INSERT 100 672.442153079 4.11888
        SELECT 811 673.441800291 0.332067
PostgreSQL 9.1:
:::::::::::::::
Result Times and Averages:
        INSERT 100 2622.1109690768 23.4154
        SELECT 459 2626.588798772 5.23984
SQLite 3.7:
:::::::::::
Result Times and Averages:
        INSERT 100 550.92420354 2.83853
        SELECT 502 551.120738178 0.397833

PostgreSQLでのベンチマーク結果が一桁遅いのが気になる。
※PostgreSQLをシングルユーザモードで実行した場合は、さらに遅くなった。


2. Raspberry Pi A(MicroSD変更)のベンチマーク結果
Raspberry PiはA+でなく Aではあるが、やや速いMicroSDを使ってのInsert/Select同時ベンチマーク実行結果である。
BerkeleyDB 5.1:
:::::::::::::::
Result Times and Averages:
        INSERT 100 495.308163151 2.26031
        SELECT 603 495.585024318 0.301102
SQLite 3.7:
:::::::::::
Result Times and Averages:
        INSERT 100 522.1067024546 2.51971
        SELECT 559 523.1204274229 0.335052

BerkeleyDBのほうがSQLiteよりもやや速い結果となった。


3. Celeron マシンでのベンチマーク結果

以下は、PostgreSQLを含むCeleron847(Dual Processor)、RAM 2GB、SDD でOSはCentOS6のマシンで、Insert/Select同時ベンチマーク実行結果である。

BerkeleyDB 6.1:
:::::::::::::::
Result Times and Averages:
INSERT 100 281.1365123651 0.381156
SELECT 1220 281.1340809510 0.16721

MySQL 5.1:
::::::::::
Result Times and Averages:
INSERT 100 299.1057975644 0.594603
SELECT 1795 299.1000098073 0.119218

PostgreSQL 9.3:
:::::::::::::::
Result Times and Averages:
INSERT 100 297.728115501 0.27439
SELECT 1165 297.754557170 0.188408

SQLite 3.6:
:::::::::::
Result Times and Averages:
INSERT 100 337.476402330 1.29092
SELECT 1931 337.627725860 0.142878
PostgreSQLも他と大きくは変わらない結果で、SQLiteが遅い結果となった。ただし、SQLiteについては、ロック時のWAIT時間が必要以上に長すぎた(CPUが速くなった分)と考えられる。
 

PostgreSQLシングルユーザモード

JUGEMテーマ:コンピュータ

今年の書初めはBashシェルになってしまった。
昨年末に簡単なベンチマークをRaspberry pi で行った。対象としたDBMSはMySQLとSQLiteで、MySQLでの実装をSQLiteにするとどのくらい早くなるかを見るのが目的だった。
意外とMySQLの成績が良いので、PostgreSQLではどうかと試してみたところ、芳しくなくて、では、シングルユーザモードにしたらどうだろうと思い仕込んでみたら、結果は一層悪くなってしまった。

その副産物がPostgreSQLのシングルユーザモード実行シェル。バックエンドサーバを止めて使用する。ベンチマーク用なので、かなり超手抜きなのはご愛嬌。結局、ほとんど意味をなざず残念なので、書初めと称することにした。

 
» read more
12345>|next>>
pagetop