PostgreSQL事例紹介セミナー2008のご案内

 Posted on November 26, 2008  |  BABA Toshiaki

PostgreSQL事例紹介セミナー2008を開催します。
事前申込制です。。懇親会はもう〆切ですが
セミナーのほうはまだいけるはずなので
ぜひ参加してみてください。

http://www.postgresql.jp/events/jirei-seminar-2008/event_info

以下紹介用テンプレです。

       ★ PostgreSQL事例紹介セミナー2008 開催のお知らせ　★

年に1度毎年恒例となりました、
様々なPostgreSQLの事例をご紹介するセミナー
です。PostgreSQLは、本格的なリレーショナルデータベースとして注目され、
年々その利用は拡大しています。今年は、ニューヨーク証券取引所でも採用され
たPostgreSQLのDWH事例や、月間25億PVを超えるWebシステムのバックエンドを支
えるPostgreSQLの事例、病院で利用される画像診断データベースでの採用事例、
全社標準データベースとしてPostgreSQLを採用した例など、たくさんの事例をご
紹介いただきます。皆様のPostgreSQL活用推進のヒントとなれば幸いです。皆様
のご参加を心よりお待ちしております。

【開催概要】

会場：  サン・マイクロシステムズ株式会社 神宮前オフィス セミナールーム
日時：  2008年11月28日(金) 10:25 ～16:00
定員：　80名（定員になり次第締め切ります）
会費：　無料（事前登録制、懇親会は別途費用）
主催：　日本PostgreSQLユーザ会
後援：　サン・マイクロシステムズ株式会社

【詳細・申し込み】

http://www.postgresql.jp/events/jirei-seminar-2008/event_info

【プログラム】

10:00～受付開始
10:25～10:30　開催あいさつ

10:30～11:15 大規模導入事例（証券取引所クラス）のご紹介
 サン・マイクロシステムズ株式会社　
            システム技術統括本部 中村 完 様

ニューヨーク証券取引所でも採用されている、 PostgreSQL をベースにした
大規模並列処理 DWH アプライアンスについて、デモを交えながら、導入例と
アーキテクチャのご紹介を致します。

11:20～11:50 携帯向けCGMサイトにおけるPostgreSQL可用性対策について
            株式会社ビジュアルワークス
            取締役　社長室　室長　落水 恒一郎 様

ビジュアルワークスは、携帯無料ホームページサービス(forestpage)を運営して
います。主に10代に高い支持を得ており、開設ホームページ数は180万以上、月
間ページビュー数 25億以上（PCを含む）のシステムです。そのシステムを支
えているのがPostgreSQLです。 PostgreSQLの利用方法とともに、採用の理由、
アクセス増大に伴う対処の過程をご案内いたします。 また、最近、可用性対策
として導入した Slony-I についてもご紹介します。

11:50～13:20 お昼休み

13:20～13:50 医療分野における診断画像データベースを支えるPostgreSQL
            株式会社日立メディコ
            メディカルIT事業部 システム本部 開発部
            画像グループ　鈴木雅登様

日立メディコ社は、X線画像,MRI,CT,核医学検査など、放射線画像診断用装置を
医療施設へ提供すると共に、フィルムレス・デジタル画像を保存するICOM画像シ
ステムを開発しています。装置から発生する大量の診断画像ファイルと、それに
付属する患者氏名、撮影年月日、撮影情報など、多量の属性情報やインデックス
を管理するDICOMサーバのDBとして PostgreSQLを採用し、医療施設向けの診断画
像システムを、安心・安全に提供してきた取り組みをお話しします。

13:55～14:35　PostgreSQLを使ったチラシ・口コミサイトの構築・運営事例
             オールクリエイター株式会社
             代表取締役 橋本 俊秀 様

オールクリエーター株式会社では、ネットでクチコミ・チラシを楽しむ携帯・Ｐ
Ｃサイト「とっとくねっト」の企画・開発・運用をしており、データベースとし
て当初よりPostgreSQLを活用してきました。今回は、PostgreSQL活用における体
験を皆様にご紹介させていただきます。

