Metalの「shared CPU/GPU memory buffer」について : DSAS開発者の部屋
iOS8のリリースにより、A7を搭載したiOS端末からはOpenGLESに代わる新グラフィックスAPIであるMetalが動くようになりました。 iOS8発表時のAppleのKeynoteで紹介されたとおり、MetalはOpenGLとくらべてAPIの層が薄くて最適化されているので高速に動作するようで、他の多くの記事でもこの事が書かれています。 しかし実際にMetalに触れてみると、単にAppleのハードウェアに最適化されていてオーバーヘッドが低く速いということに留まらず、ある一つの特長に気付きます。 それは「shared CPU/GPU memory buffer」つまりCPU/GPU間でメモリが共有されているというものです。 ここでは今までiOSの３Dアプリケーション開発に利用されていたOpenGLESでのメモリの扱い方と比較しつつ、CPU/GPU間でメモリが共有されることのメリットについ
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う : DSAS開発者の部屋
MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う innodb_support_xa と binlog の危ない関係 で、 MySQL がトランザクションログのコミットをシングルスレッドでシーケンシャルに fsync していると書いたのですが、誤解だったのでその補足です。 タイトルの通り、 innodb_flush_log_at_trx_commit=1 の場合も、トランザクションログが fsync されません。トランザクションがディスクに書かれるシーケンスは次のようになります。 1. prepare (fsync) 2. write binlog (grouped, fsync) 3. commit このうち 1 は従来通り各スレッドで並列に実行され、 2 と 3 が昨日紹介した sql/binlog.cc の
innodb_support_xa と binlog の危ない関係 : DSAS開発者の部屋
昨日の記事 で innodb_support_xa = 0にすると RDS が速くなることを紹介したのですが、その後 Twitter で innodb_support_xa = 0 にするとクラッシュ時だけでなく通常時も binlog とトランザクションログの一貫性が無くなる（コミットする順序が前後する）可能性があることを指摘していただきました。 innodb_support_xa=0すると、トランザクションがコミットされた順番でバイナリログに載ることが保証できなくなるんだけどいいのかな？ DSAS開発者の部屋:AWS RDS の書き込み性能チューニング dsas.blog.klab.org/archives/52108… — ts. yokuさん (@yoku0825) 2013年4月24日 実際に、 MySQL 5.5 と 5.6 両方で、 innodb_support_xa の説明に
Isucon2参戦記(Q) : DSAS開発者の部屋
男の戦い recaro が使えないことになってメゲそうになったものの、 やれることがまだまだ残っているのに何もせずに負けるわけにはいきません。 「逃げちゃダメだ逃げちゃダメだ」と呟きながら、残り2時間弱でできそうなことは 全部やってしまいます。 @pandax381 に、リバースプロクシで静的ファイルを直接返す設定、死んだ Web サーバーの 代わりにリバースプロクシと同じサーバーとDB サーバーでWebアプリを動かす設定をお願いして、 Webアプリのチューニングを進めます。 Webアプリ側でやったことは、 (1) Webサーバーの meinheld 化, (2) ページキャッシュを アプリから返すのでその高速化, (3) マルチプロセスの対応とチューニング, です。 (3) のマルチプロセス対応ですが、もともとアプリはシングルプロセスで動かすつもりで、 状態やページキャッシュを全部アプリ
Isucon2 参戦記（破） : DSAS開発者の部屋
#isucon2 参戦記の第二部です。昨日の @methane の記事とオーバーラップする部分もありますが、僕の視点で当日の状況をレポートします。やっと nexus7 が手に入ってご機嫌な @pandax381 です。 決戦、渋谷ヒカリエ 当日寝坊してしまうという笑えない展開もなく、受付け開始と同時に入館し、すぐに @methane と合流。開始時間まで１時間くらい余裕があったので「こんな問題だったらここをこうしよう」といった感じで軽く打ち合わせしていました。 そして、@methane が共同作業用にAWSのインスタンスを上げてくれたので、そこに recaro のソースを持ってきたりしていたら、ちょうどいい時間に。 NHNさんからレギュレーションや注意事項の説明があり、いよいよ #isucon2 スタートです。 事前の打ち合わせ通り、僕はベンチマーク用のツールを走らせながら、どんなHTTP
ApacheのアクセスログをMessagePack形式で出力するためのモジュールを作りました : DSAS開発者の部屋
Apacheモジュールのログ出力、こんどはMessagePack版を作成しました。続いてはこちらをご紹介します。 Apacheのアクセスログを使い、ユーザアクセスの集計やパターン解析などというのは一般にどこでもやられていることだと思います。通常のアクセスログはテキストファイルなので、集計を行うためにスクリプト上で扱える変数・オブジェクト化が必要になりますね。1行ごとの各ログ項目を取り出すのに正規表現を使ったり、cutやawkなどを使い空白で分割するなど、色々工夫されていることと思います。 今回、MessagePack版のアクセスログ出力をやってみようと思い立ったのは、アクセスログをあらかじめ構造化済みの状態で保存しておければ、読み込みの際の解析する手間を省くことで解析処理の高速化が期待できるのではないか、そう考えたためです。MessagePackであれば、PythonやRubyはじめ様々な
DSAS開発者の部屋:そのディスク、捨てる前に 〜shredで内容消去〜
かたちあるものいつかは壊れます。ハードディスクも例外じゃありません。 DSASはサーバが200台近くあり、複数台ディスクを積んでいるサーバもあるのでディスクの数はそれ以上です。これだけディスクがあると、どれかが壊れる確率はそれなりに高くなります。 ちなみにDSASは、 Webサーバは数十台あってディスク内容は全サーバで同期している。 DBサーバのデータ格納用ディスクはRAIDを使っているし、レプリケーションもしている。 LVSを使っている負荷分散機などいくつかのサーバはネットブートでディスクレスにしている。(のでディスク故障とは無縁) というふうに、ディスクが数台壊れたぐらいではサービス停止することのない構成になってます。 でも、壊れたディスクはデータが入っているのでそのままゴミ箱にポイというわけにはいきません。 rm -frで消したりfdiskでパーティションテーブルを壊したとしても、い
bitsliceによる超高速ビット演算 : DSAS開発者の部屋
bitslice とは Hack the Cell '09 に参加して知った、Cellに限らず一般的に使えるビット演算の高速化手法について紹介します。 Bitslice と呼ばれる手法では、ビット順を90度回転します。言葉で説明するよりもコードを見たほうが早いので、回転させるコードの例を見てください int x[32], y[32]; // x が元のデータ、y が回転後のデータ. for (int i = 0; i < 32; ++i) { int t = 0; for (int j = 0; j < 32; ++j) t |= ((x[j] >> i) & 1) << j; // x[j] の i ビット目を y[i] = t; // y[i] の j ビット目にする } この変換をすることで、y[0] には x[0] - x[31] の最下位ビットが、 y[1] には 2番目のビット
chumbyにsshログインしてオレオレswfを実行するまでのメモ : DSAS開発者の部屋
もうすぐChumby Niteが開催されるようですが、 たまたま某所からchumbyをお借りしたので、chumbyハックの導入として、 sshでログインできるようにする 自作のswfファイルを実行する ところまでのメモを残しておきます。 事前にやること - アカウントを作る chumbyが届いたら 無線LANに繋げる アクティベーション sshでログインできるようにする sshd起動の制御 (おまけ) FBCGI - chumbyの画面をPCブラウザでみる 自作swfを動かしてみる chumbyでサポートしているFlashのバージョン swfを実行する方法 (1)直接実行 (2)チャンネルの中から実行 swfファイルを作る Hello World! こんにちわ！こんにちわ！ 事前にやること - アカウントを作る 予めchumbyのサイトでアカウントを作っておきます。chumby本体をアクテ
Erlang で memcached を作ってみました。 : DSAS開発者の部屋
先日、こちらの Erlang の世界ではmemcachedとか要らない を興味深く読ませて頂きました。 たしかにクライアント側も Erlang で書かれている場合、例えばキャッシュサー バーにアクセスを行う WEB アプリケーションも Erlang で書かれていれば Erlang のプロセス間通信を使用することで簡単にキャッシュサーバを実装する ことが出来そうです。しかし、WEB アプリケーションなど、全てのシステムを Erlang で書くにはまだ私にとって勇気が要る事なので TCP/IP で memcache プ ロトコルを喋る Erlang 版 memcached を作ってみました。 その名も ememcached です。 % ememcached.erl -module(ememcached). -export([start/0, ememcached/1, process_comm
swfmillでFlash Lite 1のswfを扱えるようにしてみた : DSAS開発者の部屋
Flashに関連するオープンソースなツールのひとつに、swfmillがあります。swfmillは、swfファイルを解析してxmlファイルに変換したり、逆にxmlからswfファイルを生成することができるツールです。swfmillの使い方についてはいろいろなところで紹介されているので、ここではFlash Lite 1.xのswfファイルをswfmillで扱うときの問題点について紹介したいと思います。 swf内の文字コード FlashはVersion 6からUnicodeに対応しました。Unicode対応前と対応後でswfファイル内の文字エンコードが異なり、対応前はcp932(日本語の場合)、対応後はUTF-8になります。 そして、Flash LiteとFlashのバージョン間対応ですが、Flash Lite 1.xはFlash 4がベースになっており、Flash Lite 2.xはFlash
DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します
『Linuxロードバランサ構築・運用ノウハウ』を公開します！ これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux＋IPVS＋keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください！ 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか？ サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す
DSAS開発者の部屋:携帯ゲートウェイのIPアドレス帯更新を効率的に確認する方法
携帯電話各キャリアは、そのゲートウェイのIPアドレス帯域を公開しています。 DoCoMo au SoftBank WILLCOM 携帯ブラウザからのアクセスの場合、このIPアドレスがソースアドレスとなるので、アクセス制御や判別のために使っている方は多いのではないかと思います。 今回は、このIPアドレス帯の更新を効率的に確認する方法についてのお話です。 更新されたかどうかの確認だけならアンテナ系のWebサービスを使えばよいのですが、それだけだと、 どのIPアドレス帯が追加・削除されたのかわかりづらい。 IPアドレス帯のコピペが面倒くさい。 といった不満点があります。 そこでNet::CIDR::MobileJPというPerlのモジュールの出番です。(作者はモバイルファクトリという会社の方のようです) このモジュールには与えたIPアドレスが携帯かどうかを判別する機能があるのですが、次のようにす
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
