むー便屋さんの配達記録

とりあえず営業を開始してみました。配達時間は不定期です。配達ミスもあります。ご利用は慎重に・・・。

カテゴリ: Linux

メーリングリストでふと目にしたPG-Strom。
GPCPUを使い、PostgresSQLの処理を爆速にしてくれるという夢のあるモジュールです。

http://heterodb.github.io/pg-strom/ja/

動作させるためには、Postgresのバージョンもですが、GPUのバージョンにも制約があるのですぐに試せないのが残念。

ハードウェア
CUDA ToolkitのサポートするLinuxオペレーティングシステムを動作可能な x86_64 アーキテクチャのハードウェアが必要です。
CPU、ストレージ、およびネットワークデバイスには特別な要件はありませんが、note002:HW Validation Listはハードウェア選定の上で参考になるかもしれません。
SSD-to-GPUダイレクトSQL実行を利用するにはNVMe規格に対応したSSDが必要で、GPUと同一のPCIe Root Complex配下に接続されている必要があります。
GPUデバイス
PG-Stromを実行するには少なくとも一個のGPUデバイスがシステム上に必要です。これらはCUDA Toolkitでサポートされており、computing capability が6.0以降のモデル(Pascal世代以降)である必要があります。
note001:GPU Availability Matrixにより詳細な情報が記載されています。SSD-to-GPUダイレクトSQL実行の対応状況に関してもこちらを参照してください。
Operating System
PG-Stromの実行には、CUDA Toolkitによりサポートされているx86_64アーキテクチャ向けのLinux OSが必要です。推奨環境はRed Hat Enterprise LinuxまたはCentOSのバージョン7.xシリーズです。
SSD-to-GPUダイレクトSQL実行を利用するには、Red Hat Enterprise Linux または CentOS のバージョン7.3以降が必要です。
PostgreSQL
PG-Stromの実行にはPostgreSQLバージョン9.6以降が必要です。これは、Custom ScanインターフェースがCPU並列実行やGROUP BYに対応するため刷新され、拡張モジュールが提供するカスタム実行計画を自然な形で統合できるようになったためです。
CUDA Toolkit
PG-Stromの実行にはCUDA Toolkit バージョン9.1以降が必要です。
PG-Stromが提供する半精度浮動小数点(float2)型は、内部的にCUDA Cのhalf_t型を使用しており、古いCUDA Toolkitではこれをビルドできないためです。


環境が整えば試してみたい〜。

マルチサイトとかマルチドメインとか色々やってたらログインできなくなってしまったorz

かろうじてバックアップから戻すことができたが、FTPしたときにパーミッションがめちゃめちゃに・・。
過去の改ざん事件はパーミッションが不適切だったため、ということらしいので、ここはちゃんとしておかないとね。特に共用サーバでは。で、確認してみたらみーんな644。誰でも見れるじゃんww

最初はロリポップのFTPツールやWInSCPとかでパーミッションをちまちま変えていましたが・・・「面倒くさい!!」
PHPでスクリプト書いて提供してくれてる人もいましたが、パーミッションの「0」が設定できず。

仕方ないので自分で書きました。
PHPはしばらく触っていないのですぐにコーディングできなかったので、Linuxのコマンドにしました。
なのでLinux限定(といっても共用サーバはほとんどLinuxかな)。パーミッションはロリポップ奨励設定仕様です。
----------------------------
ディレクトリ、ファイルのパーミッションを以下の値での設定を推奨しております。
HTML・画像ファイル     604     rw----r--
CGIの実行ファイル     700     rwx------
CGIのデータファイル     600     rw-------
.htaccessファイル     604     rw----r--
ディレクトリ     705     rwx---r-x
----------------------------
プラス、セキュリティ上wp_configは400


SSHの設定を有効にして、該当フォルダへ移動し、以下のコマンドを実行します。
(SSHとかフォルダの移動とかわかんないよ!!という人は使わない方がいいですので説明はあえてしません。)
--------------------------------
find . -type d -exec chmod 705 {} \;
find . -type f -exec chmod 604 {} \;
find . -type f -name "*.cgi" -exec chmod 700 {} \;
find . -type f -name "*.dat" -exec chmod 600 {} \;
find . -type f -name "wp_config.php" -exec chmod 400 {} \;
--------------------------------
※ご利用は自己責任でお願いいたします。あらかじめ、コピーした違うフォルダなどでテストしてから使われることを強くお勧めします。何か問題が生じても責任は取りませんので。

postgresql-logo
いやー、それが本当ならちょっとうれしい記事ですねー。PostgreSQLを使ってる立場としてはなんか得した気分です。

Oracleは、最新の決算業績予想に届かなかった理由について、為替変動による業績悪化が原因だったとしている。しかし、それは多くの原因の中の1つにすぎない。実際、Oracleが最後に2期続けて業績予想を達成したのがいつだったかを思い出すのは難しい。この数年は、業績予想を達成するよりも、届かないことの方が多い。

 Oracleはずっと、理由として営業の失敗や為替変動などを挙げてきた。

 同社は言及したことがないが、Bloombergは業績悪化の原因としてオープンソースデータベースとの競争を挙げた。「(オープンソースデータベースの)影響は、Oracleの新規ソフトウェアライセンスの売上に現れており、この数字は前年同期比で7四半期連続で減少している」  



Oracleはちゃんと調べてないんでしょうか。それともまだまだオープンソースDBについて脅威にはなりえないって思ってるのか、実際にそうなのか。

 ちょっと前にはイギリスの気象庁がOracleからPostgreSQLに移行するってありましたね。

やっぱりちょっとずつですが、採用は増える気がします。レプリケーションとかCPUのスケーラビリティとかいろいろ充実してきましたから。
あとは管理・運用系(ツール)がもう少ししっかりしたらいいんですが。差分バックアップとかバックアップスケジュールとかね。
 

PostgreSQLのアップデートの頻度が異常に早い。
昔は気にしてなかったんですが。過去にもあったのかな?

http://www.postgresql.org/

9.4.0が2014年12月18日
9.4.1が2015年2月5日
9.4.2が2015年5月22日

まあ、ここまではいいんですが、
9.4.3が2015年6月4日
9.4.4が2015年6月12日

いやいや、短すぎない?。
まあ、データベースクラスタはそのままでいいんだからそこまでアップデートは大変じゃないけどさ、でもそんなに頻繁には止められんよ。

メモ。

Debian6.0でも設定したのですが、同じ設定を8.0でしたらシャットダウンしなくなりました。
で、どうやってたのかというと、起動スクリプトを/etc/rc.localに書いてました。
こんな風に。

/usr/lib/PowerActPro/MasterAgent/AgentManager start
exit 0



これやるとだめでした。シャットダウンで止まっちゃうんですよ。
なので、面倒だったんですが、ちゃんと起動スクリプトにしました。
ベースはPostgreSQLの起動スクリプトを使いました。

ちなみに、UPS管理パッケージはrpmパッケージをalienでdebパッケージに変換してインストールしました。
簡単ですね。
http://www.omron.co.jp/ese/ups/support/download/soft/poweractpro/poweractpro_master.html

power_act_pro
↑起動スクリプト

Debianがいつの間にか8.0になってました。

https://www.debian.org/index.ja.html

で、ちょうど再インストールするサーバがあったもんで、再インストールしてたんですが、
「sshd」がねぇ!!
・・・・あら、Debian7系ならapt-get install sshd でインストールできたんですがね・・・・。

ちょいと調べたら、パッケージ名が変わってました。
ssh-contact-service

まあsshでクライアントもサーバも入るみたいですが。

↑このページのトップヘ