Q&A
jps コマンドで実行中のjavaプロセスとそのプロセスID(PID)が得られます。コマンドの結果からPID:264のものが何であるか見てみてください。(それで見当がつかないようであれば結果を質問文に追記してみてください。)
↑アクティビティモニタ
昨日からずっとMacbookairがうなっております。
原因がわからずひまずアクティビティモニタを見たところ、Javaというのが原因なのかなと思いました。ただ、それがわかったところで対処の仕方がわからず、調べている所、SMCリセットしたら改善したという記事がいくつかあったため、試しました。
しかし、ダメでした。
また、アクティビティモニタのプロセス一覧[Java]を選択した状態（画像の状態）で左上の[☓]ボタンを押し、プロセスを消したのですが、すぐに復活してしまい効果はありませんでした。
一晩様子を見ていたのですが、今朝になっても改善しなかったため、質問にいたりました。
どなたか原因がわかる方はいらっしゃいますでしょうか？
尚、最近いれたものとして思い当たるのは、
「scala」 と 「Intel IDEA」(IDE)です。
scalaが原因ってことは可能性としてあり得るのでしょうか？
ps ax | grep scala 1680 s000 R+ 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn scala
宜しくお願いします。
javaは最新の状態です。
追記
$ jps
2068 Elasticsearch
3268 Jps
$ jstack 2068
かなり多かったので一部のみ抜粋
"Attach Listener" #26851 daemon prio=9 os_prio=31 tid=0x00007ff1b15bc000 nid=0xbe7f waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "elasticsearch[Volcana][bulk][T#4]" #1437 daemon prio=5 os_prio=31 tid=0x00007ff1ac914800 nid=0x83ff waiting on condition [0x000000012acda000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007952d4370> (a java.util.concurrent.LinkedTransferQueue) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737) at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647) at java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269) at org.elasticsearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:161) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "elasticsearch[Volcana][bulk][T#3]" #945 daemon prio=5 os_prio=31 tid=0x00007ff1aeb5d000 nid=0x8e7f waiting on condition [0x00000001366b3000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007952d4370> (a java.util.concurrent.LinkedTransferQueue) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737) at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647) at java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269) at org.elasticsearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:161) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "elasticsearch[Volcana][warmer][T#2]" #556 daemon prio=5 os_prio=31 tid=0x00007ff1b063a800 nid=0x9007 waiting on condition [0x000000012aa45000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000794f840b8> (a org.elasticsearch.common.util.concurrent.EsExecutors$ExecutorScalingQueue) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:734) at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647) at java.util.concurrent.LinkedTransferQueue.poll(LinkedTransferQueue.java:1277) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
"elasticsearch[Volcana][[timer]]" #13 daemon prio=5 os_prio=31 tid=0x00007ff1ac2db000 nid=0x5407 waiting on condition [0x00000001268ed000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.elasticsearch.threadpool.ThreadPool$EstimatedTimeThread.run(ThreadPool.java:703) "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007ff1ac82c000 nid=0x4b03 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread2" #8 daemon prio=9 os_prio=31 tid=0x00007ff1ab814000 nid=0x4903 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" #7 daemon prio=9 os_prio=31 tid=0x00007ff1ab813000 nid=0x4703 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #6 daemon prio=9 os_prio=31 tid=0x00007ff1ab812800 nid=0x4503 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #5 daemon prio=9 os_prio=31 tid=0x00007ff1ab811800 nid=0x4303 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Surrogate Locker Thread (Concurrent GC)" #4 daemon prio=9 os_prio=31 tid=0x00007ff1ab801000 nid=0x370b waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007ff1ab809000 nid=0x2f03 in Object.wait() [0x0000000123dca000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x0000000794ceca40> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007ff1ac02e800 nid=0x2d03 in Object.wait() [0x0000000123cc7000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x0000000794ce7dc0> (a java.lang.ref.Reference$Lock) "VM Thread" os_prio=31 tid=0x00007ff1ac02b800 nid=0x2b03 runnable "Gang worker#0 (Parallel GC Threads)" os_prio=31 tid=0x00007ff1ab01a800 nid=0x313 runnable "Gang worker#1 (Parallel GC Threads)" os_prio=31 tid=0x00007ff1ab01b000 nid=0x230b runnable "Gang worker#2 (Parallel GC Threads)" os_prio=31 tid=0x00007ff1ac008000 nid=0x2503 runnable "Gang worker#3 (Parallel GC Threads)" os_prio=31 tid=0x00007ff1ac008800 nid=0x2703 runnable "Concurrent Mark-Sweep GC Thread" os_prio=31 tid=0x00007ff1ab046800 nid=0x2903 runnable "VM Periodic Task Thread" os_prio=31 tid=0x00007ff1ab84f000 nid=0x4d03 waiting on condition JNI global references: 452
こういうのががいっぱい生成されてる・・・。
jpsを実行した所、以下のようになりました。
➜ ~ jps
2068 Elasticsearch
3092 Jps
その上で
```
➜ ~ ps ax | grep Elasticsearch
2068 ?? R 142:39.34 /usr/bin/java -Xms256m -Xmx1g -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -Dfile.encoding=UTF-8 -Djna.nosys=true -Des.path.home=/usr/local/Cellar/elasticsearch/2.1.0_1/libexec -cp /usr/local/Cellar/elasticsearch/2.1.0_1/libexec/lib/elasticsearch-2.1.0.jar:/usr/local/Cellar/elasticsearch/2.1.0_1/libexec/lib/* org.elasticsearch.bootstrap.Elasticsearch start
3118 s001 R+ 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn Elasticsearch
```
PID:264のものが何であるかは上記コマンドだけではわかりませんでした。私のやり方で何か違いましたらご指摘頂けると幸いです。
ついでに、PIDを指定するとjstackコマンドでスレッドダンプが取れるので、それも質問文に追記すると何か分かるかも知れません。PIDが294なら、
jstack 294で取得できるはずです。
アクティビティモニタで上位にあるjavaプロセスのPIDは2068に変わっていたりしませんか？それから、結果は質問文に追記してもらった方が見易くなります。
アクティビティモニタで上位にあるjavaプロセスのPIDは2068に変わっていました。2068をもとにjstackをした結果を質問文に追記致しました。お手数ですが宜しくお願いします。
Elasticsearchに心当たりはありませんか？
ここ数日はelasticsearchを使っていないのであまりこころあたりはないのですが、http://localhost:9200/_plugin/head/をみると、すごくいっぱいmarvel-esが生成されてました。質問文に追記しました。
ここに原因があるのかなと思い、現在調べてます。
https://github.com/elastic/elasticsearch/issues/4288
ただ、正直なところあまりよくわかってません・・・><
I had a same issue, high cpu and high memory, for me it was marvel creating a new big index everyday.
so I deleted all marvel indices and ran _flush, it cleared my memory and cpu came down fro 90% to 4%.
CPUを消費しているのはElasticsearchと考えて良いと思いますのでElasticsearchを落とせばCPU使用率は下がると思いますが、ElasticsearchがなぜCPUを消費しているのか、原因と対策まで含めてこの質問と考えて良いですか？
もし可能でありましたら、ElasticsearchがなぜCPUを消費しているのか、原因と対策まで含めてこの質問とさせていただいて宜しいでしょうか？質問内容と少しずれてきてしまいますが、何卒宜しくお願いします。
ちなみに、 $ elasticsearch stop みたいなコマンドはみあたらなかったため、最悪、uninstallするか、原因を特定し、解決するしかないかなと思っております。
了解です。そうであれば、Elasticsearchのバージョンやどのようにインストールしたのか、Javaのバージョンなども教えていただきたいです。Elasticsearchのログに何かエラーが出ていないかも確認したいです。また、jstackの結果については、CPUを消費しているスレッドの見当をつけたいので、runnableのスレッドを抜粋して頂けませんか？それから、GCの可能性もあるかと思うので、jvisualvmを起動して、Elasticsearchのプロセスを開いて、監視タブを画面キャプチャして質問に追加していただけますか？
それと、分かる限りは対応しますが、
Elasticsearchについて、私はそれほど詳しくはないので、タグにElasticsearchなど付け加えたほうが、良い回答がつくかもしれません。
回答2件
0
現時点では原因は分かりませんが、わかる範囲で回答します。
(追加情報があれば、改めて内容確認します。)
原因からの対策
qaz3330さんが「情報の追加・修正の依頼」に書いている、
ES java very high CPU usage · Issue #4288 · elastic/elasticsearch
ですが、ここではmarvelのインデックス削除によってCPU使用率が90%から4%になったと書いてある様です。
インデックスを削除することはできますか？
とりあえずElasticsearchを落とすには
もしHomebrewでインストールしたのであれば、ここにある様に、
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.elasticsearch.plist
でアンロードすれば停止はできるのではと思います。
他の方法でインストールしたのであれば、その内容を記述してください。
投稿2016/02/03 06:51
総合スコア1546
ご回答有難う御座います。
取り急ぎ現状の情報を書きます。
まとまり次第、質問文にも反映させます。
Elasticsearchのバージョン
version[2.1.0]
どのようにインストールしたのか
brew install elasticsearch
Javaのバージョン
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.elasticsearch.plist
でアンロードで停止はできました。
まだ、MACは唸ってますが、
しばらくこれで様子をみようと思います。
> インデックスを削除することはできますか？
インデックスの削除の仕方がわからず、調べている最中です。
curl -XPOST 'http://localhost:9200/_flush'
curl -XPOST 'http://localhost:9200/_shutdown'
とかなのかなとおもったのですが、上手く行かず。
以下の2点に関しては、私の勉強不足というのもあり、現在やり方を調べてます。
もし抜粋するために行うコマンドなど教えて頂けるとありがたいです。
jstackの結果については、CPUを消費しているスレッドの見当をつけたいので、runnableのスレッドを抜粋して頂けませんか？
visualvmを起動して、Elasticsearchのプロセスを開いて、監視タブを画面キャプチャして質問に追加していただけますか？
ひとまず、現時点で、
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.elasticsearch.plist
のかいあって、CPUは収まりました。
根本解決はしていないので、引き続き、marvelの問題に取り組もうと思います。
本当に色々とお手数をかけてすみません・・・。
runnableのスレッドですが、
"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007ff1ac82c000 nid=0x4b03 runnable [0x0000000000000000]
の様に、"runnable"と入っているスレッドをスタックトレース込みで見たいです。
visualvmについては、jvisualvmというコマンドがあると思うのですが、
それを実行できませんか？
インデックスの削除については、
http://ameblo.jp/fcv-system/entry-11947559684.html
が参考になりませんか？
度々有難う御座います。午後は外出などが重なり返答が遅れました。jvisualvmで、監視画面などを閲覧することができましたので、後ほど、runnableのスレッドなど、諸々含め、ログを出してみようと思います。
0
Javaに次いでCPU使用量が多いプロセスがmdsとmds_storeですから、これらが原因となっているのではないかと思われます。
下記ページに、mdsが暴走した際の対処方法が説明されているので、試してみては如何でしょうか。
投稿2016/02/03 05:02
総合スコア6919
スクリーンショットで見るとmdsとmds_storeのCPU使用率は足しても14.4%なので問題ないかと思いますが、どうでしょうか
javaのプロセスを停止しても復活するので、javaのプロセスを生成している別のプロセスが稼働している。javaがcpuの300%を消費しているのは異常で、プログラムが暴走していると思われる。mdsは暴走することは良く知られており、mdsと関連プロセスのmds_storeのcpu消費が大きい事から、mdsが原因ではないかと推測しました。
ご回答有難う御座います。
Macが重くなった時に暴走しているプロセスと対処法４つ
上記を基に、mds（Spotlight）暴走時の対処法
を行いましたが、改善されませんでした。
セーフブートモードで起動する（Shiftを押しながらOSを起動）はまだやってませんが、現在、修正依賴のところに上がってきたjstackをもとに、別の原因を探ってます。
あなたの回答
tips
プレビュー
