Server Side Renderingについて知るべきこと。Server Side Renderingとは何か？ それによって何が改善されるのか？（前編） ng-japan 2017 JavaScriptフレームワークとして知られるAngularのイベント「ng-japan 2017」がAngular Japan User Group主催で6月17日に都内で開催されました。 Angularは基本的にWebブラウザで実行されるJavaScriptアプリケーションのフレームワークですが、一方でサーバサイドでAngularが備えるHTML構成機能を実現する、いわゆるServer Side Rendering機能の開発も「Angular Universal」として進んでいます。 そのため、Server Side Renderingに興味を持つAngularデベロッパーも増えてきました。 ng-
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
はじめに 本連載の第2回『ベアメタル環境とDockerコンテナ環境の性能比較』で実施したコンテナ環境とベアメタル環境との性能比較では、コンテナ環境は高負荷時に挙動が不安定になるという結果となった。本記事には皆様からTwitterなどのソーシャルメディアを通じて、検証についてのご意見や問題点の解消方法について貴重なご指摘をいただいている。今回はこれらを参考に、発生したパフォーマンス劣化の原因の調査と改善策を模索していきたい。 まず筆者が目をつけたのは、Dockerが利用しているコピーオンライトデバイスの部分がパフォーマンス劣化の原因となっているのではないだろうか？ という点である。実際にテストを実施しながら検証していきたい。 ストレージドライバとは ストレージドライバは、物理サーバ上ではストレージ（HDD）コントローラのチップセットドライバだが、Dockerではコンテナ記憶域に使用されるコピ
Apache Cassandra® connector for Apache Spark™: 5 tips for success Overview We have just hit the full release of the Instaclustr managed Cassandra + Spark service offering after 4 months in preview release. During this time, we have had lots of opportunities to get in-depth with using the Cassandra connector for Spark, both with our own Instametrics application and assisting customers with developi
大きな効果を上げるために チューニンガソン#1～#3の改善率を見ると、アプリケーションや全体のアーキテクチャに手を入れないで改善できるのは最大でも10倍以下です。もちろん数倍速度が違えばサーバ台数を大きく減らせるので有意義なのは間違いないのですが、ISUCONやチューニンガソン#4のような飛躍的な高速化は望めないことがわかります。 つまりチューニングでは、単にパラメータ設定を変更するのみではなく、ボトルネックになっているコードやクエリ、アーキテクチャに的確に手を入れていくことで大きな効果を上げることができるのです。 ボトルネックの発見と解消が大事 システム全体の処理時間についてパレートの法則（経験則）を適用すると、「全体の処理時間の80％は20％の部分で発生している」ということになります。実際にシステム全体で一番ボトルネックになっている部分を解消しないことには、ほかの部分に手を入れても大
2. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 自己紹介 2 • 谷本 心 (Shin Tanimoto) - Acroquest Technology株式会社 - 開発＆トラブルシュート教育 - JavaOneスピーカー - JJUG / 関ジャバ / S2JSFコミッタ - Twitter : @cero_t (日本語) - Facebook : shin.tanimoto (英語) 3. Copyright © Acroquest Technology Co., Ltd. All rights reserved.Copyright © Acroquest Technology Co., Ltd. All rights reserved. 世の中のシステムは 完璧だろうか？ 3 4. Copyrigh
Linuxのネットワークパラメータの一つに、net.core.somaxconnというのがあります。これはlisten(2)の第二引数backlogの上限値となっています。このsomaxconnは一見intに見えますが、実はunsigned shortの範囲の数値しか受け付けません。それを超える数値を入れると黙って切り捨てられます。つまり -1→65535 0→0 65535→65535 65536→0 65537→1 と同じような動作を内部的にします。なので、この値は絶対に0～65535の範囲を超えてはいけません。以下、詳しい説明です。 おことわり: この仕様はLinux 3.11以降変更されており、範囲外の数値を設定できないようになっています。ここに書いてある内容が再現するのは、Linux 3.10以前の古いカーネルのみです。 まずsysctlの定義ですが net/core/sysct
こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha
パフォーマンスチューニングガイド 1. 概要 Expand section "1. 概要" Collapse section "1. 概要" 1.1. 本書を読むにあたって Expand section "1.1. 本書を読むにあたって" Collapse section "1.1. 本書を読むにあたって" 1.1.1. 対象読者 1.2. リリースの概要 Expand section "1.2. リリースの概要" Collapse section "1.2. リリースの概要" 1.2.1. Red Hat Enterprise Linux 6 における新機能 1.2.2. 水平方向のスケーラビリティ 1.2.3. 分散システム 2. Red Hat Enterprise Linux 6 のパフォーマンス機能 Expand section "2. Red Hat Enterprise Li
こんにちは。 前回までの内容で標準の4KBページを使用した場合、最大でSGA/512=PTE/1セッションであることがわかりました。サーバに搭載するメモリ容量に比例して許容する接続セッション数を増加させることが多く、思わぬ落とし穴として本連載ではPTEを取り上げてきました。 さて、今回は Oracle Database を使用して HugePage と 4KB(標準) を使用した場合にメモリ使用効率がどのように変化するのかを確認したいと思います。 検証用に使用する環境は、以下の通りです。 RHEL 5.6 (2.6.32) 64bit CPU: Intel Core i7-2600 CPU 3.40GHz メモリ：5GB Oracle Database EE 11gR2 (シングルインスタンス) SGA：3GB 大容量メモリ云々といっておきながらかなり貧弱な環境ですが、HugePageの検
続・HugePages_3
前回の「続・HugePages_2」の続きです。 前回はvm.nr_hugepagesはsga_targetの値を検討するところまででした。 今回は設定していきます。 1.vm.nr_hugepagesを設定します。 /etc/sysctl.confにvm.nr_hugepages=算出した値を記述します。 私の環境ではSGAを5GBと見積り、2560(5120MB/2)とします。 sysctl -p で反映します。 自動メモリ管理(AMM)環境とHugepagesの理解を深めるため、 寄り道をすると、 自動メモリ管理(AMM)環境で/dev/shmを使用している場合と、 Hugepagesを使用する場合には空きメモリの見え方が異なります。 ■自動メモリ管理(AMM)環境(DB起動前) [root@s112040 /]# free -m total used fre
ひとりごと: Java で Hugepage を使用する
2013年12月12日木曜日 Java で Hugepage を使用する JPOUG Advent Calendar 2013 の 12月12日のエントリです。 http://www.zusaar.com/event/1687004 Java で Hugepage を使う方法を紹介します。 Hugepage は、非常に大きなメモリ空間を使用するDatabaseでのみ使用されると思われがちですが、Database の専用技術ではないため Java で使うことも出来ます。 昨今の Java VM では数十GB以上のメモリを使用する環境もよく見るようになりましたので、ひょっとすると Java + Hugepage という組み合わせを使う機会に遭遇するかもしれません。 それでは、どのようにして Hugepage を使用するのかを紹介します。 ■Hugepageの設定を確認する まずは、
You are viewing the documentation for the 2.9.x release series. The latest stable release series is 3.0.x. Search Home Working with Play Common topics Configuration §Understanding Play thread pools Play Framework is, from the bottom up, an asynchronous web framework. Thread pools in Play are tuned to use fewer threads than in traditional web frameworks, since IO in play-core never blocks. Because
はじめに こんにちは、ピクトリンク事業部開発部サーバサイド開発課のkitajimaです。弊社サービスピクトリンクは、システム再構築の一環として
Playframeworkを少し大きめのスレッド数(50)で動かしていたら、自分の予想よりも大きくメモリを消費しました。 今回はその調査レポートです。 なお対象としたPlayのバージョンは1.2.5です。 Playのスレッド数のデフォルト値 まずPlayのスレッド数の設定について少し考察しておきます。 Playのスレッド数はapplication.confの「play.pool」というキーで設定されます。 このキーが省略された場合のデフォルト値は以下のようになります。 DEVモード - 1 PRODモード - 環境で利用可能なCPU数 + 1 DEVモードとPRODモードは開発環境と本番環境で設定を変更するためのフラグです。 このように開発時と本番で異なるデフォルト値が適用されますが、個人的にはこれらのデフォルト値はDEVモード、PRODモードどちらの場合においても適切ではないと考えていま
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NICのリングバッファ(ring buffer)拡張