14:40～15:10　自治体ビジネスに向けたPostgreSQLでの試み
             株式会社BSNアイネット
             白柏 雅資 様

BSNアイネットは、本社が新潟市のシステムインテグレータです。
自治体に向けたオープンソースの取組みとして、昨年度の
IPA（独立行政法人情報処理推進機構）のオープンソース活用実証事業で、
新潟県上越市様における「OSSによる統合DBを介した基幹システムと業務システ
ム連携の実証」プロジェクトを実施し、PostgreSQL,pgpool-HAを採用しました。
PostgreSQLの採用理由と、導入後の評価についてご紹介します。また、現在開発
中の「全国障害者スポーツ大会競技運営システム」においてもPostgreSQLを採用
しており、このシステムについてもご紹介します。

15:15～15:55 住友電気工業株式会社におけるオープンソースソフトウェアの
            積極的な導入
            住友電気工業株式会社 情報システム部
            中塚 康介 様

住友電気工業株式会社ではオープンソースソフトウェアの積極的な導入の取り組
みの一つとして、 PostgreSQLを標準データベースとして定め、基幹システムや
全社システムへの導入を行ってきました。PostgreSQLを導入しているシステムの
うち、全社システムの社内ポータルサイト、申請システムを取り上げ、同じく
オープンソースソフトウェアの一つであるXenを用いた仮想化とあわせて具体的
な構築事例をご紹介します。また、現在最も大規模である全社経理システムのリ
プレイスにおいてもPostgreSQLの導入を検討をしており、住友電気工業株式会社
におけるPostgreSQLの今後の利用についてもご紹介します。

[Read More]
PostgreSQL 

sendmail / qmail / postfix の接続元制限

 Posted on November 8, 2008  |  BABA Toshiaki

特に、DNS関連(正引きできないと...、逆引きできないと...というケース)について確認した内容をメモしておきます

sendmailの場合

  • 接続元IPアドレスを逆引きし、逆引きできたホスト名に対して正引きを行ったが、答えが一致しない場合にreject
    ⇒mcのLOCAL_RULESETSのRFORGEDで設定
qmailの場合
  • 接続元IPアドレスを逆引きし、逆引きできたホスト名に対して正引きを行ったが、答えが一致しない場合にreject
    ⇒tcpserverの-p(小文字)オプションで設定
postfixの場合
  • 接続元IPアドレスの逆引きができない場合、または接続元IPアドレスを逆引きした結果を正引きした時にAレコードが存在しない場合にreject
    ⇒main.cfのreject_unknown_clientで設定
  • HELO/EHLOのFQDNを正引きした時、そのホスト名がAレコード・MXレコードのいずれでもない場合にreject
    ⇒main.cfのreject_unknown_hostnameで設定
  • Envelope Fromのドメイン部分がAレコード・MXレコードのいずれでもない場合にreject
    ⇒main.cfのreject_unknown_sender_domainで設定
  • ルール：RCPTのドメイン部分がAレコード・MXレコードのいずれでもない場合にreject
    ⇒main.cfのreject_unknown_recipient_domainで設定

と、いうわけで
  • sendmailとqmailの制限は一緒。postfixは微妙に違います。
  • 「HELO/EHLOのFQDNの正引き結果」と「接続元IPアドレス」をマッチさせるルールはないみたい。
  • 「MAIL From:のFQDNの正引き結果」と「接続元IPアドレス」をマッチさせるルールはないみたい。


DNS逆引きチェックを入れちゃった場合に問題になりそう(だと言われている)ケースは
  • 共有ホスティングの場合
  • NAT構成の場合
  • 逆引きが自分で設定できない場合
だと思うんですが

[Read More]
Linux  Postfix  qmail  sendmail 

PHPでSessionの生成が遅い場合の注意点

 Posted on October 22, 2008  |  BABA Toshiaki

