ある事情で、サーバ上で多数のRailsアプリケーションを動かす必要性にせまられたので、1Railsアプリあたりの使用メモリ量を少しコンパクト化するべく、「Ruby Enterprise Edition」(REE)を試してみたところ、確かにメモリ使用量が削減された結果(当方例で約43.5%減)になったので、そのメモをエントリに残しておきます。 Ruby Enterprise Edition (REE) とは マイコミジャーナルから引用させていただくと、、、 REEはCRubyをベースにして開発されている実行環境。オフィシャルのCRubyと比較して平均で33%ほどRailsアプリケーションが使用するメモリ量を削減できるという特徴があるほか、実行パフォーマンスも改善される。 REEにおける性能向上の仕組みはガベージコレクタに対してCopy-on-Write拡張を導入することと、メモリアロケータ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ウェブ上の概要を読むだけでは、なにやら楽天が技術的なカンファレンスをやるらしい、という事しかわからないのだが、ネット上のコミュニティ（メーリングリスト）では具体的に色々とリークされていたのが興味深い。Ruby をつくった まつもとゆきひろ氏の講演だとか、楽天の技術についてだとか色々興味深いセッションが盛りだくさんですた。ネットのコミュニティにしか敢えて情報を出さなかったのは、来社層の選別をしたかったのかな？と。 自分がコミュニティ系で気がついたのは Linux-users での告知。Linux ユーザーズグループメーリングリストでは 11/14 の時点でメールが流れていました。そのほかにも Debian のML、Gentoo のMLとかでも、LUG 系でもちらほら拝見。 [linux-users:108143] カーネル読書会番外編、ディストリビューション大集合 ちなみに無料でした。一切合
1000人以上のエンジニア、全国各地に開発拠点をもっている 楽天のテクノロジーカンファレンスにいってきました。 分散並列処理フレームワークfaily,P2PオンメモリストレージROMAが 2009年にOpenSource化されるとのことでした。 楽天ウェブサービス APIの紹介 16種類のAPI 直近だと楽天ランキングAPI 1500万件,2万件の宿泊施設 Affiriateと連動可能 REST,JSON,SOAPのフォーマットをサポート 楽天ダイナミックアド 楽天版アドセンス 記事の内容にマッチした楽天の商品を出す 楽天経済圏 APIを使ったアプリが入り込める マッシュアップブームおちちている ALL 35,000ID Active 5,000ID Webサービス経由の流通金額は7.24% 3,500万request/day ItemSearch,GenreSearch,Itemcode
Ruby会議2008の2日目は、基本、SKIPブースにいたので、サブセッションをぼんやりと聴いていたのですが。 1つだけどうしても聴きたかったメインセッションのプログラムが「食べログ」の事例。 Railsで作られたシステムとしては、国内一とも言われる規模のシステムの裏側という貴重な事例発表だったので、メモを残しておきます。 Inside Tabelog's Backend Windows + ASP ⇒ Railsへ 発表者の京和さんはRails化を提案した本人 食べログ.com について 7000万PV/月 600万 UniqueUsers PV/月 サーバは全部で13台 Apache x 2 + Mongrel x * + MySQL x 3 (master/slave/slave) ruby1.8.6 rails 1.2 Mongrelについて メモリの使用量 4〜5日で8GBのメモ
最近話題の ActiveScaffold の開発メンバーでもあるLance Ivy氏のレポート。 How Rails' Benchmarks Lie I’ve been on a benchmarking blogging spree lately. Creating BenchmarkForRails (B4R) with its non-invasive benchmarking technique has made it very easy to play around with timing of key Rails methods and develop a better picture of the true costs. The results have been amazing. Railsのベンチマークでは測定しきれない部分の ベンチマークを可能にする Benchmark
Sourcecode require 'cgi' puts <<-HEAD <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" version="-//W3C//DTD XHTML 1.1//EN" xml:lang="de"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>Ruby 1.8 vs. 1.9 Benchmarks</title> <style type="text/css" media="screen"> html { font-
先に。所々きっつい突っ込みするですが(って思ったけどそうでもなかった)、全体としては「わりあいによい感じ」でした。 まず「高負荷」の定義がちゃんとあるのがぐっど。且つ、対応の角度があちこちに散らばってるのもぐっど。 ってあたりは、ほかの普通の講義にも参考にして欲しいなぁとか思う事しきり。 # 高負荷の講義やって「高負荷の定義は？」って質問に固まられるとこっちが固まっちゃいますがな。 まずターゲティングされてるのが「CPU負荷の増大」。最終的には「プロファイラつかえや」とかになるのでしょうが。 とりあえず「ループの中をチェック」とか「でっかいデータとかファイルとか」「画像処理とか動画処理とか」。 うんまっとうだけど…割合に最近の若い子が知らない話なのかも。８２の法則とかいう話が昔話になられても困るんだけど(苦笑 DBがボトルネックってもも結構多々。個人的には「５＋重(５重以上)にネストしたお
コンピュータのメモリ容量を超えるサイズのプログラムを実行する必要がある場合、最近のオペレーティングシステム（OS）のほとんどはスワップ処理と呼ばれる手法を用いる。これは、メモリ内データの大部分を一時的にハードディスクに格納しておき、必要なデータだけを物理メモリ空間に持ってくるというものだ。本稿では、Linuxシステムにおけるスワップ処理の効率化とスワップ処理サブシステムのパフォーマンス最適化につながるテクニックを紹介する。 Linuxは、物理メモリの領域をページという単位に分割して処理する。スワップ処理とは、ハードディスク上にあらかじめ設定した空間（これをスワップ空間と呼ぶ）にページ単位でメモリ上のデータをコピーし、そのページのメモリ領域を解放する処理をいう。物理メモリとスワップ空間を合わせた容量が、仮想メモリとして利用可能になる。 スワップ処理が必要になる主な理由は2つある。1つは、物理
ワークパイル（Work pile）は、並列処理の為のアルゴリズムの一種です。 lucille 開発日記: マルチスレッド化: ワークパイル 簡単に云ってしまえば、ワークパイルはサーバ/クライアント機構と似たようなもので、ジョブを処理するスレッド部分ではマスタースレッドから仕事(ジョブ)を受け取って処理し、仕事がなくなるまでループするというものです。 いわゆる生産者消費者問題を解決する手法の一つですね。 ちょっとサンプルコードを見てもらったほうがはやいかも。 workpile.rb 1 require 'thread' 2 3 class Workpile 4 def initialize(num_workers) 5 @queue = Queue.new 6 @workers = ThreadGroup.new 7 8 # Spawn worker threads 9 num
見本誌届きました。今月の連載は UNIX ネットワークプログラミング入門と POE について。IO::Socket でソケットAPIをいじりながら echo サーバーを並行処理なし → fork → IO 多重化まで発展させていき、イベント駆動でネットワークプログラミングしたい故に POE 導入...というところまで解説しています。 次回後編は POE の詳しい使い方を中心に、面白い POE::Component::* を各種紹介するといったところまで書ければと思います。 今月号の見所はやっぱり廣瀬さんの LVS の記事ですかね。あと Flex2 開発入門とかも。Flex 盛り上がってきてますね。 調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱され
いまシステムがどの程度I/O待ちを喰らっているかを判断するには以下のようにiostatで判断できます。 # -c がミソ [hoge@hogelinux]% env LANG=C iostat -c 1 100 avg-cpu: %user %nice %sys %iowait %idle 0.00 0.00 0.00 0.00 100.00 この%iowaitに着目します、平常時はこうしてほとんどゼロに近い値です。 そこでたとえば以下のようにベラボーにDISK-I/Oを発生させます。 [hoge@hogelinux]# dd if=/dev/zero of=/var/tmp/a.out bs=1024k count=10240 & [hoge@hogelinux]# dd if=/dev/zero of=/var/tmp/b.out bs=1024k count=10240 & [hog
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ （「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました） InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能（同期書き込み） innodb_flush_log_at_trx_commit=1,0,2
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
サーバのチューニングをする上でかなりやっかいなのがデータベース系。特にログファイルの量が膨大になると後から中身を見て問題を分析するのも一苦労という場合が。そんなときにこのMySQL用topコマンド「mytop」を使えば一体何が起きているのかがすぐにわかるので問題点の把握が容易になります。ベンチマークするときに併用すればかなり効率が良くなるのではないかと。 インストールと使い方は以下の通り。 まずは「mytop」から。以下が公式サイト。 mytop - a top clone for MySQL http://jeremy.zawodny.com/mysql/mytop/ マニュアルは以下にあります。 mytop - display MySQL server performance info like `top' インストールするにはSSHなどを使ってrootでログイン後、wgetでファイル
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
元ネタ: http://labs.unoh.net/2007/07/mysqltips.html あまり具体的じゃないので、僕の考えとか。 正しいかどうかは各自の状況だとか実際試すべきなんだけど、参考になれば。 MyISAM、InnoDBなどテーブルタイプ 僕は断然InnoDB派です。 ただ仰るとおり、ログるだけのテーブルとかならMyISAMでもいいとは思うけど。 トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。 これだけの指摘だとちょっと微妙な気がするです。 MyISAMの使いどころってのは、 ピンで他とリレーションが無い単純追記系のテーブル リレーションがあり、同一トランザクション内での更新系クエリが存在する場合は、トランザクションが期待通りに動かないので、基本的にはInnoDBと混在させるべきではない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
