Amazon EC2で高速SSDを8つも搭載した新しいI2インスタンスのベンチマークをとってみた - 元RX-7乗りの適当な日々
AWS re:Inventで発表されていた、SSDによる高性能ランダムI/O用に最適化されたという、Amazon EC2の新しいインスタンスタイプ「I2インスタンス」が先日使えるようになりました。 インスタンスタイプとしては"i2.*"からはじまるやつです。 I2インスタンスタイプは、特にリレーショナルデータベース、NoSQLデータベース、およびトランザクションシステムによって生成されるI/O集約型のワークロードをホストするように設計されています。最も大きいサイズのI2インスタンスタイプは、4KBのブロックサイズでの計測で、秒間365,000を超えるランダムリードと秒間315,000を超えるランダムライトの性能を発揮します。4つのインスタンスサイズをご利用いただけますので、必要なストレージとI/O性能が高くなのに合わせて、小さくスタートし、スケールアップしていくことができます。 このインス
デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi - 元RX-7乗りの適当な日々
sonots先生の話を聞きに行ってきたので、そのメモを残しておきます。 瀬尾 直利 氏 DeNA Co., Ltd. AIシステム部 リードエンジニア DeNAの機械学習基盤 ディープラーニングの基盤 => GPU基盤 という認識 GPUすごくて、CPU使って30日のところ、GPUを使うと4日くらいのオーダー GPUの特徴 並列処理が得意 CPUだと24coreとかのオーダー GPUでは3000〜4000core 分岐処理は苦手 行列演算に向いている GPU製品 NVIDIA Tesla HPC向けにGPUシリーズ NVIDIA GeForce GRID クラウドゲーミング向け AMD FirePro NVIDIA Tesla API CUDA OpenCL DirectCompute CUDAのアーキテクチャ CPU(ホスト)からGPU(デバイス)にデータを転送 GPUで処理 GPUから
デブサミ2017「グランブルーファンタジーを支えるインフラの技術」講演メモ #devsumi - 元RX-7乗りの適当な日々
CAを離れて1年半。最近はどんな感じか知りたかったので聞いてきました。面白かったです。 グランブルーファンタジーを支えるインフラの技術 (株)Cygames 佐藤太志 氏 グランブルーファンタジーについて 特徴 スマホのRPG ブラウザゲーム 協力プレイ、マルチプレイ システム規模 登録ユーザ数1400万人 月間300億PV 100万query/sec 8万req/sec トラフィック12Gbps (CDN除く) システム構成 LBはBIG-IP CDNはAkamai HTTP/WebSocketがフロントインターフェース Web: Apache + mod_php + mysqli Node: Node.js + twemproxy DB: MySQL + MHA オンプレミス、仮想化環境は使っていない ネットワーク通信量が非常に多い 低レイテンシを求められている ハイパフォーマンスを実
Quaggaを使ってLinuxサーバで動的ルーティング - 元RX-7乗りの適当な日々
Quaggaは、UNIX/Linuxプラットフォームで動くルーティングソフトウェアです。 OSPF、BGP、RIP等のプロトコルが実装されていて、GNU Zebraから派生したソフトウェアだとか。 某所の環境が、ロードバランサを設置(というかLBに仮想IPアドレスを配布)すると上位のルーターにそのLBへのルートが必要となるネットワーク構成だったので、ソフトウェアベースのLinuxロードバランサに、こいつを入れて、OSPFで動的な経路広報(ダイナミックルーティング)ができるか検証してみました。 インストール 今回、OSはCentOS 6系で動かしてみました。 CentOS 6系で、Quaggaはyumリポジトリに入っていますので、 # yum -y install quaggaでインストールできると思います。 僕は、最新版で動作検証してみたかったので、公式のダウンロードサイトから最新版(現在
サイバーエージェントを退職します - 元RX-7乗りの適当な日々
私事ですが、タイトルの通り、(株)サイバーエージェントを退職します。昨日8/31が最終出社でした。正確に書くと退職日はもう少し先です。 入社日が2010/09/01だったので、ちょうど丸5年が経ちました。在籍中は、社内外の皆様に多くのご協力を頂き、様々なことにチャレンジすることができました。本当にありがとうございました。 5年もやっていると、それはもう毎日飽きないくらい良い事も悪い事も色々ありましたが、エンジニアとして技術面、および人間として考え方の幅が大きく広がったと思っていて、良い成長機会を頂けたと思っています。 会社として伸び盛りの重要な大規模サービスやプラットフォームサービスに大きく関われた事、様々な技術的挑戦をさせてもらえた事、その上でそれなりの事業貢献ができた事、そして多くの優秀なメンバーと共に刺激を受けながら仕事ができた事、その全てが素晴らしい経験となりました。 私がやってき
NVMe SSDのベンチマークをとってみた (約70万IOPS/1台) - 元RX-7乗りの適当な日々
手元にNVMe SSDがあったので、自分でベンチマークを取ってみたログ。 NVMeってのは、ストレージデバイスを接続する際の規格で、従来でいうSATAインターフェースの仲間みたいなもの。NVMeの詳細は以下のリンク先に記載があるので読んでいただきたい。 NVMeは、SCSIやSATA（Serial ATA）と同じく、ストレージを接続するための規格だ。パイプラインやランダムアクセスなど、メモリーベースのストレージであるSSDの特徴を活用できる。また、SATAやAHCIの登場から現在までの間に進化した、データのレイテンシー（遅延時間）短縮のための手法も反映している。 具体的な改良点としては、4KBの転送に必要なメッセージが2つではなく1つで済む点や、コマンドを処理するキューが1つではなく複数になっているという点がある。「複数」というのは、実に6万5536個である。これにより、多数のディスクI/
Linuxサーバに搭載されているCPUコア数の確認 - 元RX-7乗りの適当な日々
この前、若手に聞かれたので、ここにも書いておく。 好みでは有るが、可能な限り数字のみで標準出力に出せるようにしておくと、スクリプトの中などで並列実行数を動的に定義しやすい。 ちなみに下記の前提は、CentOS 6.6 & 56コア(！)のサーバで確認している。 nproc # nproc 56一番簡単なやつ。 getconf # getconf _NPROCESSORS_ONLN 56getconfでも拾える。 /proc/cpuinfo # cat /proc/cpuinfo | grep -c "processor" 56皆さん、ご存知の通り、 /proc/cpuinfo は多くのCPU情報を取得することが出来る。 余談だけど、 /proc/cpuinfo に含まれる"physical id"はどの物理ソケットか、とか、"core id"を見ると物理コア(HT関連などで論理コアの紐付き
Linuxでストライピング(RAID0)なソフトウェアRAIDを組んでいた際にデバイスが外れてしまった場合 - 元RX-7乗りの適当な日々
若手が(ry・・・シリーズ。次から他の人にやってほしいのでｗ 共有用のメモを残してしておきます。 Linuxのサーバで、ソフトウェアRAID(ストライピング)を組んでいたときに、片方のデバイスが不調で外れてしまったんだけど、デバイス内のデータは無事で、復旧(RAID0再構成)させたい場合のオペレーション。 ちなみに、たまたまなんだけど、ちょうど8年くらい前に似たようなエントリを書いていた。参考までに。 ソフトウェアRAIDのデグレード(縮退)モードからの復旧 - 元RX-7乗りの適当な日々 RAIDデバイスの確認と試行錯誤 外れてしまったデバイスは、問題なさそうってのは確認済み(本エントリでは割愛)で、あとは正常なRAIDデバイスに戻したいフェーズ、ってのが前提。 (自分が作ったサーバではないので、アレやコレやと確認しながら手探りになってしまっていますがｗ) # cat /proc/mds
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
NFSのチューニング - 元RX-7乗りの適当な日々
何故か遅いNFSをチューニングするべく検証。 # 5MBの書き込みに27秒もかかるのはちょっと。。。 下記の検証結果が、全ての環境であてはまるわけではないため、ご参考程度までに。 検証時の構成 Linux(Xen domainU) ---NFS mount---> Linux(Xen domain0)Xenのバージョンは3.0.2(linux kernelは2.6.16)。 # NICのデバイスも所詮はXenによって仮想化されているので、それほど参考にならないかもなぁ・・・。 実験内容 設定をいじる server: /etc/exports client: autofs(/etc/auto.master) マウント先に、5MBのブロック(1ファイル)を書き込み # マウントポイントの名前は適当(^^; 設定1(syncのみ) server: /home/share client_hostn
新しいSSDベースのEBSボリューム(General Purpose)のベンチマークをとった - 元RX-7乗りの適当な日々
昨日の Amazon Web Services からの公式発表により、Amazon EBSのボリュームとして、「General Purpose (SSD)」が選択できるようになりました。詳細は、以下のAWS公式ブログにてご確認ください。 Amazon Web Services ブログ: 【AWS発表】新しいSSDベースのElastic Block Storage で、で、既に今回追加された新しいEBSのボリュームタイプに関しては、以下のエントリでまとめられています。 http://rimtty.hatenablog.com/entry/2014/06/17/184348 へー、なるほどねぇ、、、とか思いながら読んでいたのですが、最後のところで、 新型EBSのベンチマークについては、いつもの id:rx7 さんが颯爽ベンチってくれると思うので待ちます。 http://rimtty.haten
DeNA松信さんの「MySQL環境におけるFusion-io検証結果とDeNAにおける活用価値」セッションメモ - 元RX-7乗りの適当な日々
弊社の一部のサービスでも絶賛活躍中のFusion-io社のioDrive。 Fusion-io ioDriveとFusion-io ioDrive Duoではどちらも、最小容量のモデルはSLC型、そのほかはMLC型を使っているが、Fusion ioDriveの読み込み速度は735〜770MB/s、書き込み速度は510〜750MB/sだ。Fusion ioDrive Duoに至っては、読み込み速度は1.0〜1.5GB/s、書き込み速度は一律1.5GB/sという数値をたたき出す。 ＠IT Special PR：Fusion-ioのクールな技術を使いこなせ！ 今日はデルさん主催の下記セミナーにて、このFusion-ioに関するDELL社の検証結果紹介や、DeNA松信さんによるMySQL環境でのFusion-io検証結果およびDeNAでの利用に関するお話が聞けるとのことだったので、途中からの参加で
Redis(2.8系)の基本オペレーションとかSentinelの挙動とかの色々メモ - 元RX-7乗りの適当な日々
最近必要に迫られて、ようやくRedisをインストールして触ってみました。(Redis童貞からの脱却) 色々と、基本部分ではあるけど、せっかく実際に触りながら勉強したので、このエントリにメモしておこうと思います。 尚、使ってみたRedisのバージョンは、stableの最新版である2.8.7です。(OSは、LinuxのCentOS 6.5) ちなみに、このエントリに書いていないような、Redisの基本的なアレコレについては、WEB+DB Press Vol.73のRedis特集(2.6向けではありますが)にほとんど書いてあるので読むべし。 WEB+DB PRESS Vol.73 作者: 設樂洋爾,白土慧,はまちや2,大和田純,松田明,後藤大輔,ひろせまさあき,小林篤,近藤宇智朗,まかまか般若波羅蜜,Mr. O,川添貴生,重国和宏,柳澤建太郎,奥野幹也,佐藤鉄平,後藤秀宣,mala,中島聡,堤智
MySQLのホストキャッシュ - 元RX-7乗りの適当な日々
MySQL 5.5 のホストキャッシュに関するメモ。 詳細は以下ドキュメントに全て書いてある。(英文) MySQL :: MySQL 5.5 Reference Manual :: 8.12.5.2 DNS Lookup Optimization and the Host Cache シーケンス 新しいクライアントから接続があると、サーバはそのIPアドレスからホスト名がホストキャッシュにあるかチェックする。 無ければ、サーバはホスト名を解決することを試みる。 まず、IPアドレスからホスト名をチェックし、そしてホスト名からIPアドレスをチェックする。で、その結果をオリジナルのIPアドレスと比較し、同じであることを確認した後、ホストキャッシュに格納する。 キャッシュが一杯の場合は、最も長い時間使われていないエントリが破棄される。 名前解決 OSがサポートしている場合、スレッドセーフな geth
nscdが保持しているキャッシュをクリアする - 元RX-7乗りの適当な日々
hostsファイルの記載に誤りがあるまま、telnetコマンドを実行した。 で、誤りに気付き、hostsに記載のIPアドレスを修正し、telnetコマンドを再度実行したが、なぜか古い記載のアドレスに接続しにいく。 むむっ、と思って、straceしてチェックしたら、 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0↑の通り、nscdを見に行っておった。 # nscd -i hostsということで、↑のような感じで、nscdの持っているhostsのキャッシュを破棄して、無事期待通りの動作になった。 ・・・たまに調べるから、ここに残しておく。 それでは！ =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́ 追記 やっぱりそうだよなぁ。うーむ。 デーモンは( pas
Linuxで使っているNICのドライバやバージョンを調べる方法いろいろ - 元RX-7乗りの適当な日々
稼働しているLinux OSで、ネットワークインターフェースにどのドライバ(のどのバージョン)が実際に適用されているのか、をどうやって調べたくなる時があります。 覚えている限りでその色々を書いてみる。ちなみに、以降の紹介例ではCentOS 6系で試してみました。 他にナイスなやり方とかご存知であれば、教えてください。 dmesg (or /var/log/boot.log) dmesgのバッファ溢れが起こっていない前提で、dmesgからチェックする方法。 使っているインターフェース名でgrepる。 # dmesg | grep eth0 igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:26:xx:xx:xx:xx igb 0000:01:00.0: eth0: PBA No: 313130-032 ADDRCONF(NETDEV_UP)
HAProxyのパフォーマンスチューニングをやったメモ(CPS編) - 元RX-7乗りの適当な日々
HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。 基本的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。 あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。 前提 HAProxyを動かすのに使用した環境は以下の通り。 Server: DELL PowerEdge R420 CPU: Intel Xeon E5-2430L @ 2.00GHz * 2 Memory: 96GB Ethernet controller: Intel Corporation Ethe
TIME_WAIT状態のTCPコネクションを早く終了させるべくKernelをリビルド - 元RX-7乗りの適当な日々
以前、一度やったはずなのですが、すっかり忘れてしまっていて、結局調べることになったので、今回はここに作業ログを残しておきます。 TIME_WAITコネクションの増殖 一般的にネットワークアクセス数が極端に多いサーバでは、TIME_WAIT状態のコネクションが残留しがちです。 TIME_WAITの滞留時間が、Linuxデフォだと60秒になっているため、下記のエントリにも書きましたが、60秒の間に数十万レベルのリクエストが来るとあっという間にコネクションテーブルが埋まっていってしまうわけです。 で、別にTIME_WAITコネクションが多くなってしまうこと自体は、完全な悪というわけでもなく、 "net.ipv4.tcp_max_tw_buckets" あたりでキャップもできるし、それなりに制御して付き合っていけばいいわけですが、ローカルのTCPポートを使い切るようなケースだと、使えるローカルポー
HAProxyを透過型のプロキシとして使う(HAProxy with tproxy) - 元RX-7乗りの適当な日々
HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。 で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。 使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。 参考: Transparent proxy support (www.kernel.org/doc) https://www.kernel.org/doc/Documentation/networking/tproxy.txt Linux kernelのnf_tproxy_coreモジュールを
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