webサーバのパフォーマンスについて、PHPでセッション生成が遅い場合、
php.iniの設定を確認してみてください。

session.entropy_file = /dev/random
となっている場合、この/dev/randomからの読み取りの遅延が原因で動作が遅くなっている可能性が高いです。
⇒使うのであれば /dev/urandom を使いましょう。

/dev/randomからの読み込みが遅くなる原因は、
  • /dev/randomは、十分なエントロピーが得られない場合には応答をwaitすること
  • エントロピーの素として「人間の利用するキーボードなどの入力デバイスのタイミングの「ぶれ」などを活用」していること
    ⇒iDC設置のサーバ機器だとエントロピーがたまらない！
だそうです。
⇒from: Linusのクリスマスプレゼントが引き起こした問題 - @IT

この場合、サーバの負荷は高くないものの応答が遅い状態になります。
みなさまご注意ください。

[Read More]
Linux  System Tuning  PHP 

稼働中のMySQLの情報収集

 Posted on October 21, 2008  |  BABA Toshiaki

稼働中のMySQLの情報収集の方法です。

show status like 'Max%';
のように、絞り込みも使えるので便利ですね。

値を読む際には単位に注意しましょう。
公式ドキュメントには、単位がキッチリ書いてないものが結構あって難儀します。。。
mysql> show status;
mysql> show variables;
innodbの場合

[Read More]
MySQL 

PHPをAPCで高速化

 Posted on October 13, 2008  |  BABA Toshiaki

OpenXで広告配信システムを構築したとき、APCの導入で負荷が1/100くらいに下がったのでメモ。
LoadAverage60→0.6になりました。
導入は簡単です。

# pecl install APC
でokです。
php.iniに設定を追加して完了。
[apc]
extension=apc.so
apc.enabled=1
apc.optimization=1
apc.ttl=10
apc.gc_ttl=10
apc.shm_size=96
ポイントは、apc.shm_sizeを大きめにとらないとgcが正常に動作しないようです。
apc.shm_sizeが足りないと、apacheのエラーログに
[Mon Oct 10 08:15:45 2008] [apc-warning] GC cache entry '/var/www/openx/var/cache/deliverycache_1184f8a13xxx4b67eb68c969e9e5740.php' (dev=64769 ino=0) was on gc-list for 2852984 seconds
なんてのが出続けます。。。

[Read More]
OpenX  System Tuning  PHP 

webサーバをチューニング

 Posted on October 13, 2008  |  BABA Toshiaki

webサーバのチューニングのポイントをまとめておきます。

TIME_WAIT待機時間を短くする
アクセスが多いシステムだと、
ソケットの開放が追い付かなくなって
ポートを使いきってしまいます。
⇒特にKeep Alive OFFのwebサーバなど

RedHat系Linuxの場合、この待機時間は
net.ipv4.tcp_fin_timeout
の値になります。(単位は秒)
net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycleを有効にすることで再利用を促進します。
オンラインで変更する場合、sysctlを使って調整します。

設定値の表示
# sysctl -a
設定値の書き換え
# sysctl -w net.ipv4.tcp_fin_timeout=30
# sysctl -w net.ipv4.tcp_tw_reuse=1
# sysctl -w net.ipv4.tcp_tw_recycle=0

↑なんか勘違いしていた可能性があるので修正。現状では大きな問題は起きていないですが、tcp_tw_recycleはNATで問題が起きることがあるようなので最終手段です。
@2008/12/11追記

↑tcp_tw_recycleを1にすると問題が多くて地雷祭りなので、基本0にしておきます。
@2010/10/29追記

いまさらですけど、tcp_fin_timeoutはtime_waitの数と関係ありません(60秒でハードコードされているとのこと)。tcp_fin_timeoutが関係あるのはFIN_WAIT_2の数で、FIN_WAIT_2が多い場合はtcp_fin_timeoutを短くすると改善するかもしれません。

