2009年2月20日

高速・軽量メールクライアント Sylpheed の応用ソリューション～高速全文検索機能(Sylph-searcher)、メールライブラリ(LibSylph)～

 [ReTweet This!] カテゴリ：OSC 2009 Tokyo/Spring

担当：SRA OSS, Inc. 日本支社
講師：山本 博之（SRA OSS, Inc. 日本支社）

・Sylpheed
・オープンソースのメールソフト、ライセンスはGPL+LGPL
・高速・軽量
・高機能
・高い操作性
・高信頼性
・マルチプラットフォーム

・主な機能
・様々なメールプロトコルに対応
・セキュリティ関連機能
・強力なフィルタリング・検索機能
・外部プログラムとの連携
・国際化・他言語対応
・その他多数の便利な機能

・最近追加された機能
・POP3リモートメールボックス機能
・設定ファイルの自動バックアップ強化
・縦3ペインモード
・添付ファイル忘れ防止機能
・送信前の宛先確認機能

・Sylpheedの歴史
・1999/9開発スタート
・2004/12バージョン1.0正式リリース
・2008/12バージョン2.6

・LibSylph
・コンパクトなC言語メールライブラリ
・Sylpheedのコア部分をライブラリとして独立
・UIに依存しない様々な機能を提供
・メール関連機能を組み込んだプログラムを作成可能
・組み込み用途にも使用可能（ゲーム機やPDAで実績あり）

・LibSylph開発の動機
・Sylpheedを開発する際に使えるメールライブラリを探してた、、、なかったー
・結局、メール関連機能は自前で実装
・だったら、汎用的に使える部分を公開しちゃおうよ的なながれで公開

・LibSylphの機能
・メールボックス管理
・メールの送受信
・メールデータの処理
・エンコード・デコード
・その他にも
・入出力、ファイル、ネットワーク
・パーサ、XML、HTML、設定ファイル
・文字列処理、文字コード変換、自動判別

・LibSylphの具体的な使用例
・MailDepot、SRAのメールアーカイバ製品、社内でやりとりされるメールをすべてDBにアーカイブして高速に全文検索、メールの送受信解析にLibSylphを使用
・Sylph-Searcher、メールの取得・解析に使用

・Sylph-Searcher
・Sylpheed向けの全文検索アプリケーション
・Sylpheedの検索機能を補完

・開発動機
・Sylpheedの本文検索は遅い、、、数千件のメール検索に数分かかる
・大量のメールを高速に！
・PostgreSQLに最近全文検索機能が実装されたし
・そいつを使っちゃえ！　ええっっ！　そうだったのか

・デモ
・げげっげげｇ！　すげー速い！！

・特徴
・高速な検索、数万～数十万件のメールから瞬時に本文の検索が可能
・PostgreSQL8.3を全文検索エンジンとしてtsearch2を使用
・単体のアプリケーションとして動作
・Windows版はインストーラ版も提供、GTK+、Mecab、PostgreSQLを全て同梱

・構成
・メールデータをSylph-SearcherがLibSylphを通して取得、MeCabで本文を分かち書き（tsearch2の為）、PostgreSQLに登録・インデックスを作成、以降は超高速に全文検索！！

・他の検索エンジンと比較
・
・Google Desktop、細かい条件指定が出来ない、インデックスに時間がかかる
・Vista標準、言わずもがな
・Mozilla Thunderbird、Sylph-Searcherの方が速い

・Sylpheed　TODO
・高速化、データ構造、キャッシュ改良、サマリー表示の改善、マルチスレッド化
・プラグイン機構の追加、迷惑メールフィルタ、RSSリーダ、カレンダー
・S/MIME対応
・インポート・エクスポート
・UIを親切に

・LibSylph TODO
・APIがこなれていない
・ドキュメントの不足、記述不足、英語版、、、
・Sylpheed同梱と単体版の統合

