Mackerelチームのエンジニアのid:itchynyです。 「mackerel-agentを入れるとloadavgが7時間ごとに上昇する」 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada

JavaScript で高速なコードを書こうとする際に、はまりがちな罠と、JSX のコンパイラでどのように対処しているのかを紹介
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はsessionstackblog に投稿されている、HowJavaScript works シリーズの一記事 "HowJavaScript works: memory management + how to handle 4 common memory leaks" の和訳です。投稿されたのはAlexander Zlatkov, 原文はこちらです。翻訳については許諾いただいています。 メモリ管理もしくはC言語におけるメモリ解説他、用語なども怪しい箇所は多分にありますので、間違いがありましたら修正のご指摘・編集リクエス

Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う(?)SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR


ECMAScriptの改訂により、JavaScriptはよりシンプルな構文や、より厳密な構文が書けるようになってきています。以前、ES2015+相当のJavaScriptはES5相当へ変換したほうが実行速度が良くなるという話がありました(参照「2017-02-14のJS - JSer.info」)。JavaScriptプログラマーとしてはどのような書き方が最適なのか気になります。そこで、Chrome・Safari・Firefox Quantum・Edgeで、ECMAScriptの構文を一部ピックアップして実行速度を調べてみました。 パフォーマンスの計測方法 検証を行いたい構文を使ったコードを100万回実行・計測する関数を用意し、用意した関数を10回ずつ実行しています。 はじめに、for文を空の状態で実行するコードを用意しました。計測結果がミリ秒以下になる時があるため、さらなる精度で計測でき

JITでどれだけ速くなるか この世には「嘘」、「ひどい嘘」、そして「ベンチマーク」があります(訳注: 元ネタ)。JITによる高速化を正確な値で表すなど無理な相談です。正確な値など存在しないからです。しかし、特定のプログラムについては、完全に合理的な負荷をかけた状態で50%、150%、あるいは250%までJITで高速化できるケースが多々あります。現実的な負荷の元で、500%以上もの高速化を達成するケースすらいくつかあります。ただし、JITよりインタプリタの方が速いケースも若干あることは言うまでもありません。なぜなら、現実世界には常に最適化されているものなど存在しないからです。 現時点での無難かつシンプルなCRuby向けJIT実装では、およそ30%〜50%のパフォーマンス向上が見られ、測定方法次第では最大150%に達することもあります。30%〜50%はJITにしてはかなり控えめな値ですが、これ

[2017.12/7 13:00 更新] ISUCON7本選にご参加いただいた皆さん、ありがとうございました! こちらでは感想エントリや何をしたかに言及されたエントリをまとめていきます。見つけた順ですが後で何かしらのルールで並び替えます。もしここに載っていないものがある場合は ISUCON7本選のブログ書いたよ!フォームで教えていただけると助かります。重複はこちらでチェックしますのでドシドシお願いします。 ブログを書くまでがISUCONです!本選のTweetはこちらでまとめています ▼ISUCON7本選 Tweet まとめ#isucon -Togetter ・ISUCON7優勝しました [MSA] - mizkeiのブログ ・ISUCON7で優勝しました - ken39arg’sblog ・ISUCON 7 で優勝してきました | ジェットゾウ ・ISUCON 7本戦出場して

7 回目の ISUCON、なんとか 2 日通しの枠で予選通過できて本当に良かった。 今回も @mirakui, @rosylilly と一緒に白金動物園として参加しています。 今回はギリギリの集合ながら予定より開始が遅れたので、アニメを 2本見ました。結城友奈は勇者である -鷲尾須美の章- #2 はチームビルディングの話で景気が良かった [独自研究] し、その後も something 景気が良い物ということで Fate/Apocrypha #16 も見たけどこれも景気が良かったです。アストルフォ私服。 というわけで、白金動物園の手の内を公開します。ベストスコアは 34 万ほどで対したことないけど…。上位陣のスコアびびる。 実装 https://github.com/shirokanezoo/isucon7qRuby +Go… にする目論見が最終的にRuby のみです。ベスト 346
JavaScriptで画像処理などの重い計算をしているとどうしても気になるのがループの部分。実際の処理に加えてループの部分でのロスが気になり始めたので実際にどのループ方法が速いのか試してみました。 概要 0~9999999の長さ1000万の配列のすべてを足し合わせるという単純な計算を行います 配列は、各ループの前で常に初期化を行います。 ループはforまたはwhileを用います。foreachやforinは使いません。 v8(Node.js)、Chrome、Firefox、Safariで実験を行います 筆者が噂で聞いた5つのポイント(後述)を加味した計32種類のコードを自動生成し、実行します。 各プラットフォームで5回実行し、平均をとります。 ウェブブラウザではWebWorkerを用いて実行します。 結果は実行環境に左右されている可能性があります 環境MacBookAir (11-in

1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く