タグ

ブックマーク / dsas.blog.klab.org (7)

  • 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 でのレプリケーション遅延は危険 : DSAS開発者の部屋
    k12u
    k12u 2014/07/24
  • TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋

    昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日海外の間を結ぶ長距離ネットワーク(いわゆるLong Fat pipe Network)において、通信時間を削減するにはどうしたらいいか?」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間(伝送遅延)を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日国内のホスト同士であれば、RTT(往復遅延時間)はだいたい10〜30ms程度ですが、日・北米間だと10

    TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
    k12u
    k12u 2014/04/29
  • Windows用フリーウェア「WinAmulet」を公開します : DSAS開発者の部屋

    ・「イージスガード」公開のお知らせ (2009/10/06) WinAmulet 上位互換の「イージスガード」を個人用フリーソフトとして公開しました。イージスガードに使用制限はありません。今後はぜひこのイージスガードをご利用下さい。 ・WinAmulet 終了のお知らせ(?) (2009/08/13) ■ はじめに 私の PC には個人的なファイルをたくさん保存しているフォルダがあります。その中身は、住所録や思い出のスナップ、メールデータやちょっとした秘密のメモなどさまざまです。 ある時ふと思いました。これらのファイルを読み書きするときに使うプログラムはごく限られています。 普段自分がそれ以外のプログラムを使ってこれらにアクセスすることはありませんし、まして、たとえ Windows のシステムプログラムであっても、自分の意図とは無関係に動いているプログラムからこれらに勝手にアクセスされるの

    Windows用フリーウェア「WinAmulet」を公開します : DSAS開発者の部屋
  • apache module 開発事始め : DSAS開発者の部屋

    先日は,必要に迫られて Apache 1.3 の mod_access を改造したという話を書きました.その時は単にあるものを改造しただけでしたが,ふと思い立って,一から Apache 2.0 用のモジュールを書いてみました.書く上で色々 Web サイトを探してみたのですが,あまり日語の入門向けの文章が見あたらなかったので,開発する上で分かったこと(と言うほど大したものじゃないですが)をまとめておこうと思います. フェーズには,例えばそのリクエストを受け付けるか拒否するかを決めるフェーズや,リクエストされた URI と実際のディスク上のファイルとの間の対応付けを解決するフェーズ,そしてもちろん実際のレスポンスを生成するフェーズ等があります.hook 関数を挿入するポイントはこれらのフェーズになりますが,もちろんその全てのフェーズのための関数を用意する必要はありません.また個別の設定を施す

    apache module 開発事始め : DSAS開発者の部屋
  • カラフル端末で視認性を高める - grepとシェルのプロンプト編 : DSAS開発者の部屋

    このブログに含まれる「DSAS」という文字列をgrepしてみます。 どこに「DSAS」があるのかさっぱりわかりません (^^; grepの結果を| less -p DSASとかに渡せばlessがハイライトして識別しやすくなるのですが、ここはgrepのカラフル機能(--color=auto)を使ってみます。 だいぶ識別しやすくなりました。 ハイライトの色を変更するには、色指定を環境変数GREP_COLORにセットします。指定の形式は前回紹介したlsのdircolorsと同じです。例えば、太字の黄色にしたい場合はこのようにします。 export GREP_COLOR='01;33' あと、毎回--color=autoと指定するのは面倒なので、環境変数GREP_OPTIONSにセットしておきましょう。GREP_OPTIONSにセットしたオプションは、暗黙的に効果を発揮します。 export GR

    カラフル端末で視認性を高める - grepとシェルのプロンプト編 : DSAS開発者の部屋
  • DSAS開発者の部屋:そのディスク、捨てる前に 〜shredで内容消去〜

    かたちあるものいつかは壊れます。ハードディスクも例外じゃありません。 DSASはサーバが200台近くあり、複数台ディスクを積んでいるサーバもあるのでディスクの数はそれ以上です。これだけディスクがあると、どれかが壊れる確率はそれなりに高くなります。 ちなみにDSASは、 Webサーバは数十台あってディスク内容は全サーバで同期している。 DBサーバのデータ格納用ディスクはRAIDを使っているし、レプリケーションもしている。 LVSを使っている負荷分散機などいくつかのサーバはネットブートでディスクレスにしている。(のでディスク故障とは無縁) というふうに、ディスクが数台壊れたぐらいではサービス停止することのない構成になってます。 でも、壊れたディスクはデータが入っているのでそのままゴミ箱にポイというわけにはいきません。 rm -frで消したりfdiskでパーティションテーブルを壊したとしても、い

    DSAS開発者の部屋:そのディスク、捨てる前に 〜shredで内容消去〜
  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • 1