・Sylph-Searcher
・UIの改良
・検索機能の強化
・添付ファイルの検索
・他のメールソフトへの対応
・Sylpheedへの統合、受信時に自動的にインポート、Sylpheedからシームレスに、Sylpheedのメールストレージとして→そうなればベスト！

・ビジネスでの利用
・Sylpheedの開発を支援、ビジネスにしたいー
・LibSylphを製品に組み込む
・導入、カスタマイズなど

・これは、聞いておいてよかった～、っていうかすぐにでも導入しよう
・Sylpheedって検索が遅いのが一番のネックだったもんねー
・なんだろ、これだけ速ければGmail並にいけてるんじゃないか

投稿者 ymkx : 2009年2月20日 17:51 |

AMDの最新テクノロジとソリューション

 [ReTweet This!] カテゴリ：OSC 2009 Tokyo/Spring

担当：日本AMD株式会社
講師：林 淳二（日本AMD株式会社 セールスデベロップメント部 )

・AMDビジネスは台数ベース、売上ベースで堅調に成長
・コストパフォーマンスがいいから、不況時には有利

・CMは？　ブランド力のためにも、、、
・無駄な広告費をかけるより、OEMへの支援や価格性能比を高めるための技術開発へ投資じゃ
・そりゃ、ごもっとも。でも、やってるじゃんフェラーリ、、、

・AMDのCPUって大丈夫？
・相性問題はほとんど聞かない
・うちもいろいろあるけど、64特有の問題だと思う

・開発向けのツールもオープン
・developer.amd.com/cpu/Pages/default.aspx

・環境問題関連
・2001年から環境に対する働きかけをしている
・ワット性能、低消費電力において長期的かつ継続的に市場を牽引
・クリーンエネルギーの積極的な採用
・エネルギー効率の飛躍的向上
・真のQuadCore、なんちゃってじゃねーぞ
・8coreが2010/3,12coreが2010/6頃の予定
・コアは増えるけど、電力消費は増えません！　どこかのCPUとは違ってな（攻撃的だ）
・色々エコ活動をしてるとか

・製品の話し
・Opteron
・自社独自チップセット、Fiorano、ここまではソケット互換
・来年、新しいソケット、8core・12core、Maranello
・Istanbull、Socket F(1207)、6core、仮想化支援機能が大幅にアップ
・FioranoはI/O性能、仮想化性能、電力効率などが向上

・仮想化支援
・AMD-V、RVI、ハードウェアベースの仮想メモリの管理支援機能、アプリケーションの性能向上
・Tagged TLB、仮想OS上のアプリ切り替えを高速化・効率化
・Extended Migration、仮想マシンのライブマイグレーション（サーバ稼働中の移行）をAMD Opteronプロセッサ世代間で実現
・AMDはソケット数だとか、世代違いとか気にせずにライブマイグレーション可能

・電力効率関連
・Independent Dynamic Coreテクノロジー
・アイドル時にクロック周波数を落とすことが可能
・45nmクアッドコア製品で、800Mhzまで落とすことが可能
・AMD CoolCoreテクノロジー
・Low-Power DDR2 Memory、こよなく愛してますー、FB DIMMにも飛びつかねー、消費電力を低減するために、1slotで5-10Wの消費電力の低減
・AMD Smart Fetchテクノロジ、アイドル時にコアをhaltにすることにより消費電力の低減
・いろいろあるねー

・Intel同等製品(低電圧版)で比較すると、MAXで10W、30%で37W、idel時にも41Wの差がある
・ラックサーバでは一台当たり60W近い電力消費を押さえる、整数演算はちょっと負けてるけど

・グラフィックスの話し
・ATI、Radeon
・ATI GPUの性能向上、nvidiaを引き離す
・世界初のTeraFLOPs対応のGPU

・FirePRO、プロプロフェッショナル向け

・Intel意識しすぎ（笑）、でも、わかりやすかった

投稿者 ymkx : 2009年2月20日 17:50 |