また、起動時に設定されるように
/etc/sysctl.conf
を編集して設定しておきましょう。

参考図書

[Read More]
Linux  System Tuning 

auto negotiationの仕組み

 Posted on October 13, 2008  |  BABA Toshiaki

旧サイトからの移設分エントリです。

最近はインターネットも一般的になってきたこともあって、その仕組みについての知識もだいぶ普及してきたようです。
パケット通信とはなんぞや、や、 HTTP, FTP, SMTP, POP等のプロトコルレベルの話からTCP/IPの仕組みぐらいまでが一般的ですかね。
OSI参照モデルなんかは大学でも情報系の学科なら必修ですね。

実践的な話ではTCPの場合のコネクションをはるまでの過程やルーティングの話がありますね。私も基本的な話はだいぶ分かっていたつもりなので すが、最近ひとつ疑問につきあたりました。

オートネゴシエーションの仕組みはどうなっているのか、です。

あのHUB< ->NIC間等で通信スピードと方式の検出を行うあれです。まさに基礎の基礎。なにしろ最初の一歩・ケーブルを挿す、の直後ですから。 というわけで調べてみました。

今回は一次情報の場所がわからなくて困りました。まずRFCを調べたけど空振り。ということでgoogleからあさってみました。で、見つけたのがここ(⇒Charles Spurgeon's Ethernet Web Site)。ここが一次情報源だと思います。

で、 肝心のauto negotiationの仕組みはというと、詳しくは分かりませんでした。(といってもただじっくり読んでないだけですが。)おおざっぱに言うと、FLP (fast link pulse)やNLP(normal link pulse)と呼ばれる既定のパルス波を用いて以下の優先順位で検出を行っているらしいです。

[Read More]
ブログロール  Server 

[OpenXチューニング]MySQL物理データファイルのサイズ

 Posted on October 13, 2008  |  BABA Toshiaki

OpenXでのMySQLチューニングの話

OpenXの場合、impressionをinsertでMySQLに記録するため
物理データファイルのサイズを小さく保つことが大事になります。

特に、インプレッションを記録する
ox_data_raw_ad_impression
テーブルのサイズが重要です。

実数はI/O性能によるので参考にしかなりませんが、
経験的にはデータファイルが800MBを超えたあたりから
急に性能が落ちてきます。

メンテナンススクリプトがテーブルをロックするので、
メンテナンススクリプトの処理時間が長いと
配信が遅延する原因になります。。。
また、データファイルが大きいと
配信自体(ox_data_raw_ad_impressionテーブルへのinsert)自体の
性能も低下する感じです。

と、いうわけで、

  1. 生データ保持期間を短くする
  2. (小さくできれば)データファイルを小さくする
という2つがポイントになります。

生データ保持期間を短くする
OpenXの管理画面で設定します。
ログイン ⇒ Administrator account ⇒ マイアカウント ⇒ 全般設定 ⇒ メンテナンス設定
集計後、統計情報の元データを削除しますか にチェック
統計情報を削除するまでの猶予期間(秒)  を設定
実際にデータが削除されるのは
メンテナンススクリプト(定期メンテナンス or 自動メンテナンス)が
実行されるタイミングです。
データファイルを小さくできるか調べる
show table statusで調査できます。
Data_freeが大きい場合、小さくする余地ありです。
mysql> show table status where name like 'ox_data_raw_ad_impression' \G;
データファイルを小さくする
データファイルが大きくなりすぎた場合、
PostgreSQLならVACUUMコマンドで対応しますが
MySQLの場合はOPTIMIZE TABLE句で対応します。
mysql> OPTIMIZE NO_WRITE_TO_BINLOG TABLE ox_data_raw_ad_impression;
分速80MBくらいのスローペースで、テーブルにロックがかかるので、
頻繁に実施するか/まとめて実施するかは
システムの特性にあわせて選択するのがよいと思います。

[Read More]
ブログロール  MySQL  OpenX