タグ

メモリに関するshigeaki1jpのブックマーク (17)

  • OutOfMemoryに泣く | SIOS Tech. Lab

    ◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【6/19開催】Kong Community Japan Meetup #4 イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定!参加無料です!! https://column.api-ecosystem.sios.jp/connect/kong/1081/ 【6/21開催】開発者目線でのSBOMとの向き合い方 SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法(デモ)を紹介します。

    OutOfMemoryに泣く | SIOS Tech. Lab
  • Using Native Memory by JVM | DevelopersIO

    はじめに こんにちは。事業開発部のこむろ@さっぽろです。 最近、諸事情から所属部署でどこにでも顔を出す人として活動しています。 今回はJVMのメモリ周りについて初めて調べました。 背景 Javaアプリケーションを利用している場合、最近ではContainerを利用してアプリケーションを起動しているところも多いかと思います。わたしの所属する事業開発部では、ECSを利用して複数のJavaアプリケーション(Spring Boot)をContainerで稼働させています。 Containerで稼働させるため一つのホストのリソースをすべて割り当てられるわけではありません。Containerには利用できるリソースにハードリミットが設けられているため、リソースの配分には少々気を使う必要があります。 今まであまり意識してチューニング等していなかったのですが(富豪的にメモリを割り当てたりしてて深く考えていなか

    Using Native Memory by JVM | DevelopersIO
  • LinuxにおけるOOM発生時の挙動 - Qiita

    はじめに これはLinux Advent Calendar 2015 3日目の記事を2016/2/2に編集したものです。 Linuxにおいてシステムの物理メモリが枯渇したOut-Of-Memory(OOM)という状態になった際の挙動について説明しています。OOMに関連が深いsysctlパラメタを紹介するとともに、カーネルの内部論理についても触れました。 記事に記載されているファイル名は、とくに断りが無ければカーネルソースのトップディレクトリからの相対パス名です。調査に使用したカーネルバージョンは4.3です。 書は話を単純化するために、細かい動作論理については説明を省いていることをご承知おきください。また、書の中に誤りを見つけたかた、および、私が追いきれなかったソースについての詳細をご存知のかたは、指摘していただけると助かります。 Out-Of-Memory(OOM)とOOM-kill

    LinuxにおけるOOM発生時の挙動 - Qiita
  • Kubernetesで実際のメモリを超えるコンテナアプリを動かすと、どうなるか? - あさのひとりごと

    Kubernetesは、コンテナアプリケーションをデプロイするためのオーケストレーションツールです。Kuberenetesは分散環境におけるスケーラブルなコンテナ実行環境をつくるための、さまざまな機能が提供されています。 もともとはGoogleが開発したBorgをもとにOSS化したものですが、今日ではマイクロソフトや(ry Kubernetesをつかうとステートレスでマイクロサービス的なアプリケーションを1日に何度もデプロイでき、スパイクアクセスがきても水平スケールが容易なので、大規模Webシステムでスケーラブルな基盤を作れる、というのは広く知られています。 一方、Kubernetesには「Resource Requests」という機能があり、これはPodをデプロイする時に必要とするリソース(CPU/メモリ)を指定できるものです。これにより、Kubernetesクラスタのリソースの使用率を

    Kubernetesで実際のメモリを超えるコンテナアプリを動かすと、どうなるか? - あさのひとりごと
  • JavaScriptのクロージャはメモリーリークをちゃんと理解して使おう - Qiita

    はじめに 前にブログで書いた記事なのですが、せっかくなのでQiitaにも投稿します。 脱初級者の壁として君臨しているクロージャ。クロージャの使い方はわかったけど、いろんな記事を見るとクロージャは問題点もあるみたい。それに、そもそもクロージャの使い所がいまいちわかんないと思ってクロージャに再度立ち向かおうと思った次第です。同じような悩みを抱えているデザイナーさん、コーダーさん、フロントエンドエンジニアさんの参考になれば嬉しいです。 クロージャとは とりあえずおさらい & 補足をします。 よく見かけるクロージャの見がこちら。 ここで簡単にクロージャについて説明します。ちなみに、最近読んだで何となくJavaScriptを書いていた人が一歩先に進むためのが説明としてわかりやすかったので、そちらを引用させていただきながら。 まずクロージャとは ローカル変数を参照している、関数の中に定義している

    JavaScriptのクロージャはメモリーリークをちゃんと理解して使おう - Qiita
  • JavaScriptでメモリ効率を考える その2(メモリアロケータ篇) - Qiita

    JavaScriptでメモリ効率を考える その1(シングルフレームバッファ篇) JavaScriptでメモリ効率を考える その2(メモリアロケータ篇)←この記事 通常の配列生成 前回のシングルフレームオブジェクトで大量のオブジェクトは捌けました。 捌けましたが、あれはプロパティやら何やらが色々固定されたクラスだから出来たことで、例えばこんなケースだと難しいです。 function loop(){ let i = 1000; while(i--){ // ランダムなサイズを指定 const size = Math.ceil(Math.random() * 100000); // 配列を生成 const arr = new Float32Array(size); // 破棄する arr = null; } requestAnimationFrame(loop); } サイズが変動する配列はプー

    JavaScriptでメモリ効率を考える その2(メモリアロケータ篇) - Qiita
  • LinuxのI/OやCPUの負荷とロードアベレージの関係を詳しく見てみる - Qiita

    大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ

    LinuxのI/OやCPUの負荷とロードアベレージの関係を詳しく見てみる - Qiita
  • いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita

    さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分

    いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita
  • HeapStats @ Seasar Conference 2015 LT

    Introduction and Technical Preview about HeapStats. http://icedtea.classpath.org/wiki/HeapStats

    HeapStats @ Seasar Conference 2015 LT
  • アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog

    問題 アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について調べた。 該当のサーバでは、以下のようにメモリの使用率が徐々に上昇していく。 また、アプリケーションのプロセス自体がメモリを消費しているわけではない状態。 原因 調査すると、このバグ仕様を踏んでいるのではないかと思われるページを見つけた。 https://bugzilla.redhat.com/show_bug.cgi?id=1044666 内容としては、curlを実行した際に /etc/pki/nssdb/以下の存在しないファイル(毎回違うパス)に対してaccessシステムコールが大量にコールされ、 negative dentry cacheが溜まっていき、メモリ使用量が圧迫されるというもの。 実際、この状況が起きているサーバを調べるとメモリ使用率のうち多くを占めているのはnega

    アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog
  • Linuxの性能関連のまとめ - ITメモ

    性能測定コマンド sar :システム稼動状況 mpstat:CPU稼働状況 vmstat:仮想メモリ稼働状況 free :メモリ情報 iostat:ハードディスク,CPU使用状況 ps :プロセス情報 top :プロセス情報 目安 CPU CPU使用率:90%以上 CPU待ちプロセス数:2より大きい(1CPUあたり) メモリ メモリ使用量:ページングの発生回数 ディスク ディスク使用率:80%以上 ネットワーク ネットワーク使用率:80%以上 パケット衝突回数:送信パケットの10%以上 sarコマンド # sar [オプション] [-o ファイル名] 取得間隔 取得回数 -u:CPUCPU使用状況 -q:CPU:プロセスキュー、システム稼動負荷 -r:メモリ:メモリ,スワップ領域使用状況 -R:メモリ:メモリ動作状況 -B:メモリ:ページング統計値 -W:メモリ:スワッピング統計値 -b

    Linuxの性能関連のまとめ - ITメモ
  • SparkアプリケーションのためのJavaガベージコレクションのチューニングについて - TEPPEI STUDIO

    この記事は、インテルの SSG STOビッグデータテクノロジーグループのメンバーからDataBricksに寄稿されたブログを翻訳したものです。誤訳がありましたら、@teppei_tosaに御連絡ください。 Sparkは、その優れた性能、シンプルなインターフェイス、および分析や計算のための豊富なライブラリによって、幅広い業界で採用されてきています。ビッグデータエコシステムにおける多くのプロジェクトと同様に、Sparkは、Java仮想マシン(JVM)上で実行されます。Sparkはメモリに大量のデータを格納することにおいて、Javaのメモリ管理とガベージコレクション(GC)に大きく頼っています。また、プロジェクトTungstenなどの新たな取り組みは、将来のバージョンで、メモリ管理のさらなる簡素化と最適化を目指しています。しかし、今日時点でも、JavaのGCオプションとパラメータを理解しているユ

    SparkアプリケーションのためのJavaガベージコレクションのチューニングについて - TEPPEI STUDIO
  • Redisを使う時は見積の二倍の容量必要だよね、という話 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    Redisを使う時は見積の二倍の容量必要だよね、という話 - Qiita
  • 恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、

    恐怖の JVM 大量メモリ消費!メモリリークの謎を追え!! - Cybozu Inside Out | サイボウズエンジニアのブログ
  • Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して

    今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか?また、元々Permanent領域に格納されていた情報は何処にいってしまったのか?JVM付属のツールにどういった影響があるのか? 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番(「補足 – HotSpotVMのメモリ構造概説)を読んでいただくとスムーズに読み進められるだ

    Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
  • Macをスピードアップさせる5つの簡単テクニック | ライフハッカー・ジャパン

    デジタル機器を使っていれば、処理スピードの低下は避けられません。好きなようにあれこれ使っていれば、データやあらゆる情報がどんどん溜まっていきます。人間が生きるためにべ物を必要とするように、Macがきちんと仕事をするためにはデータが必要です。しかし、困ったことに、データが溜りすぎて、Macの処理能力を超える時がいずれはやってきます。そうなったら最後、スピードは徐々に落ち始めます。 そのような状態になってしまったら、日常的な処理をいったんやめたほうが良いでしょう。Macは休息を必要としているので、ひと息つかせてあげましょう。(あえて言うなら)「格的な休暇」をあげてください。一気に生き返るはずです。 では、Macの処理スピードをアップさせる簡単な方法を5つご紹介しましょう。 1. メモリの空き容量を10%以上に保つ 何はともあれ、メモリの空き容量が10%以下にならないよう気をつけます。使用可

    Macをスピードアップさせる5つの簡単テクニック | ライフハッカー・ジャパン
  • JVM! JVM! JVM!

    10. jmc Java Mission Control ● メモリ統計、スレッド数、クラス数をグラフィカルに表 示 ● jconsoleと似たような感じだけどjmcの方がなうい? ● ダッシュボードのカスタマイズ(グラフの追加)が可能 ● Flight Recorderというプロファイリングツールがあ る。が商用ライセンスが必要(らしい ● -XX:+UnlockCommercialFeatures -XX:+FlightRecorder ● Eclipseプラグインとしても利用できる(らしい

    JVM! JVM! JVM!
  • 1