仮想化環境の設計手法　～プロのテクニック教えます～

 [ReTweet This!] カテゴリ：OSC 2009 Tokyo/Spring

担当：日本仮想化技術株式会社
講師：宮原 徹 （日本仮想化技術株式会社 代表取締役社長兼CEO）

・仮想化技術のエキスパート
・全てではなく、スポット的に

・仮想化マーケットが、ぶわーっと来るかと思ったら、、、
・不景気のあおりでシステムの予算自体が、、、
・自分たちの技術などを積極的に出していこう
・みんなで乗り切るぜ、この不況
・お互いの情報をちゃんと交換しませう

・仮想化によるコスト削減
・構築は簡単だけど、設計がだ大変
・やらなきゃいけないのは仮想化だけじゃない
・トータルのサーバ構築の技術・センスが必要

・プロのテクニックとは
・知ってるか知らないか
・仮想化に関しては、知ってる人が少ない
・プロを増やすことが仮想化マーケットを広げることに繋がる

・仮想化設計
・現時点での目的の多くは、既存環境の移行
・優先度的にはコスト、でもちゃんとしてれば下がる
・コストが高まる要因は、過剰なスペックを求めた部分
・きちんと設計していれば、過剰なスペックを求める必要はない
・残念ながら意志決定権を持ってる人たちは、この辺りのことに理解が乏しい
・だからこそ技術的に正しい方向を提示できるようにする必要がある
・適正な設計、足らなくなったら追加できるように

・仮想化マイグレーションプロセス
・普通のシステム構築の場合と同じ、ただ、マイグレーション先の検討・方法の検討などが加わる
・仮想化のメリットはいくつかあるけど、同時に全てのメリットを享受しようとしてはならぬ
・明確に一つの目標を達成する（多くても二つ）、その為に目標がぶれないようにする

・設計フェーズ
・論理設計→仮想化設計→物理設計
・仮想化→物理マッピング
・現時点での物理マシンのリソースから計算しちゃダメ
・ちゃんと計算すれば驚くほど物理マシンは減らせる
・ギリギリまで物理的なことは考えない

・コスト削減は、今までの見積もり法を変えなきゃいけない

・リソースプールは最低3台、冗長性を排除するなら1台でOK
・仮想マシンはリソースプール内のどこかで動いていると考える
・障害発生時はリソースプール内で相互にカバーする

・設計手順
・重要度及び負荷率をABCランク分け
・現場の感覚で構わないので、負荷をとりあえずつける、きっちりしたのは難しいからね
・マシングループ毎に仕分け
・グループ毎の要求リソース量を算出
・難しいのはI/O、これはきちんと取るべき、sarコマンドとかで
・CPUクロック数、メモリ量の積算値*60%
・ストレージはパスの帯域幅やディスク本数などで性能値が左右される、別途検討が必要

・ハードウェア選定のポイント
・メモリ量が仮想マシン収容力を大幅に左右、16GB↑
・高速なI/Oの装備が必須

・60%をやってると、異常発生時に性能劣化を考えなくてよい

・CPUよりもメモリの壁が先に立ちはだかる

・ブレードvsラックマウント
・4台以上ならブレードかも、最近はメモリを積める奴も増えてるし
・増加が予測される場合は、ラックはすぐにいっぱいに

・今後、ブレードへのHDDの搭載は減る方向に
・高クロックよりもコア数
・まず、1仮想CPUから始める、空回り・ロックは意外と落とし穴

・ネットワーク構成
・少なくとも2系統、4系統あれば
・ブレードはI/Oの追加が難しい
・（ebayで買うと安い、落札代行可能）

・I/O
・iSCSI、気軽でいいかも、ソフトウェアで実装できるし
・性能はFCだけど、コストが、、、

・NFS、意外と使える、特に更新系は
・検索に関してはメモリがpoorでもあり

投稿者 ymkx : 2009年2月20日 17:49 |