You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Go is a simple and fun language, but, like any other language, it has a few gotchas... Many of those gotchas are not entirely Go's fault. Some of these mistakes are natural traps if you are coming from another language. Others are due to faulty assumptions and missing details. A lot of these gotchas may seem obvious if you took the time to learn the language reading the official spec, wiki, mailin
こんにちは、ミドルウェア開発チームの青木です。 先日、アプリケーションサーバーが応答を返さなくなるトラブルに遭遇しました。 今回はその時のトラブルの原因と対策の顛末についてお話しようと思います。 現象 アプリケーションサーバーが突如応答を返さなくなりました。 現象が発生したアプリケーションサーバーのスタックトレースを見ると、あるスレッドの先頭が上記のようになっていました。 "qtp258153142-514386" prio=10 tid=0x00007f40b8dbf000 nid=0x7b4e runnable [0x00007f415ccb0000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$Loop.match(Pattern.java:4692) at java.util.regex.Pattern$G
問題 アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について調べた。 該当のサーバでは、以下のようにメモリの使用率が徐々に上昇していく。 また、アプリケーションのプロセス自体がメモリを消費しているわけではない状態。 原因 調査すると、このバグ仕様を踏んでいるのではないかと思われるページを見つけた。 https://bugzilla.redhat.com/show_bug.cgi?id=1044666 内容としては、curlを実行した際に /etc/pki/nssdb/以下の存在しないファイル(毎回違うパス)に対してaccessシステムコールが大量にコールされ、 negative dentry cacheが溜まっていき、メモリ使用量が圧迫されるというもの。 実際、この状況が起きているサーバを調べるとメモリ使用率のうち多くを占めているのはnega
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable(EJB除く)である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
既に12月22日ですが、このエントリーは、Node.js Advent Calendar 2014の13日目のエントリーです。 いや私が書くの遅れたわけじゃないですけど…(言い訳)、ちょうどタイムリーなネタがあるので、先日リリースされたNode-v0.10.34で発生した(現在も継続している)問題について携わった経緯を自分の目線で書いてみます。 追記:日本時間の12/24にNode-v0.10.35がリリースされました。 http://blog.nodejs.org/2014/12/23/node-v0-10-35-stable/ 本記事の不具合も修正されています。 1. Node-v0.10.34リリース直後にissue発生 先週12/17にNode v0.10.34 (Stable)がリリースされました。10月中旬にPOODLE騒ぎでOpenSSLに対応した Node-v0.10.33
This document provides an overview of performance analysis tools for Linux systems. It describes Brendan Gregg's background and work analyzing performance at Netflix. It then discusses different types of tools, including observability tools to monitor systems, benchmarking tools to test performance, and tuning tools to optimize systems. A number of command line monitoring tools are outlined, such
PPLサマースクール2016「商用Java処理系の研究開発」のパート2です. http://ppl.jssst.or.jp/index.php?ss2016 Java言語処理系の実装について詳説する.まずJava仮想マシンの概要について述べ,その主要な構成要素として,クラス管理とインタープリタ,ヒープ管理とガベージコレクション,スレッド管理と同期機構,JITコンパイラとの連携,などについて説明する.性能改善のために行った各種手法についても触れる. 他のパート 1 Javaの登場と発展 http://www.slideshare.net/Tamiya_Onodera/java-66081108 2 Java仮想マシンの実装技術 http://www.slideshare.net/KiyokuniKawachiya/java-66003903 3 Java Just-In-Timeコンパイラの
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 メモリリーク。一言でプログラマを死に追いやる恐怖の言葉。C/C++の世界ではmallocしたのにfreeしないとかのケアレスミスでよく起きていた問題です。その後、ガベージコレクタが掃除してくれるプログラミング言語が増え、一部の言語で循環参照に気をつけるぐらいであまり気にしなくても良い的な風潮になっています。 というものの、そうとも言ってられなくない状況も増えてきています。クラウドのスケールアウトブームも一段落というかコモディティ化し、go言語で再び性能向上方面に関心が寄せられたり、日本でErlangの勉強会が満席になったり、スケールアウトから再びスケールアップ方面に話題が移りつつあるのを感じます。長時間稼働のサーバで、スケールアップしてさらに数多くのリクエストを大量に受けるよう
@hirose31さんと、Apache HTTPDからHTTPSでファイルダウンロード中にサーバプロセスがSIGBUSで死ぬって件にぶちあたり、 「OpenSSLの中でmemcpyがSIGBUSしてます」「な、なんだってー!」 って調べたのですが、理由は以下のとおりだった。 HTTPSの場合、デフォルト設定だとファイル読込にmmap(2)が使われる mmapされたファイルのサイズが変更されてもApacheはそれを検知しようがない そして、ファイル末尾以降のデータを読もうとするとセグメンテーションエラー(SIGBUS)が発生し、Apacheのサーバプロセスは異常終了する HTTPの場合は、ローカルファイルシステムの場合sendfile(2)が使われるので、ファイルサイズが変更になってもApacheは異常終了しない ただし、mod_deflateのような出力フィルタを使っている場合は、HTTP
Apacheのmod_statusを使えば各プロセスの状態を知ることができます。CloudForecastやCacti等でそれを元に視覚化している人も多いと思います。 mod_statusで確認できる状態には以下の11種類があるのですが、 状態名 値 mod_stautsでの記号 説明 SERVER_DEAD 0 . Open slot with no current process SERVER_STARTING 1 S Server Starting up SERVER_READY 2 _ Waiting for connection (or accept() lock) SERVER_BUSY_READ 3 R Reading a client request SERVER_BUSY_WRITE 4 W Processing a client request SERVER_BUSY_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く