September 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

Bash on Windows で postgresql

JUGEMテーマ:コンピュータ

 

昨年9月に、Windows Service for Linix で動く、Bash on Windows がUbuntu 16.04 にアップグレードされていた。

Build 14936 残念ながら共有メモリが使えなくて、postgresql のサーバは使えなかった。

今年になって、Build 15002で shmctl, shmget, shmdt, shmat がサポートされた。

( https://msdn.microsoft.com/en-us/commandline/wsl/release_notes )

 

これによって、共有メモリが利用可能となり、postgresql のサーバも稼働するはずであると思い、BoW をインストールしてなおしてみた(手順は、WSL その33 - Ubuntu On Windowsをインストールするには(Windows 10 Anniversary Update版) を参照)。

 

Ubuntuのインストール後に、以下のように、一般的なUbuntu と同様に postgresql をインストールする。

$ sudo apt install postgresql postgresql-contrib

インストールができたら、サービスを起動してみる。

$ sudo /etc/init.d/postgresql start

サービスが起動したら、postgres ユーザで接続してみる。

$ sudo su postgres -c 'psql'

psql (9.5.8)

Type "help" for help.

postgres=# ¥l

....

普通にインストールできるようになっていた。

ちなみ、共有メモリの状態は次のとおり確保されていた。

$ sudo su -c 'ipcs -a'
------ メッセージキュー --------
キー     msqid      所有者  権限     使用済みバイト数 メッセージ

------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x0052e2c1 0          postgres   600        56         6

------ セマフォ配列 --------
キー     semid      所有者  権限     nsems

 

 

 

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が速くなった分)と考えられる。
 
12345>|next>>
pagetop