恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
Javaとキャッシュの付き合い方で考えてた - 日々量産
キャッシュっていろんな意味があってアレだけど、ここでは「苦労して得た情報なんだから使いまわしたい」時に使うキャッシュということで。 仕事でキャッシュ使ったほうがいいよなぁ、とぼんやり思ったので考えまとめるためにメモっとく。 アルゴリズムの勉強しかけたけど、LRUとLFUぐらいしかわからんし、効率よく実装するにゃ頭が足らんかった。 なぜキャッシュを使いたいと思ったか 設定ファイル読み込んだり、独自の定義ファイル(xmlとか独自フォーマットなファイルとか)をいくつも読む必要があった。 これらのファイルを1リクエスト中に1〜5回ぐらいファイルを読むようで、応答速度も「現在は」気になってない。 でも、ファイルのアクセスは時間がかかる！遅い！！クソザコ！！！という固定概念を持ってるので、キャッシュしたほうが早くなるよなーと思った。 キャッシュのメリット 実行時間が短縮できる(応答速度が上がる) キャ
どうしてメモリはスワップするのか！？
こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha
Linux のメモリー管理(メモリ―が足りない？,メモリーリークの検出-防止)(Kodama's tips page)
サ−バ等に使っているPC のメモリが十分かどうか気になる事は多いと思う. 調べ出すと フリーメモリーの不足や SWAP にメモリーがはみだしている様子など 心配な事がいろいろでて来る. PC の動作が遅くなる原因は様々な要因が絡み合っているので, 表面に現れた症状だけでは効果的な対策が分からない事もある. 以下では, メモリ−関連にしぼって解説する. メモリの状況を調べる メモリ−は十分なはずなのに 余裕が無い？ どのプロセスがメモリを消費しているのか？ メモリーのリークを検出する方法？ 防止する方法？ メモリ−は十分なはずなのに SWAP を使ってる？ じゃ, 本当のメモリ−不足はどうしたら分かるの？ メモリーと SWAP 領域はどのくらい確保すると良いのか メモリの状況を調べる メモリの利用状況を調べる方法は, free, top, ps, vmstat, /proc/meminfo
Linux のオーバーコミットについて調べてみた
Linux のオーバーコミットについて調べてみた Linux のオーバーコミットのはなし（これを書いたのは Linux 2.6.38 のとき） Linux カーネルは実メモリ以上にメモリをプロセスに割り当てることができる この仕組みをオーバーコミット (over-commit) と呼ぶ オーバーコミットでは，とりあえずメモリを malloc させて仮のアドレスを返しておき， 実際に使われる段になってはじめて実メモリを確保する． 実験ただ malloc し続けるだけのプログラムを作って実験してみる． このプログラムをメモリ 1 GB + スワップ 1 GB のホストで実行してみると， $ free -t total used free shared buffers cached Mem: 1022404 82992 939412 0 4172 12280 -/+ buffers/cache:
MySQLのメモリ設定を追求してみよう – OpenGroove
（2015年1月追記：これは現時点で約5年前に書いた記事です。各種パラメータは名称や仕様が変更されている可能性があるため、最新の情報を参考にしてください） MySQLのメモリの話を考えていたら何が何だか分からなくなってきたので、my.cnfでの設定に絡めてまとめてみようと思う。そもそも、MySQLサーバにおいてMySQLのプロセスがトータルで使用するメモリは、どれくらいに見積もっておけばいいだろうか。参考書やネット上では以下のような計算式が紹介されている。 max_connections x [スレッド領域用メモリ合計値] に、以下をプラス。 [グローバル領域用メモリ合計値] DB専用サーバの場合だとこの値をマシン搭載メモリの8〜9割くらいにする、と想定するのがひとつの指針となるようだ。しかし32bit版Linux OSの場合は2〜3GBまでの制限があるため、搭載メモリがそれ以上あったとし
"PHP Fatal error: Allowed memory size of xxx" で落ちる前にできること - ぷぎがぽぎ
PHP Advent Calendar 2013 - 7日目 昨日は@hidenorigotoさんのBeyond MVCでした。 今日は PHPあるある的な問題に対する対策について少しばかり書きたいと思います。 ※ 歯ブラシを持たせてみた *1 メモリ不足でよくやる対応 PHPで大量のデータを扱ったりすると、設定された利用可能な最大メモリ使用量を超えて PHP Fatal error: Allowed memory size of 524288330 bytes exhausted (tried to allocate 351 bytes) in ....というエラーが発生して対応に追われたことの経験がある人はかなり多いと思います。 そもそも環境のメモリに余裕があるならmemory_limitを調整してメモリの使用量を増やしたり あまり余裕がない場合は暫定的対応として、該当処理部分だけ <
5.3.2. Cachegrind を使ったキャッシュ使用量のプロファイリング Red Hat Enterprise Linux 6 | Red Hat Customer Portal
パフォーマンスチューニングガイド 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
UnicornのWorkerプロセスをリサイクルする - Qiita
Web サーバやアプリケーションサーバは、リクエスト数やメモリ使用量がある閾値を超えたらプロセスの再起動を行う仕組みが用意されています。 Apache にも IIS にもそのための設定項目が用意されていて、この仕組みを一般にリサイクルと呼ぶようです。 UA からのリクエストをさばくワーカープロセスが疲弊せず、パフォーマンスを維持するための仕組みですね。 Ruby で人気のアプリケーションサーバである Unicorn ですが、残念ながらこのリサイクルの機能を持っていません。 どうにかできないかなーと思って調べていたら、この短所を補完する Gem がリリースされていました。 Unicorn Worker Killer | github そのまんまですね。 この Gem でできるのは、以下のようなリサイクルです。 ・一定のリクエスト数を超えたらランダムで再起動する（上限に達したら必ず再起動）。
cronのジョブをランダムに走らせる - 綾小路龍之介の素人思考
一時間に1回コマンドやシェルスクリプトを走らせたいけれど、走るタイミングはランダムであってもらいたい。呼び出しのタイミングが一定であればcronだけでOKだが、ランダムなタイミングだとそういうわけには行かない。そんな場合にどうするのか。1時間に1回という点はcronで、ランダムなタイミングはsleepで解決してみる。呼び出されるコマンドやシェルスクリプトの一般性をなくさないために呼び出すタイミングをランダムにするためのシェルスクリプトを介してコマンドやシェルスクリプトを呼び出す。 $ cat randomsleep.sh #!/bin/bash NUM=`expr $RANDOM % 3600` echo $NUM sleep $NUM $ sh randomsleep.sh; wget http://www.google.com -O - randomsheep.shで0-3599秒の適
memcachedと“正反対”、Redisが仮想メモリをサポート － ＠IT
2010/09/07 KVS（キー・バリュー・ストア）に分類されるオープンソースのRedisの新バージョン、「Redis 2.0.0」が2010年9月5日にリリースされた。Redisはmemcachedと同様にキーと値のペアをメモリ上に保持するKVSの一種だが、3つの際立った特徴がある。1つはハッシュ以外のデータ構造もサポートしていることで、リスト型、集合型、順序付き集合型などのデータ構造が扱え、サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作がアトミックに行える。バージョン2.0では複数の操作を1つにまとめてアトミックに操作するコマンドも増えている。 もう1つのRedisの特徴は、マスター・スレーブによるレプリケーション設定ができ、リード側のスケールアウトが容易にできること。 そして3つ目の特徴は、
SwiftのArrayがヤバイ - Qiita
(2015.11.18に追記) 「Swift List」 で検索するとこの投稿にたどり着いてしまいますが、関数型言語でいうところのリストをお求めの方は "Swiftでhead、tailにパターンマッチできる遅延リスト" を御覧下さい。 (2014.7.24に追記) SwiftのArrayの新仕様（beta 3以降）がヤバイどころかすばらしいのでまとめました 。 (2014.7.10に追記) SwiftのArrayがヤバくなくなりました。 本投稿に書かれているのはbeta 2までの古いSwiftについての情報ですのでご注意下さい 。beta 3以降では次のような挙動となり、値型としてごく自然な挙動になりました。 var a = [11, 22, 33] var b = a a[0] = 777 // b[0]は777にならない a.append(44) a[0] = 888 // b[0]は
Island Life - 100年後の言語
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...ループを使わずに1から100までMore... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチ
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
chromeの爆裂的なメモリ消費をなんとかする拡張 * prasm（プラズム）
ソーシャルゲーム系フロントエンドを作る際に殴り合いにならないようエンジニアが確認すべきこと
IBM Developer